A multi-site content management system (CMS) shared across brand properties sounds simple: one platform, one team, unified governance. Then you sit down with three brand teams whose Content-Types were described as "basically the same" and discover three different editorial structures, three approval chains, and three publishing cadences. One content model either forces compromises on everyone or accumulates conditional fields that nobody wants to edit.
The scope here is content modeling and information architecture for a multi-site CMS, not database-level multi-tenancy, which matters when you sell software to external customers. Structuring Content-Types, taxonomies, roles, and publishing workflows decides whether five internal brands can share one Strapi instance without overwriting each other's content.
In brief:
- Multi-site CMS architecture is mainly a content modeling problem: the Content-Type design determines whether brands can share a platform cleanly.
- Modeling brand as a relation or as a content boundary shapes permissions, publishing, and API queries.
- Design shared and brand-specific taxonomies deliberately; letting each brand define its own tags leads to content sprawl.
- Scope editors to brand boundaries through roles instead of separate instances when the content model allows it.
Multi-Site CMS vs. Multi-Tenant CMS: What's the Difference
The two terms describe different problems with different failure modes, and vendors use them loosely enough that teams often solve the wrong one.
Infrastructure isolation vs. content model isolation
Multi-tenancy isolates tenant data so external customers cannot see each other's data, using infrastructure-level or logical controls depending on the architecture.
Multi-brand work separates editorial authority inside a shared content model. Strapi's multi-tenancy guide draws the line: one Strapi instance serving multiple frontends with a shared dataset "is fully supported and essentially what 'headless CMS' means," while one instance hosting multiple independent projects "is closer to true multi-tenancy and is not supported by Strapi out of the box." A cross-brand content leak is a governance problem you fix with roles. A cross-tenant data leak is a breach.
When shared instance is the right call vs. separate instances
Start with schema overlap. Identical page types, components, search engine optimization (SEO) fields, media rules, and navigation favor a shared schema, along with shared assets and a shared editor pool. Different page models, legal fields, available integrations, or release timing favor separate site roots.
Treat infrastructure and data-isolation requirements as separation criteria when evaluating whether separate instances should be hosted independently. Workflow control alone rarely justifies it, though review processes that differ completely across teams can be one factor. If Brand A's editors simply shouldn't publish Brand B's pages, roles solve that more cheaply than a second instance. Organizations that must never share editors or assets are the exception and belong on separate instances.
Mapping Your Brand Portfolio Before Building Anything
Every decision downstream, from field names to role definitions, depends on knowing what your brands share and how they relate to each other. Do that inventory first.
Shared content vs. brand-specific content: the audit you need first
The audit should produce one document showing what is shared, what is local, what each brand owns, what is inherited, and what comes from another platform.
Typical shared candidates are legal and compliance content, product specification models, global company information, global navigation components, and product descriptions from a shared catalog. Brand-specific content is usually campaign work, brand voice, and locally adapted editorial. For each item, record the owner, the last revision date, whether taxonomy terms are applied consistently, and which keywords each brand targets, so sibling brands don't compete for the same terms.
Brand relationship models: parent-child, sibling, and federated
In a parent-child model, a corporate brand controls shared content and sub-brands inherit it. Sub-brand teams read shared content and write only inside their own brand, while the corporate team locks down the assets that define the brand.
Sibling brands share infrastructure but not editorial control. Each brand runs on its own day to day, so the relation between brands is thin and the content model can be too. Each brand's roles get full create, read, update, and delete access to their own Content-Types and none to a sibling's.
Federated portfolios sit between the two. In practice, central teams can define the content structure and governance rules while regional teams publish within those boundaries. That calls for a global content layer that brand teams extend with local variations, plus permissions that separate structure ownership from content ownership. Brands keep editorial independence inside that shared structure.
How many brands before you need a different architecture conversation
Brand count matters less than overlap. Three independent brands whose content, teams, and permissions barely overlap may prefer separate projects. 15 regional brands may want one shared architecture so they don't rebuild the same product models and integrations 15 times.
In practice, the more brands diverge in structure and the less they share, the stronger the case for a disciplined hub-and-spoke model or separate instances. A single instance serving many brands risks hitting limits on the number of Content-Types and piling up duplicate content. Strapi has no built-in federation layer, so aggregating content across Strapi instances is custom work.
Content Type Architecture for a Multi-Site CMS
Once the audit tells you what's shared, the Content-Type design turns that list into schema. The core question is whether brand lives inside your types or around them.
Designing shared content types that brands inherit
Global navigation, legal pages, press releases, and job listings from a shared pool are the usual shared Collection Types. Strapi's Content-Type Builder lets you create and update content types and add fields, but the official docs do not describe per-brand customization of a shared type without cloning it. Components are "reusable sets of fields, that can be quickly added to content-types, dynamic zones but also nested into other components." Dynamic Zones let administrators compose and rearrange Components per entry. A shared Article can carry its core fields plus a Dynamic Zone holding brand-specific Components, such as one brand's promo block and another's legal disclaimer.
Different Components in one Dynamic Zone cannot share a field name with different types, or an enumeration field with different values, so agree on shared field names first. Strapi 5 also requires on fragments when populating Dynamic Zones (populate guide).
Brand-specific fields and selective overrides
The alternative is one Article type per brand, which duplicates every schema change. On platforms built around per-brand stacks, a new global field on the shared product model must be propagated to every brand stack. Cross-brand queries also get harder because there is no single collection to query.
A shared legal page can carry an optional brand-override Component, which each brand fills only where its wording differs.
Modeling brand as a relation vs. as a content boundary
Brand-as-relation means every content item has a brand relation field and queries filter at runtime. A sensible default is to start with a shared content domain model (product, campaign, article, policy) and apply brand and region as first-class dimensions, not forks. In Strapi 5 the brand-scoped query is a deep filter:
GET /api/articles?filters[brand][name][$eq]=BrandA&populate[brand]=*Strapi's REST API doesn't populate relations by default, so populate is required, and the populated Content-Type needs the find permission or it comes back empty. Per the filters documentation, slow deep filters on large datasets need a custom route with an optimized query, and filters can't target polymorphic structures such as Dynamic Zones.
Brand-as-boundary puts each brand's content in its own namespace.
The relation model wins when brands share material and one record should serve several of them. The boundary model wins when permissions must be airtight and brands share almost nothing. In Strapi, a boundary means either separate Collection Types per brand or separate instances, because there is no space concept in between.
Taxonomy, Tags, and Locale Strategy Across Brands
Classification and localization look like editor-level decisions, so multi-brand models tend to degrade here as inconsistencies accumulate.
Shared vs. brand-scoped taxonomies
Nielsen Norman Group defines a taxonomy as "a closed list of acceptable terms that are arranged hierarchically," a controlled vocabulary whose terms content creators cannot invent. In Strapi, model terms as relation-backed Collection Types, as Strapi's content modeling guide does with an FAQ Collection Type holding a manyToOne relation to FAQ-Category.
Split the vocabulary in two. A global taxonomy (product categories, topic clusters, industry tags) is shared across brands and drives cross-brand discovery and reporting. Each shared term exists once and is filtered by brand instead of copied per brand. Brand-scoped taxonomies (campaign tags, regional tags, brand categories) live in separate Collection Types that only that brand's editors can write to.
Keep both vocabularies out of one flat, free-text tag system and model each term as a referenced document.
Locale-per-brand vs. locale-per-market
Locale-per-brand gives each brand a fixed locale set (Brand A publishes EN-UK, Brand B publishes FR-FR). The model then ties allowed locales to the brand relation, so each brand's entries exist only in its own locales. Locale-per-market treats locales as independent of brand, so any brand can operate in any market. Entries localize independently and brand stays a separate dimension, so brand times locale combinations multiply.
Strapi 5 pushes you toward locale-per-market. Per the Internationalization documentation, locales are set at the application level, with one list and one default locale for the whole instance, and no custom locales beyond the 500+ pre-created options. Internationalization (i18n) is free but disabled by default, and you enable it per Content-Type and per field.
To approximate locale-per-brand, add locale-scoped permissions. The role-based access control documentation lets you "define also what permissions should be granted for each available locale," so Brand B's editors can be scoped to fr. That scoping works at the Content-Type level, while finer restrictions on individual translators may still require custom development or Strapi plugins, per Strapi's own i18n guide.
Content can only be managed one locale at a time, so simultaneous multi-locale publishing needs Releases (Growth and Enterprise). locale=all is gone, so queries name a specific locale, and publish() in the Document Service API accepts a locale.
Roles, Permissions, and Editorial Workflows per Brand
Content model decisions from the previous sections determine how much of your permission scheme the platform enforces for you and how much you build.
Scoping content editors to brand boundaries
Strapi 5 Role-Based Access Control (RBAC) is free. It covers create, read, update, delete, and publish permissions per Content-Type, restrictions per field, per-locale scoping, and two built-in conditions: the administrator is the creator, or shares the creator's role. If you modeled brand as a boundary with separate Collection Types, that is enough.
Brand-as-relation is harder. No setting in the Admin Panel scopes entries to only those where brand = Brand A, and a GitHub issue states plainly that "Strapi is not built to handle multi-tenancy." The supported path is a custom condition registered through conditionProvider (RBAC configuration guide), whose handler returns a boolean or a query object that filters entries:
// src/index.js (bootstrap)
await strapi.admin.services.permission.conditionProvider.register({
displayName: 'Brand A content',
name: 'brand-a-content',
async handler(user) {
return { brand: { documentId: user.brandId } };
},
});The handler returns a query object, so editors see only entries whose brand matches, on the free Community plan. The third-party strapi-plugin-multi-tenant packages a similar approach. Strapi trades native UI convenience for no license cost plus developer time.
Cross-brand content sharing and approval
When corporate pushes a legal update to every brand site, shared Collection Types should belong to a corporate role. A Brand Editor role gets read-only access to shared content, a Corporate Publisher role holds publish rights, and field-level permissions can leave some fields open to brands.
When Brand A republishes a Brand B article, create a new entry linked to the original and route it through a Review Workflow stage that only Brand B's role can move out of, so the source brand signs off.
Strapi's documentation pages don't describe a native content-inheritance mechanism, so expect custom webhook work if you need it.
Publishing calendars across brands
Draft and Publish is a core feature toggled per Content-Type, and Releases depend on it. The Strapi 5 breaking changes made status a reserved attribute, so give your editorial-state field a different name on Draft and Publish types.
Independent schedules come from Releases (Growth and Enterprise). Each brand creates its own release with its own date, time, and timezone. A release is Blocked only when its own entries "haven't reached the required stage for publishing," so Brand A's stalled launch never holds up Brand B.
Different approval chains need Review Workflows (Enterprise only). Assign a distinct workflow to each brand's Content-Types and set, per stage, which roles can move content out and which can move it in. A transition needs both permissions, so Brand A editors cannot advance Brand B's content. Content Manager list views filter by Assignee and Review Stage, so each brand can see its own queue.
Common Multi-Brand Architecture Patterns
Two useful governance shapes are the hub-and-spoke and federated models, with separate CMS instances as a third option when neither fits.
The hub-and-spoke model
A central team owns the shared foundation and brands extend it. Content flows one way, hub to spoke. In Strapi terms, shared Collection Types and the global taxonomy are writable only by the corporate role, while brand roles read shared types and have full access to their own. This fits when the parent-child hierarchy is real.
The federated model
Federated brands keep editorial independence and share infrastructure plus whatever a federation agreement permits. In Strapi, model syndication with a shareable boolean on the source entry and a syndicatedFrom relation on the copy, so lineage stays visible. The risk is weak governance. Agree in writing on what can be shared, and by whom, before the first syndicated entry. This model suits true sibling brands.
When to split into separate CMS instances
Split when most fields are conditional per brand, or when the residency rules covered earlier require it. Strapi's pseudo-multi-tenant approach requires "a separate database, theming, and separate domain for each Strapi instance," and on Strapi Cloud each instance is its own per-project subscription. You also lose cross-brand references entirely, and every schema change has to be repeated and maintained in each instance.
Avoiding the Pitfalls That Break Multi-Brand Setups
Two failures to guard against are a content model nobody governs and roles nobody re-checks.
Content sprawl and duplication
Sprawl starts when a brand team can create a second Article type because the first lacked their field. Competing taxonomy trees and orphaned entries nobody owns follow.
Strapi offers a structural control. The Content-Type Builder runs in the Development environment only and requires at least Read permission under Roles > Plugins - Content Type Builder. Give that permission to one content model owner and route new type requests through them. For recurring audits, Nielsen Norman Group recommends 3-month intervals between content reviews.
Permission bleed between brand editors
Misassigned roles let Brand A editors see or publish into Brand B collections, and nobody notices until a wrong-brand page goes live. Create a test user for every role, log in as each, and try the actions that role shouldn't allow. For relation-based scoping, also log in as Brand A and request a Brand B documentId directly.
Review role assignments whenever someone changes teams, and name one owner for role changes in the team wiki.
Decide the Architecture Before You Open the Content-Type Builder
A multi-site CMS that holds up over years is shaped by decisions made before the first Collection Type exists. Choose the brand relationship model (parent-child, sibling, or federated), audit what's shared versus brand-owned, pick brand-as-relation or brand-as-boundary with its permission consequences understood, and set role boundaries before editors log in. Teams that skip the audit usually find out when a legal update needs to land on five brand sites and lives in five different places.
When you're ready to build, Strapi Cloud runs each Strapi project as a managed instance. If you'd rather start from working code, Launchpad is a production-grade Next.js integration and Strapi 5 project you can clone and extend with the brand relation, shared Collection Types, and roles described above.
