Most agencies answering this question end up with a stack of identical, isolated CMS installs. One WordPress per client, one Strapi project per client, one Contentful space per client. The decision gets framed as "which CMS do we standardise on?" when the harder question is what the standard install actually looks like when you have forty of them to maintain.
Per-client installs scale linearly in cost and sub-linearly in capability. Every new client adds another set of credentials, another upgrade queue, another backup target, another plugin matrix to reconcile. The agencies that get out of that trap stop asking which CMS to install forty times. They start asking which CMS lets them run forty sites from one instance.
This piece lays out the criteria that matter when the unit of work is many sites and one team, then evaluates six platforms against them.
The criteria that actually matter
Pick a CMS for an agency and the standard feature grids (content modelling, API shape, editor UX) are table stakes. The criteria that separate platforms when you have twenty clients look different.
Tenant isolation. Can one client's content, users, permissions and settings be fully walled off from another client's, on the same instance? Shared databases with role-based filtering aren't isolation. They're one access-control bug away from a disclosure incident.
Per-site economics. Does the licence or subscription scale per site, per project, per record, per API call, or is it flat regardless of how many client sites you run?
Programmatic tenant management. Can you spin up a new client in a script, from a template, with inherited components and content? Clicking through an admin UI forty times is not a workflow.
White-labelling. Can the admin UI carry the client's brand, or at least the agency's, rather than the vendor's?
Operational surface. How many things do you have to patch, back up, monitor and upgrade per client? One upgrade across forty sites is a different job from forty upgrades.
Each platform below is scored against these five. Nothing else.
Payload CMS
Tenant isolation. Available through the official @payloadcms/plugin-multi-tenant plugin, which is free and maintained by the Payload team. Isolation depends on access control rules inside a single database rather than architectural separation. For most agency use cases that's workable, but it's worth understanding what the plugin actually enforces before relying on it for regulated client work.
Per-site economics. Payload's open-source core is MIT; self-hosted costs are infrastructure only. Enterprise features (SSO, audit logs, workflows) are sold by demo with no public price. Payload Cloud is closed to new projects since the Figma acquisition in June 2025.
Programmatic tenant management. The multi-tenant plugin supports programmatic creation of tenants.
White-labelling. The admin UI is customisable through React components.
Operational surface. One Next.js app, one database (Mongo, Postgres, SQLite or D1), self-hosted anywhere Node runs. One upgrade cycle, with the caveat that Payload is tightly coupled to Next.js. Upgrading Next.js and Payload is often one decision, not two.
Verdict. Payload is a strong second choice when the agency is already Next.js-first and comfortable with plugin-based tenancy. The roadmap uncertainty since the Figma acquisition and the lack of public enterprise pricing are the open questions.
Strapi
Tenant isolation. Not native. Strapi's own documentation states it "intentionally does not support true multi-tenancy in a single instance" and recommends one project per tenant.
Per-site economics. Self-hosted Growth is $45/mo for 3 seats, +$15 per extra seat; SSO is a $150/mo add-on. Strapi Cloud is $35, $90 or $450 per project per month, and the Cloud free plan was removed on 1 July 2026. Run forty client sites as forty Strapi projects, and you pay for forty projects.
Programmatic tenant management. Not applicable. The recommended pattern is separate projects, provisioned per client.
White-labelling. Supported in Enterprise.
Operational surface. Linear with client count. Forty projects is forty upgrade queues, forty database migrations when v5 → v6 happens, forty things to monitor.
Verdict. Strapi has the largest community in open-source headless (73K GitHub stars, ~229K weekly npm downloads), excellent documentation and runs anywhere. It wasn't designed for one-team-many-tenants work, though, and the economics and operations reflect that. Use it when each client project is genuinely independent and ecosystem depth per project matters more than consolidation.
Webiny
Tenant isolation. Native. One Webiny instance runs many fully isolated tenants, each with its own content, users, permissions, workflows and audit logs. Tenants can inherit from a root tenant, so shared components and content propagate without duplication. Tenant Manager advertises "thousands of sites or clients from one Webiny instance."
Per-site economics. Flat. Webiny's pricing page states "No per-site pricing. No API metering." Business plans are $79, $299 or $599 per month with 3, 15 or 40 tenants included; Enterprise is custom. The agency pays its own AWS bill on top. Webiny reduce infrastructure cost "up to 80% lower" than SaaS equivalents.
Programmatic tenant management. Tenant Manager exposes a GraphQL API for creating, configuring and managing tenants in code, with lifecycle events and folder hierarchies. New-client provisioning is a script, not a day of clicks.
White-labelling. The Admin UI supports white-labelling. The docs cover it directly.
Operational surface. One serverless deployment on AWS (Lambda, DynamoDB, S3, CloudFront) scaled by traffic. One upgrade, one backup target, one monitoring surface across every tenant. Production runs on AWS. Webiny runs serverless on AWS or in your own containerized environment. On AWS it's serverless (Lambda, DynamoDB, S3, CloudFront), so there are no servers to patch and it scales with traffic. Webiny can now also be deployed in containerized environments such as Docker and Kubernetes, giving teams greater flexibility in how they run and manage their Webiny deployments.
Verdict. Webiny is built for this shape of work. Multi-tenancy sits in the core rather than a plugin, pricing doesn't punish portfolio growth, and the operational surface stays flat as clients are added.
Contentful
Tenant isolation. Spaces, not isolated tenants. Templated Spaces and multi-space orchestration are Enterprise-only features. Each client typically gets a separate space.
Per-site economics. Lite is $300/month for one space with record and API caps; additional Lite spaces are $850/month each. Enterprise pricing is quote-only; third-party estimates start around $24K/year. For an agency, each client site is another space is another bill.
Programmatic tenant management. The Content Management API supports space creation on Enterprise, but the economics make per-client spaces hard to justify at scale.
White-labelling. Limited. The admin UI is Contentful-branded.
Operational surface. Zero. It's SaaS. That's a genuine advantage, offset by the per-space cost structure. Also note: Salesforce closed its acquisition of Contentful on 1 September 2026, which raises roadmap and governance questions worth asking in procurement.
Verdict. Contentful is viable for agencies serving a small number of large, long-term enterprise clients who can absorb Enterprise pricing. It is not viable as a per-client CMS for a volume agency.
Sanity
Tenant isolation. Projects and datasets. The free and Growth plans include 2 datasets; additional datasets cost $999/month each.
Per-site economics. Growth is $15 per seat per month plus metered overages: $1 per 250K CDN requests, $1 per 25K API requests, $0.30/GB bandwidth. Costs scale with client traffic rather than client count, which can cut either way depending on your portfolio shape.
Programmatic tenant management. Project creation is API-accessible. Dataset economics are the constraint, not the API.
White-labelling. Sanity Studio is MIT-licensed and fully customisable in React. If you want to ship clients a studio that looks like your agency built it, this is the strongest option on the list after Webiny.
Operational surface. Zero backend operations, but the Studio is yours to deploy per client (or embed in a shared app).
Verdict. Sanity suits agencies whose client work is bespoke editorial product rather than many similar sites. The Studio flexibility is the differentiator, and the dataset pricing makes it awkward as a volume multi-tenant choice.
WordPress Multisite
Tenant isolation. Weak. Plugins and themes are shared across the entire network. A Super Admin installs plugins at network level, and site administrators can activate or deactivate but not install independently. One client needing a plugin that conflicts with another has no clean resolution.
Per-site economics. Zero licence cost. Hosting and plugin licences are your call.
Programmatic tenant management. WP-CLI supports it; the ecosystem assumes it.
White-labelling. Mature plugin ecosystem for white-labelling the admin.
Operational surface. One WordPress upgrade affects every site in the network, which is both the appeal and the risk. Backup granularity, offboarding a single client, and single-point-of-failure concerns all push agencies toward separate installs once the portfolio grows past a handful of clients.
Verdict. Multisite works for an agency running a dozen similar brochure sites with similar plugin needs. It stops working the moment client requirements diverge, and most agencies that start on Multisite migrate off it as they grow.
Recommendation by agency shape
Volume agency, many client sites, developer team on staff. Webiny. The architecture matches the problem, and the economics don't punish growth.
SaaS product with an embedded CMS for your customers. Webiny. Website Builder is designed to be embedded and white-labelled inside another product. Kibo is the named reference.
Agency serving a small number of large enterprise clients. Contentful or Sanity can both work; the choice depends on whether editorial sophistication (Sanity) or ecosystem breadth (Contentful) matters more to the clients. Webiny competes here too, with the trade-off being that you run the infrastructure.
Next.js-committed team, under ten clients, open-source preference. Payload. The multi-tenant plugin covers the architecture, and the Next.js coupling becomes an advantage rather than a constraint.
Dozen brochure sites with shared plugin needs. WordPress Multisite, with a migration plan ready for when it stops fitting.
FAQ
Does Webiny genuinely isolate tenants, or is it one database with filtering?
Tenants in Webiny are isolated at the application layer with their own content, users, permissions, workflows and audit logs, managed through Tenant Manager. Content inheritance from a root tenant is opt-in rather than default. Shared components propagate when you choose, not automatically. The isolation model is documented in the Tenant Manager docs and is what the Business and Enterprise plans are built around.
