Why one headless CMS for many brands is a governance problem before it is a software choice
A group running several brands or country sites can serve all of them from one headless CMS instance, provided the content models, roles and locales are designed on purpose before anyone installs anything. Strapi, Payload and Directus can each fit this job. The deciding factors are the team's skills, where the platform will be hosted, and which paid features the group needs, not a feature checklist. The hard questions are about tenancy: who owns a shared product component, who may publish a brand's pages, and what happens when one country's legal copy must differ from another's. Those are governance decisions that the software will enforce but cannot make for you.
Start by writing down the ownership rules for three layers: shared components (navigation, footers, legal blocks), brand-specific content types, and locale variants. Then map each layer to permissions. In Strapi and Directus, that usually means role-based permissions scoped to content types and fields, while Payload expresses similar rules through field-level access control defined in code. Test the rules with a real editor account from each brand before launch, because a permission that looks correct in a design document often exposes another brand's entries in practice. Confirm with each vendor exactly how a role can be limited to one brand's entries, since that capability is not uniform across products. Licensing and edition choice belong in the same review. Strapi's SSO for administrator login is an add-on on its Growth self-hosted plan and included in Enterprise, while audit logs and review workflows are Enterprise features, according to Strapi's pricing page. If brand legal teams need sign-off and an audit trail of who approved what, those requirements shape the edition choice from the start. Check current terms directly with each vendor, as plans change; the Strapi self-hosted pricing page lists the current Strapi tiers.
What a multi-brand content platform must satisfy and what it means for the build
This table maps each requirement a multi-brand or multi-country content platform must meet to the source of that requirement and the build decision it forces. Read each row as a question to answer before choosing a shared or per-brand model. The main takeaway is that editor isolation, locale scoping and admin access are design decisions made in the content model and roles, not settings added after launch.
| Requirement | Source or constraint | Build consequence |
|---|---|---|
| Per-brand editor isolation | Brand governance and contractual separation between brands sharing one platform | Scope roles by brand or site so editors see and publish only their own collections and entries, and test this with a non-admin account per brand |
| Shared versus brand-specific content models | Brand teams need different fields, but group legal and product data should stay consistent | Put common components such as legal footers and product specs in shared collections, and keep brand-only fields in per-brand collections or a brand attribute |
| Locale variants per country site | Country sites need translated copy, local legal wording and separate publishing dates | Model locales explicitly, define fallback rules, and grant publishing rights per locale rather than per whole site |
| Admin SSO for editors | Group identity policy requires central login, joiner and leaver control for every brand's editors | In Strapi, SSO covers admin panel login only and is a paid add-on on Growth or included in Enterprise, so confirm which plan you need before design |
| Audit trail of content changes | Brand and legal teams need to show who changed or approved a published claim | Confirm which change history, review workflow and audit log features each product and plan provides, since some sit in paid editions |
| Public-sector and university accessibility | The ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts | The CMS does not guarantee accessibility, so the front ends it feeds need accessibility testing per brand and template, with the compliance date set by the entity's population |
| One API, one front end per brand | Brands need different designs, navigation and release cadences while sharing content | Serve each brand's front end from the same headless API with brand-scoped queries, so design changes do not require CMS changes |
| Database and hosting support for the chosen product | Each product lists supported databases and runtimes, and self-hosted operations must match them | Confirm the database engine and Node.js or other runtime versions in the vendor documentation before sizing the shared instance and its backups |
Which headless CMS fits a multi-brand estate and why
A group running several brands or country sites needs to decide how much content, users and permissions to share. The three products below handle that boundary differently, so the license, database, edition and role features each one needs should be checked before a single-instance or per-brand design is chosen.
Strapi: MIT core with paid admin controls
The Community Edition is MIT licensed, but SSO and audit logs for the admin panel sit in paid tiers: SSO is an add-on on Growth and included in Enterprise, while audit logs and review workflows are Enterprise features. Strapi supports PostgreSQL, MySQL, MariaDB and SQLite only, not MongoDB. Ask the vendor whether multi-brand separation of content types, locales and admin roles is handled by one instance or requires separate projects, and confirm it against the current documentation.
Payload: code-defined models in Next.js
Payload is MIT licensed and installs into an existing Next.js app, so brand sites and the CMS can share one codebase and one type system. It supports MongoDB, PostgreSQL and SQLite, and its built-in features include localization, versions and drafts, and field-level access control. This suits a group whose engineers own each brand's front end. Confirm how access rules and localization scale across dozens of brands, and whether a separate tenant per brand is needed.
Directus: SQL data and native role permissions
Directus is licensed under the Monospace Sustainable Core License, which permits internal use and professional services to deploy or host it for a licensee, but it excludes a competing use against the vendor's paid offerings. It connects to an existing SQL database through DB_CLIENT, including PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, SQLite and CockroachDB. Its native MCP server and AI Assistant follow the same role permissions as human users, which should be tested per brand role.
One instance or one per brand
A single instance shares infrastructure, model governance and shared assets such as media and components, but a misconfigured role can expose one brand's drafts to another brand's editors. One instance per brand isolates data and upgrades, at the cost of running, patching and backing up several systems. A common pattern is a shared instance for global components with separate projects for brands that have strict data or release separation. Test the chosen split with a role matrix before go-live.
Roles that keep brands apart
Each brand's editors should see only their own collections, locales and media folders, while a central team manages shared models. Check whether each product can express brand-scoped roles at the record level or only at the content type level, and whether that scope also applies to API tokens, webhooks and preview links. Ask the implementation partner to write a test for each brand's editor that confirms no cross-brand read or publish is possible.
Localized variants across sites
Country sites often need the same content in different locales with different legal text and fallbacks. Payload's built-in localization and Strapi's and Directus's locale features differ in how they store translations and how fallback is configured, so the choice affects editorial workflow and API shape. Confirm how each product handles per-locale publishing rights, translation status and URL generation before modeling content for every market.
How a multi-brand CMS rollout moves from model design to brand cutover
The sequence turns a group's brands and country sites into one governed content platform, with each brand proven on a pilot before the rest move in waves. Every phase closes with a written artifact that the next phase depends on.
Establish governance and inventory every brand
Start by listing each brand, country site, domain, language, content type, editor group and existing system that holds content today. Brand leads, the platform owner and the security lead agree who can approve model changes, who owns each brand's content, and who can grant admin access. The step is done when the brand inventory and a signed governance charter exist, and every site has a named business owner and a named technical owner.
Design the shared and per-brand content models
Separate what all brands genuinely share, such as global components, legal footers, taxonomy and media conventions, from what varies by brand, such as product names, tone-specific blocks and campaign types. Decide which model changes are shared and which may be local, and test the model against real content samples from two brands. The output is an approved model map that shows each collection or content type, its owner, and whether it is shared, brand-specific or locale-specific.
Build the role and locale matrix
Map each editor role to the brands, countries, locales and actions it may perform, including create, edit, publish, approve and manage media. Define which roles can see shared content but not change it, and how fallback locales appear to editors and visitors. Confirm in your chosen platform how field-level and document-level permissions handle these rules, because the matrix is only as strong as what the platform enforces. The output is a role matrix tested per brand with test accounts that try to cross brand boundaries and fail.
Prototype the front end and preview for one brand
Connect one brand's front end to the content API, set up preview for drafts, and confirm that the published output matches the approved design and URL structure. Check that caching and publish events refresh only the intended brand's pages. The step is done when an editor from the pilot brand can draft, preview and publish a full page set without help from the platform team.
Migrate and cut over the pilot brand
Move one brand's content, media and redirects into the new models, reconcile counts and spot-check high-traffic pages, and run the old and new sites in parallel for a defined window agreed in the plan. Editors from that brand work in the live platform while the team records every defect and fix. The output is a cutover record for the pilot site that lists the data reconciliation results, redirect coverage, sign-off by the brand owner, and the rollback steps that were tested.
Move the remaining brands in waves
Group the remaining brands into waves based on the inventory, starting with brands that share the most models with the pilot. Each wave repeats the migration, role testing and cutover steps, and any model change needed by a later brand goes through the governance charter before it is built. The step is done when every brand has its own cutover record and the shared model map reflects the final state.
Hand over with runbooks and ongoing ownership
Document how to onboard a new brand or country site, how to request model changes, how to rotate editor accounts and how to restore the platform from backup. Train the internal owners who will run the platform, and agree who handles upgrades, security patches and support afterward. The handover is complete when runbooks are reviewed by the platform owner, each brand owner accepts their runbook, and the support model is written down.
Questions brand and digital leads ask before choosing a multi-site CMS
Should we run one headless CMS instance or one per brand?
For most groups with brands that share a content model, components and a delivery team, one instance is the better starting point, because shared models, shared components and one upgrade path reduce ongoing work. Separate instances fit better when brands must be fully isolated for legal, contractual or data residency reasons, when they have unrelated release calendars, or when one brand's traffic could affect another. Strapi, Payload and Directus all support organizing content so each brand's editors see only their space, but the isolation you need decides the architecture. Test the choice against your sharpest constraint, then confirm it with your legal and security teams before you build.
What do our content owners need to provide before a multi-brand build starts?
Brand and country leads need to agree on what content is truly shared, what each brand varies, and who approves changes to shared models. The build also depends on an inventory of existing sites, page types, locales, legal disclaimers and media assets, plus a named owner per brand who can make decisions quickly. Ask each brand to supply sample content for its hardest cases, such as regulated disclaimers or unusual product data. Without these inputs, the content model usually grows by exception, which is the most common reason multi-brand projects slow down.
How long does a multi-brand CMS build take, and what drives that?
Duration depends mainly on the number of brands, the number of distinct page types and locales, the volume of content to migrate, and how many approval stages each brand requires. Front-end work for each brand often takes longer than the CMS configuration itself. Fixed-scope work starts with an agreed written scope, so timelines should come from that scope, not from a generic estimate. Ask any partner to show the phases, the content types in each phase and the decisions that must close before each one.
Can our internal team build a multi-brand headless CMS without a partner?
A capable internal team can build a multi-brand CMS, especially if it already runs Node.js or a similar stack and has done a headless project before. The gaps usually appear in content modeling for several brands, role design for editors across brands, localization rules, database operations, upgrades and security hardening. Assess your team against those specific skills, then decide which parts you keep in-house, such as content modeling and editorial workflow, and which you contract out, such as platform hardening or migration. Any partner should show its work in writing so your team can run the platform after handover.
Which multi-brand features need a paid Strapi plan?
Strapi's Community Edition is free and includes REST and GraphQL APIs, unlimited entries and unlimited API calls. Single sign-on for administrators is an add-on on the Growth plan and included in Enterprise. Audit logs and review workflows are Enterprise features, while content history and releases start at the Growth plan. Per-brand editor separation and roles should be checked against your own requirements, since the current Strapi self-hosted pricing page lists the plan boundaries. Confirm these details on the pricing page before you budget, because plan terms change.
How does licensing affect agencies that build sites for several brands?
Licensing decides whether an agency can build, host and modify the platform for each client without extra permissions. Strapi's Community Edition code outside the ee directories is MIT licensed, while ee directories fall under the separate Enterprise license, so agencies must check which features touch that code. Directus is licensed under the Monospace Sustainable Core License, which permits internal use and professional services to deploy or host it for a licensee, but excludes a competing use. Payload is MIT licensed. Have counsel review the exact terms against your client contracts and the features you plan to use.
How do we keep one brand's editors out of another brand's content?
Use role-based access control scoped to each brand's content and media, and test it with real editor accounts before launch. Strapi, Payload and Directus each handle permissions differently, so the test plan should cover reads, writes, publishing and media uploads for every role. Keep shared components under a central team and make brand-specific fields explicit in the model. Ask for a permissions matrix and a test report as deliverables, and confirm which of these controls depend on a paid edition before you commit.
What to ask an implementation partner before signing
Start by asking how the partner models shared versus brand content. Ask for the proposed content model on paper before any build: which types live in shared collections (legal footers, navigation patterns, global components) and which are brand-owned, how a brand-specific field is added without forking the schema, and how a locale or country variant is attached to a parent entry. Ask whether the design sits in code (Payload collections) or in a managed schema (Strapi content types or Directus collections), and what happens to that design when a brand asks for a new content type next year. Request a written scope that names each collection and its owner.
Next, ask how role scoping is tested for each brand, not just described. A credible partner will name the roles, the permission matrix per brand and locale, and the test cases that prove an editor for one brand cannot read, edit or publish another brand's entries or media. Ask how the test plan covers the Strapi admin role settings, Directus role and permission rules, or Payload field-level and collection access controls, and whether the tests run again after every schema change. Ask who signs off the results. For editor login, ask whether SSO to the admin panel is in scope, which identity provider and group mapping is used, and whether the paid self-hosted edition needed for it is included in the quote. Also ask how audit evidence (who changed what and when) is captured, and confirm which product edition provides it, because the answer differs by platform and plan.
Then ask how the partner plans a major version upgrade, using Strapi 4 to 5 as the reference case. Strapi v4 reached end of life on April 30, 2026, so any inherited v4 estate needs a dated upgrade plan. Ask for the database backup and restore rehearsal, the codemod and data migration run, the handling of the changed response format and the Document Service API, and the rollback approach, since the migration docs say downgrading is not supported. Finally, confirm who owns the front-end build. Ask whether the brand sites are built by the partner, by each brand's agency, or by an internal team, who maintains the shared component library, and who answers for accessibility of the output. Ask for a named test plan with a written scope, owners, acceptance criteria and the environments used for each brand before you sign.
Integration points that multi-brand CMS deployments must plan for
A multi-brand content platform touches identity, data protection, delivery, search, translation and consent tooling at once, and each touchpoint has a decision that affects every brand on the instance. Settle these before the content model is built, because changing them later reaches every site that reads from the CMS.
Identity provider for administrators
Decide which identity provider authenticates brand editors and administrators, and how roles map to groups from that directory. Strapi's SSO covers administrator login to the admin panel through an identity provider, with auto-registration, a default role and an optional local login lock-out. Confirm whether your edition includes SSO, because Strapi lists it as an add-on for Growth and as included in Enterprise. End-user accounts for site visitors are a separate concern handled by each product's user model.
Database and backup regime
One instance holding many brands means one database is a shared failure point, so the backup schedule, restore tests and retention rules apply to every brand at once. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and it does not support MongoDB. Back up the database before any major upgrade, because the Strapi migration docs say downgrading is not supported. Ask who owns restore testing and how a single brand can be restored without rolling back the others.
Media storage and CDN
Brand logos, product imagery and campaign video usually sit in one media library, so storage layout and delivery paths determine how easily each brand's assets stay separated and cacheable. Decide whether assets live on local disk, object storage or a third-party provider, and whether each brand gets its own bucket or path prefix. Confirm how cache invalidation runs when an editor replaces an image, because a stale asset can persist on the edge for a brand that never asked for the change.
Search across brands
Site search for several brands raises a tenancy question: one index with filters, or one index per brand. A shared index is simpler to operate, but it requires every query to carry a brand filter so results from one brand never appear on another brand's site. Separate indexes isolate data and tuning at the cost of more indexing jobs and more places to check when content is unpublished. Confirm how unpublished or draft entries are excluded from the index on each publish and unpublish event.
Translation handoff
Country sites and brands often send content to agencies or machine translation, and the CMS must hold source and translated versions without mixing them up. Decide which locale fields are written by translators, which roles can approve a translation, and how a changed source entry flags its translations as stale. Confirm that the translation tool can read and write the chosen content model through the API, and that exported files carry entry IDs so imported text returns to the correct brand and locale.
Analytics and consent tooling
Each brand site will load analytics, tag managers and consent banners, and those scripts often read content identifiers or page metadata from the CMS. Decide which consent platform governs each brand's regional sites, and whether CMS-driven pages must pass consent state to tags before they fire. Keep form submissions and tracking identifiers out of the CMS content model unless you have a documented need, and confirm with your privacy team which regional rules apply to each country site.
Evidence auditors and brand owners ask for and which component produces it
This table maps each piece of evidence that auditors and brand owners request to the component that produces it, and whether that component needs a paid Strapi edition or can be built through configuration. Read it as a checklist to confirm with your chosen platform before the first brand goes live, because the answer for audit logs and review workflows changes with the edition you license. DeployOpen prepares this evidence for assessment, but auditors and certification bodies issue the actual conclusions.
| Evidence | Where it comes from | What to confirm before go-live |
|---|---|---|
| Role matrix by brand and site | Role and permission definitions in the CMS, exported as configuration and reviewed per brand owner | Each brand editor role is limited to its own collections, locales and media folders, and a test account confirms it cannot read or publish another brand's entries |
| Access review records | Admin user lists, SSO group mappings and role assignments captured on a fixed schedule | Who approves a new brand editor, how removals are logged, and whether admin SSO is in place (a Growth add-on or Enterprise feature in Strapi self-hosted plans) |
| Audit log of content and admin changes | Strapi audit logs are an Enterprise feature per the self-hosted pricing page; Payload and Directus logging must be confirmed or built through hooks and database log configuration | Whether the chosen edition records who changed which brand's entry, when, and from which account, and where those logs are stored and retained |
| Version history and publishing records | Content history and releases start at the Strapi Growth plan per the pricing page; Payload offers versions and drafts natively | That every brand's published version can be traced to an approver, a timestamp and a prior revision, including shared components that feed several sites |
| Backup and restore records | Database and media storage backups run by the hosting team, with restore tests logged | Restore tests cover a single brand's content without overwriting other brands, and the backup includes both the database and the media store |
| Accessibility test results for published front ends | Automated and manual WCAG 2.1 AA test reports for each brand's front end, which the CMS does not produce by itself | Test results are tied to the release that shipped, and each brand or country site is tested, not only the primary domain |
| Change records for schema and model updates | Version-controlled content model code and migration scripts reviewed before deployment | Shared model changes are approved by the platform owner and the affected brand owners before rollout to every site |
How DeployOpen scopes and builds a multi-brand content platform
DeployOpen plans, implements, hardens and supports self-hosted open-source headless CMS platforms inside the client's own cloud accounts, data centers or air-gapped networks. DeployOpen is a Chainscore Labs company. Work runs under fixed-scope written agreements, and a quote follows from that written scope rather than from a published price list. The first phase is usually a scoping exercise that fixes the list of brands, country sites and locales, the shared and per-brand content types, the editorial roles for each brand, and the front ends that will read from the API. Each of those decisions changes the build, so the scope document should name them explicitly. Ask the partner to show, in writing, which of these items are inside the quoted work and which are assumed to be handled by your own teams.
The build phase turns the scope into a working instance. For the roles, DeployOpen builds and tests the permission model against real test accounts from each brand, confirming that an editor for one brand cannot read, publish or preview another brand's entries through the admin panel or the API. Where a platform supports it, administrator sign-in is connected to your identity provider, and the test plan covers the paths that a single misconfigured role would expose. Where the CMS feeds public front ends, security testing can cover the CMS API, the admin panel and the front ends together, including authorization checks on draft content and preview links. Ask the partner which test cases are documented, who signs off the role matrix, and how results are retained as evidence.
After launch, the platform needs upgrades, patches and a named support path. DeployOpen offers retainers for upgrades and ongoing support, which are priced separately from the initial build and should be requested as their own line in a quote. Ask what the retainer covers for each product you select, how major version changes are handled, and how the partner plans for product release cycles and end-of-life dates. DeployOpen does not issue audit reports, attestations or certifications, so compliance evidence for your organization comes from independent assessors. Your job in procurement is to confirm the scope, the test evidence and the support terms in writing before any work starts.
