What a multi-site CMS actually needs to do
Running twenty client sites is not running one site twenty times. The six things that break at scale, and the questions to ask a vendor before you commit a fleet.
Most CMS marketing is written for a company with one website. The features, the pricing, the onboarding: all of it assumes a single product with a content team behind it.
An agency has a different shape entirely. Twenty sites, forty clients who each touch only their own, no shared editorial team, and a maintenance fee per site that decides whether any of it is profitable. Almost nothing designed for the first shape survives contact with the second.
Here is what actually breaks, in the order it breaks.
1. Pricing that multiplies
The first wall, and the most brutal.
Almost every hosted CMS prices per project, per space, or per seat. On one site that is a line in a budget. On twenty it is the budget.
Concretely, as surveyed on 8 August 2026: Contentful goes from a free tier straight to €300 a month with nothing in between. Strapi Cloud starts at $35 a month per project, so twenty sites is twenty subscriptions. Sanity charges $15 per seat, and an agency’s seat count grows with every client onboarded. Storyblok’s free tier allows one seat, then Growth is $99 a month with $20 a month for each extra locale.
None of these companies is being unreasonable. They are priced for their actual customer, which is a company with one site and a budget. You are not that customer.
The question to ask: what does this cost at twenty sites, with two editors each, two languages each? Do the arithmetic before the demo, not after.
2. Tenant isolation that actually isolates
Your client must see their site and nothing else. Not “see a list where theirs is highlighted”: nothing else. Not the existence of your other clients, not their names in a dropdown, not a 403 that confirms another project exists.
This sounds obvious and is regularly done badly. The tell is the error code: if asking for a resource you do not own returns 403 Forbidden, the system has just told you that resource exists. Across a client fleet, that is an information leak with commercial consequences: your client learns who else you work with.
The question to ask: what happens if I request another tenant’s resource by id? The right answer is 404, everywhere, with no exceptions.
3. A content model you can repeat without copying
Twenty brochure sites share maybe eighty percent of their structure: a home page, services, a contact block, opening hours, some SEO fields. The remaining twenty percent is what makes each client theirs.
Systems that make you rebuild the model by hand each time punish you twice: once in the setup, and again every time you improve the shared pattern and have to apply it across twenty sites manually.
The model belonging in code rather than in a UI matters here more than anywhere. A TypeScript file can be copied, diffed, reviewed, extracted into a shared package and imported. A model clicked together in an admin interface can only be recreated by clicking again.
The question to ask: can I put my content model in version control, and can I share pieces of it between projects?
4. Seats that are not a cost centre
An agency’s editor count grows in a way a product company’s does not. Each client is one or two people. The seasonal person who updates the menu is another. The client’s partner who logs in twice a year is another.
Per-seat pricing turns every one of those into a line item, which pushes you toward the thing you must never do: sharing one login between several humans. That kills your audit trail, and the day a client asks who deleted their pricing page, you cannot answer.
The question to ask: what does an extra editor cost? If the answer is not zero, model it at forty editors.
5. Deployment that survives being different everywhere
Client sites are not uniform. One is on Vercel because the client’s previous agency put it there. One is on Netlify. One is on a shared host with FTP because that is what the client’s brother-in-law sold them. One is on your own VPS.
A CMS that assumes a single deployment story forces you to normalise your fleet, which is a project nobody is paying for.
What you want instead is a per-site deploy target: a hook, a CI trigger, an agent on a server, whatever that particular site needs, configured once and then invisible.
And crucially, status that is real. A tool that says “published” when it means “wrote a row and fired a webhook” is worse than one that says nothing, because your client believes it. The build failing silently is how a client discovers, three weeks later, that their new prices were never online.
The question to ask: after my editor clicks Publish, what tells them the page is actually being served?
6. Billing you can hand to a client, or absorb
Two models coexist in agencies and both need supporting.
Either the client pays directly, in which case they need their own invoice with their own VAT details, or you absorb the cost into a maintenance fee, in which case you want one invoice covering the fleet rather than twenty separate charges to reconcile.
The question to ask: can I be billed once for the whole fleet, and can I put my own brand in front of the client?
7. An exit that works for twenty sites at once
The question every agency should ask and almost none do: what happens to the fleet if this vendor doubles its price, changes direction, or shuts down?
For one site, a migration is an unpleasant weekend. For twenty, it is a project you cannot finance, which means you will pay the new price instead. That asymmetry is exactly why per-project pricing tends to rise once a vendor knows its customers are locked in.
The protection is a real export, and “real” has a specific meaning: content in a format your next tool can read, not a proprietary JSON dump that technically contains your data. For an Astro fleet, that means markdown and JSON shaped like content collections, produced by a command you can run today without asking anyone.
The question to ask: show me the export, right now, on the free tier, and let me look at what comes out.
The thing that is not on any feature list
Across a fleet, the cost that eventually dominates is none of the above. It is support time.
Every tool your clients touch generates a stream of small interruptions: a forgotten password, a photo that will not upload because it is a HEIC from an iPhone, a page that “did not save” because they closed the tab before autosave ran, a change that is not visible because the build failed quietly.
Each one costs ten minutes and a context switch. Twenty sites with two editors each, at one interruption per editor per quarter, is roughly one hundred and sixty interruptions a year. That is several weeks of your attention, and it is invisible in every comparison table.
The lever that reduces it is not features, it is the opposite: fewer screens, fewer settings, fewer states an editor can get into. Every option you expose to a non-technical client is a question they can ask you later. This is why our editor has no settings screen at all, and why the only modal an editor ever meets is the confirmation before deleting something.
What we built, and what we left out
Menestrel is shaped by these six constraints, because it started as internal tooling for exactly this problem.
Pricing is per site, with unlimited seats and unlimited locales from the first paid plan: 3 € excl. VAT per month per site, or a Studio plan at 15 € excl. VAT covering ten sites. Adding an editor costs nothing, on purpose, because an agency’s editor count is not a proxy for the value it produces.
Tenant isolation answers 404 everywhere, verified by a dedicated test suite that walks every endpoint with another tenant’s session and asserts nothing but 404 comes back.
The content model is TypeScript in your repository, so it diffs, reviews and copies like any other code.
Deploy targets are per site: Vercel, Netlify, Cloudflare Pages, GitHub Actions or an agent on your own server, each configured once. The editor sees the real deployment state, ending at “live”, because the publish path follows the build to completion.
And the Studio plan carries white-label: your domain, your logo, and emails leaving from your own sending domain, so the client sees your agency rather than a supplier they did not choose.
What we do not do, and you should weigh it: no visual page builder, no content API at request time, no self-hosting, and Astro only. Publishing goes through a build, so one to three minutes between the click and the live page. If any of those is a hard requirement, we are the wrong tool and the comparisons say which one is not.
The honest summary
The multi-site problem is mostly an economics problem wearing a technical costume. The features you need are not exotic; what breaks is that everything is priced and shaped for someone with one website.
Before committing a fleet to anything, do the twenty-site arithmetic, ask what a wrong-tenant request returns, and ask what the editor sees after they publish. Those three answers tell you more than any feature comparison.