The challenge
Many organizations run multiple public websites - from a handful (e.g. a separate site for each of a holding company’s brands) to dozens and sometimes even hundreds or more sites - common in specific verticals such as education and health.
Multi-site setups are often based on a single shared codebase maintained by a centralized tech team. A major challenge for that team is balancing between cohesion across sites on one end and content editors’ flexibility on the other.
Driven by the need to modernize their legacy multi-site stack, organizations that once relied on monolithic (and oft heavily customized) solutions are now adopting a headless CMS and facing a crucial choice: should they use multiple content spaces/datasets or go for a single one?
This choice has many operational aspects in the short- and long-term, and significantly affects the pricing negotiation with the CMS vendor.
Option 1: A Single Content Space
Pros
Content permissions & CMS configuration (including plug-ins) are managed in one place.
Easiest to reason about for the technical team.
Encourages modern Continuous Delivery (CD) practices, e.g. feature flags and gradual rollouts.
Total license cost can be lower, especially in the transition period: pricing can follow the aggregated usage volume for all sites, rather than a fixed minimal cost per site.
Easy to switch to multi-site setup later, if need be.
Cons
Planning & performing migrations can be tricky, and requires careful planning and risk management.
An incorrect schema or code change can immediately impact all sites. Feature flags are not a waterproof guarantee.
Administration of users & permission can be harder for content ops teams who are less used to multi-tenant systems.
Navigating a single CMS space with the content of many sites can be hard - you have to be sure to always filter out any content except for the site which you’re working on. Everyone touching the content space must be aware of this.
Analysis
The option of using a single space if often luring to engineering teams. Here's how engineering typically thinks about this:
If we’re going for a single codebase, or set or of shared micro-services, shouldn’t we strive for a single content space as well? developers hate supporting multiple subtly-different versions concurrently, while on the other hand they are used to the concept of multi-tenant systems - where any data access is in the context of a tenant (site) ID.
Assuming the schema is powerful and flexible enough, page layouts and the general look and feel can very widely between sites. Add in a centralized design system and common NPM packages for front-end components, and you get a powerful set of blocks to build with.
On the other hand, with multiple space it would always be tempting to start evolving each site’s schema separately, leading to loss of ability to maintain these sites.
The engineering team has a suite of modern tools to ease and stagger migrations - but may underestimate the potential hardships of operating sweeping sensitive migrations and schema changes down the line.
In the worst case, proponents of the single space would say (and this is generally correct): it is much easier to later change our minds and “fork” the single space to multiple spaces, then going the other way.
For content ops teams, going for this route is often a less clear cut choice:
There is inherent simplicity in the concept of one content space equaling one site: all the content you see belongs to that site. The list of pending changes is only ever for that site, and permissions are simpler and mostly site-specific.
The “blast radius” of changes is much smaller. Busy teams can decide to postpone adopting a new schema & code version until they’re ready to. Content ops teams naturally worry more about sudden outages and broken pages than about the architectural concerns of the tech team.
However, from a cost perspective, a multi-space license for a CMS typically has a fixed cost per space, regardless of the space size. This can mean higher costs. Asking for pricing based on total volume of content items, users, API calls, etc. can be cheaper, especially when getting started and having less volume. Of course, enterprise pricing is always subject to negotiation.
Option 2 - Multiple Content Spaces
Pros
Simpler mental model and less error prone for content teams: whatever content you see in a given space belongs to the same site, without the need to always be mindful of which content belongs to what. Space permissions apply to that site, so it's easier to see what roles exist for that given site.
True gradual rollout of changes is possible: a new code version X is coupled with a new schema version (if needed), and both can be rolled out gradually across sites, and paused if needed.
Cons
Ongoing technical support is harder when multiple versions run concurrently for extended time periods.
Governance: it’s harder to ensure that permissions follow corporate standards across the organization. All kinds of outdated/incorrect rules may linger in specific spaces.
Analysis
With this option, the list of pros and cons presented for Option 1 above is mostly turned on its head. There are a few more points to consider, though:
For true multi-site operations with a shared codebase, the schema of any given space cannot diverge freely, or the ability to bring it back into the fold will be lost. When presented with challenges (e.g. we only need little field X for this or that site), making changes to only the relevant space is always tempting. It may indeed be harmless at first, but tends to lead to increased “entropy” over time.
The tooling for synchronizing schema versions between spaces is improving, but can still be hassle (with each CMS having their own solutions - ask!)
Our recommendation
First, do note that consolidation of multiple codebases and datasets into one centralized system is always harder and slower than planned.
Hence, don’t be over-zealous in forcing everyone to get onboard as quickly as possible. If a specific team has unique demands and needs, it’s better to wait with onboarding them than trying to make the system overly generic from the get-go, which might complicate matters for everyone.
That said, here’s our general recommendation (the usual disclaimers apply):
A single space is a good fit for businesses that have been burned by too many “islands”. It demands a strong tech team, but then again having multiple cantons with a less-capable tech team for each is an operational nightmare of its own, just broken down to a thousand cuts.
As mentioned, the main challenge with a single space for content ops teams is navigating the content easily & safely. Engineering must make supporting that a priority to gain trust. Marketers’ velocity depends on their confidence.
Our approach to this problem is switching from directly working over nested models to thinking visually. You have a “master” viewport where everything is accessible to admins, plus a viewport per website: when a content editor goes into any such viewport, they see only a live view of that site’s homepage and sitemap, so they are naturally located in the right context and only wander within its boundaries. Viewports are based on filtering rules which are centrally managed.
Adopt the available best practices for managing gradual rollouts. Involve content ops in ensuring that changes go smoothly - and be able and willing to hit “pause” when issues are detected.
Finally, ask the CMS vendor to offer pricing that reflects gradual adoption of their product and the uncertainty involved. Strive to get a quote where you can decide what's best for you (single space or many) without big cost penalties.
We believe that Stackbit is an excellent choice for modern multi-site setups, based on the above principles which apply to any choice of stack.
