# How do you run several brands and sites from one Sanity setup?

Reviewed by Martin Dejnicki · facts verified 25 October 2026 · canonical: https://deploi.ca/sanity/use-cases/multi-brand-content-hub

Experience: Reviewed from Sanity's documentation, not production use.

## Short answer

One Sanity project runs several brands and sites from one Sanity Studio, and the plan decides how far apart they sit. Growth includes 2 datasets, plus up to 2 more at $999 a month each ([Sanity pricing](https://www.sanity.io/pricing), October 2026). Its built-in roles cover every dataset, so locking editors to one brand needs Enterprise custom roles ([Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles), October 2026).

- **Datasets on Growth:** 2 included, 2 more at $999 a month each. Extra datasets are a Growth add-on billed per dataset per month, and Sanity charges only once you create the dataset ([Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Extending the Growth plan with paid add-ons](https://www.sanity.io/docs/platform-management/growth-plan-add-ons))
- **Keeping editors to one brand:** Enterprise custom roles. Growth's Editor and Developer roles read and write every dataset, and Contributor writes drafts in every dataset, so a workspace per brand separates screens, not access ([Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles); [Sanity, Plans that scale with you](https://www.sanity.io/pricing))
- **Shared content across datasets:** Cross-dataset references, Enterprise only. Same project only, one target dataset per field, no links to drafts, and dereferencing works in GROQ but not GraphQL ([Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references); [Sanity, Plans that scale with you](https://www.sanity.io/pricing))
- **Document quota on Growth:** 25k documents across all datasets. Every brand draws on one project allowance, drafts included. Growth has no document overage: the $299 a month Increased quota add-on lifts it to 50k, and past that the path is Enterprise ([Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments))

## Deploi's call

Start with one project, one Sanity Studio and a workspace per brand, and choose datasets by access, not by brand count. On Growth, put brands whose editors trust each other in one dataset with a brand field, and give a brand its own dataset only when its content or assets must stay apart. Buy Enterprise when editors must be locked to one brand.

**BUILD: Run the brands from one Sanity project when**

- The brands share most of their content model and one team owns the schema.
- Editors may see each other's brands, because Growth's built-in roles cover every dataset, or you will buy Enterprise for custom roles.
- Two to four datasets cover your brands and environments, the most Growth allows ([Sanity pricing](https://www.sanity.io/pricing), October 2026).
- Shared content can live in the same dataset, or be linked by URL until you need references.

**DEPENDS: Price Enterprise or separate projects first when**

- Each brand's editors must be blocked from other brands' content.
- Brands must reference shared documents across datasets instead of copying them.
- Brands times environments needs more than 4 datasets.
- Each brand has its own developers, front end and release cycle.

## When does one Sanity setup beat a separate CMS per brand?

One Sanity setup beats a separate content management system (CMS) per brand when the brands share a content model, a central content or engineering team, and content such as legal copy or product data. Sanity Studio takes an array of workspace configurations, so one deployed Studio gives each brand its own editing space with its own schema, structure and plugins ([Sanity Docs, Workspaces](https://www.sanity.io/docs/studio/workspaces), October 2026). You maintain one codebase, one schema review and one set of integrations instead of one per brand. That consolidation is the core of [consolidating several CMSs onto one platform](https://deploi.ca/sanity/use-cases/cms-consolidation).

A separate Sanity project per brand has a documented price. Sanity's multi-tenancy guide says separate projects give complete separation of members and settings, but they prevent referenced content, and common settings must be duplicated by hand ([Sanity Docs, multi-tenancy guide](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), October 2026).

> **When a CMS or project per brand is the better call**
>
> - Each brand has its own developers, release cycle and front end, and nobody would own a shared schema.
> - The brands share almost no content types, so one schema would be a union of unrelated models.
> - A brand may be sold or spun out, and you want its content and settings to leave as one unit (Deploi's judgment).

## Which Sanity capabilities make a multi-brand setup work?

Six layers of Sanity make a multi-brand setup work, and each one draws a different boundary: the workspace draws the editing screen, the dataset draws the content and asset pool, and the role draws access.

**A multi-brand Sanity setup, from what editors see to where content lives**

- Editing: Sanity Studio workspaces, Structure Builder, initial value templates
- Model: shared schema types, a brand field, references
- Shared content: cross-dataset references, Media Library
- Access: built-in roles, custom roles, dataset tags
- Storage: Content Lake datasets, private datasets
- Delivery: Graph-Relational Object Queries (GROQ) filtered by brand

The combination works because each layer can read the one below it. A workspace's schema can be a function that receives the workspace's dataset name, so one codebase loads brand-specific types only where a brand needs them ([Sanity Docs, multi-tenancy guide](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), October 2026). Structure Builder lists filter documents by a field value with a GROQ parameter, which gives each brand its own document lists inside a shared dataset ([Sanity Docs, Structure Builder cheat sheet](https://www.sanity.io/docs/studio/structure-builder-cheat-sheet), October 2026). Three capabilities in the stack need Enterprise: custom roles, cross-dataset references and the organization-wide Media Library. The rest run on Growth ([Sanity pricing](https://www.sanity.io/pricing), October 2026).

## Should brands share a dataset or get one dataset each?

Brands should share a dataset when their editors may see each other's content, and get a dataset each when content or assets must stay apart. The choice is about access more than brand count. A dataset is the boundary for the asset pool, but on Growth no built-in role stops at a dataset or a brand field. On Enterprise, custom roles can scope access by dataset or by a GROQ (Graph-Relational Object Queries) filter on a field such as brand ([Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles), October 2026).

**A brand field suits teams that trust each other, a dataset per brand separates assets, and a project per brand separates everything**

| Question | Brand field in one dataset | Dataset per brand | Project per brand |
| --- | --- | --- | --- |
| Datasets used on Growth | 1 per environment | 1 per brand, 4 at most | 2 included per project |
| Can editors open other brands' content | Yes, unless Enterprise custom roles filter it | Yes on Growth; Enterprise roles scope it per dataset | No, members are separate |
| Asset pool | Shared by every brand | Separate per dataset | Separate per project |
| Shared content | Ordinary references | Cross-dataset references, Enterprise only | Copied by hand |
| Schema changes | Reach every brand at once | Reach every brand unless the schema function branches | Independent |
| Wins when | Brands share editors and content | Assets or content must stay apart | Teams, code and releases are separate |

The "Datasets used on Growth" and "Wins when" rows are Deploi's judgment from the sources above. Sources: [Sanity Docs, How to implement multi-tenancy with Sanity](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation); [Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles); [Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references). As of 24 October 2026.

On one dataset, every new document needs its brand set. Initial value templates set it at creation, and filters on reference fields stop editors linking across brands ([Sanity Docs, multi-tenancy guide](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), October 2026). Read what Sanity datasets do and cost before you commit to a count.

## What does a multi-brand setup need on each Sanity plan?

A multi-brand setup needs Growth for private datasets and 5 built-in roles, and Enterprise for custom roles, more than 4 datasets, cross-dataset references and Media Library. Growth bills $15 per seat a month, and its extra datasets bill monthly per dataset, charged only once you create them ([Sanity pricing](https://www.sanity.io/pricing), October 2026; [Sanity Docs, Growth add-ons](https://www.sanity.io/docs/platform-management/growth-plan-add-ons), October 2026).

**Growth runs a few brands side by side; Enterprise is what keeps their editors apart**

| Capability | Free | Growth | Enterprise |
| --- | --- | --- | --- |
| Datasets | 2, public only | 2, plus up to 2 at $999 per dataset a month | Custom |
| Private datasets | No | Yes | Yes |
| Built-in roles | 2 | 5 | Custom |
| Custom roles scoped to one brand | No | No | Yes |
| Cross-dataset references | No | No | Yes |
| Media Library across projects | No | No | Paid add-on |
| Documents across all datasets | 10k | 25k, or 50k with the $299 a month add-on | Custom |
| User seats | 20 | Up to 50 | Custom |

Sources: [Sanity, Plans that scale with you](https://www.sanity.io/pricing); [Sanity Docs, Extending the Growth plan with paid add-ons](https://www.sanity.io/docs/platform-management/growth-plan-add-ons); [Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references); [Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles); [Sanity Docs, Meet the library](https://www.sanity.io/docs/media-library/interface). As of 24 October 2026.

The document quota counts every dataset in the project, so all brands draw on one allowance. Growth has no document overage: the Increased quota add-on ($299 a month) raises it to 50,000, and past that the path is Enterprise ([Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments), October 2026; [Sanity pricing](https://www.sanity.io/pricing), October 2026).

## How do you roll out a multi-brand Sanity setup?

Roll out a multi-brand Sanity setup in seven steps, starting from who may edit what rather than from the schema, because access decides the dataset pattern and the plan.

**Rolling out several brands on one Sanity project**

1. **Map brands, environments and access.** List each brand, each environment, and which editors must be kept out of which content. The content lead owns this map.
1. **Choose the dataset pattern.** Use the access map to pick a brand field in one dataset, a dataset per brand, or a project per brand.
1. **Build one shared schema.** Add a required brand field, or branch the schema function on the dataset name where one brand needs its own types.
1. **Add a workspace per brand.** Give each workspace its own basePath, a Structure Builder list filtered by brand, and initial value templates that set the brand.
1. **Lock each brand's settings document.** Pin it in the structure, hide it from the new-document menu, and remove delete and duplicate actions.
1. **Link shared content.** Use cross-dataset references on Enterprise ([Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references), October 2026); on Growth, store the link as a validated URL string or keep shared documents in the same dataset.
1. **Test with a real editor account.** Sign in with each role and check what it can read, edit and publish before you invite the brand teams.

Steps 5 and 6 are patterns Deploi runs on deploi.ca, written up as one Studio serving three workspaces and validated links across datasets.

## What goes wrong in multi-brand Sanity setups?

A screen boundary is easy to mistake for an access boundary, and that is where multi-brand setups go wrong. These five pitfalls are documented by Sanity:

- **A hidden workspace isn't a permission.** The workspace `hidden` property controls client-side visibility only and does not restrict data access ([Sanity Docs, Workspaces](https://www.sanity.io/docs/studio/workspaces), October 2026).
- **Growth roles reach every dataset.** Editor and Developer read and write all datasets, and Contributor writes drafts in all of them, so a dataset per brand doesn't fence in a Growth editor ([Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles), October 2026).
- **Permissions add up.** A member who holds a restricted custom role and the stock Editor role can still edit every document.
- **Assets ignore the brand field.** In a shared dataset every workspace sees one asset pool, and dataset asset URLs stay public to anyone who has them ([Sanity Docs, multi-tenancy guide](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), October 2026).
- **Cross-dataset references have edges.** They can't point at drafts, each field targets one dataset, and Sanity Studio lets an editor delete a document that another dataset references ([Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references), October 2026).

The sixth comes from Deploi's own build on deploi.ca: a type named "singleton" is still creatable twice until the structure, the new-document menu and the document actions all block it. The access model behind these pitfalls is covered in how Sanity roles and permissions combine.

## Deploi's point of view

**Where we disagree.** The standard advice is one dataset per brand. On Growth that spends both included datasets on brands, leaves none for staging, and still doesn't stop an Editor in one brand from changing another, because Growth's built-in roles read and write every dataset. A dataset per brand separates assets and content; it only separates people on Enterprise. The second mistake is treating a hidden workspace as a permission: Sanity's docs say it hides the screen and leaves the data reachable.

**What we've seen.** deploi.ca's Shopify sections run from one deployed Sanity Studio with three workspaces (Build vs. Buy, Builds and FAQ) over two datasets in one project, each workspace with its own schema types, structure and plugins, and content types kept apart by type prefix. These are three content hubs of one company, not three brands, but the mechanics are the same. Cross-dataset references need an Enterprise plan with the feature enabled, so deploi.ca doesn't use them: FAQ answers link to Build vs. Buy pages through a URL string field validated against a per-kind prefix: 254 of 256 live answers carry one, counted 24 October 2026. Settings documents are singletons enforced in three layers, because naming a type a singleton does nothing on its own.

**What we'd tell you to do first.** Write the access map before the schema: every brand, every environment, and which editors must be kept out of which content. That map, not the number of brands, decides the dataset pattern and whether Growth is enough.

**What we refuse to promise.** We don't promise brand-level editor isolation on Growth. Sanity's built-in roles reach every dataset, so isolation needs Enterprise custom roles or separate projects, and we say so before the build starts.

## When this answer changes

- Sanity makes custom roles or cross-dataset references available on Growth
- Sanity changes Growth's 2 included datasets or the $999 extra-dataset price
- The workspace hidden property starts restricting data access, not only the screen
- Media Library becomes available below Enterprise
- Growth's 25k document quota, or the $299 a month Increased quota add-on and its 50k ceiling, changes

## Ready to plan a multi-brand setup on Sanity?

Contact us today to work out whether your brands share one Sanity project or need several, and which plan that takes. [Contact us](https://deploi.ca/contact)

## Sources

1. [Sanity, Plans that scale with you](https://www.sanity.io/pricing), checked 24 October 2026
2. [Sanity Docs, Extending the Growth plan with paid add-ons](https://www.sanity.io/docs/platform-management/growth-plan-add-ons), checked 24 October 2026
3. [Sanity Docs, Cross-dataset references](https://www.sanity.io/docs/studio/cross-dataset-references), checked 24 October 2026
4. [Sanity Docs, Roles](https://www.sanity.io/docs/user-guides/roles), checked 24 October 2026
5. [Sanity Docs, How to implement multi-tenancy with Sanity](https://www.sanity.io/docs/developer-guides/multi-tenancy-implementation), checked 24 October 2026
6. [Sanity Docs, Workspaces](https://www.sanity.io/docs/studio/workspaces), checked 24 October 2026
7. [Sanity Docs, Meet the library](https://www.sanity.io/docs/media-library/interface), checked 24 October 2026
8. [Sanity Docs, Structure Builder cheat sheet](https://www.sanity.io/docs/studio/structure-builder-cheat-sheet), checked 24 October 2026
9. [Sanity Docs, Plans and payments](https://www.sanity.io/docs/platform-management/plans-and-payments), checked 24 October 2026