Use cases
How do you run several brands and sites from one Sanity setup?
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, October 2026). Its built-in roles cover every dataset, so locking editors to one brand needs Enterprise custom roles (Sanity Docs, Roles, October 2026).
- Datasets on Growth
- 2 included, 2 more at $999 a month eachExtra datasets are a Growth add-on billed per dataset per month, and Sanity charges only once you create the datasetSources: Sanity (Plans that scale with you); Sanity Docs (Extending the Growth plan with paid add-ons)
- Keeping editors to one brand
- Enterprise custom rolesGrowth'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 accessSources: Sanity Docs (Roles); Sanity (Plans that scale with you)
- Shared content across datasets
- Cross-dataset references, Enterprise onlySame project only, one target dataset per field, no links to drafts, and dereferencing works in GROQ but not GraphQLSources: Sanity Docs (Cross-dataset references); Sanity (Plans that scale with you)
- Document quota on Growth
- 25k documents across all datasetsEvery 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 EnterpriseSources: Sanity (Plans that scale with you); Sanity Docs (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.
BuildRun 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, October 2026).
- Shared content can live in the same dataset, or be linked by URL until you need references.
DependsPrice 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, 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.
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, October 2026).
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.
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, 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, 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, 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, October 2026).
| 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 |
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, 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, October 2026; Sanity Docs, Growth add-ons, October 2026).
| 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 |
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, October 2026; Sanity 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
- 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.
- 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.
- 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.
- 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.
- Lock each brand's settings document. Pin it in the structure, hide it from the new-document menu, and remove delete and duplicate actions.
- Link shared content. Use cross-dataset references on Enterprise (Sanity Docs, Cross-dataset references, October 2026); on Growth, store the link as a validated URL string or keep shared documents in the same dataset.
- 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
hiddenproperty controls client-side visibility only and does not restrict data access (Sanity Docs, 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, 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, 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, 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
Sources
Every source opened and checked on 25 October 2026.
- Sanity, Plans that scale with you
- Sanity Docs, Extending the Growth plan with paid add-ons
- Sanity Docs, Cross-dataset references
- Sanity Docs, Roles
- Sanity Docs, How to implement multi-tenancy with Sanity
- Sanity Docs, Workspaces
- Sanity Docs, Meet the library
- Sanity Docs, Structure Builder cheat sheet
- Sanity Docs, Plans and payments