Choosing a CMS for an Astro site: the four families
Git-based, headless SaaS, static-first CMS, or nothing at all. What actually separates these options on an Astro project, and how to decide without regret.
The question comes up on every Astro project the moment a client needs to edit a page. The comparisons you find line up feature tables that all look alike. The decision really turns on three questions, and everything else follows from them.
The three questions that decide it
1. Who edits? A developer, or someone who does not know what a branch is. By far the most discriminating criterion, and the one most often underestimated.
2. Does the site have to stay static? If yes, the CMS has to step out of the way at build time. If no, everything becomes possible and much more expensive to operate.
3. How many sites? One site is a subscription. Twenty sites is a business model, and per-project pricing becomes the dominant factor.
Family 1: git-based
Decap, Sveltia, Tina. The editor writes in a UI, the CMS commits to the repository.
For: free or nearly, content lives in the repository, no database to operate, and Git history is content history.
Against: your client inherits a GitHub account and a mental model that is not theirs. Content and code share one history, so restoring a piece of text means touching the repository. Across a fleet, every site is one more hand-maintained configuration.
When it is the right call: your editors are developers, or you are the only editor.
Ecosystem note (surveyed 4 July 2026): Sveltia has overtaken Decap in npm downloads and moves fast, but still runs on a single maintainer, with no 1.0 and no paid offering, and a UI in English and Japanese only. Decap is maintained at a minimum. On client work, longevity deserves to be asked about before features.
Family 2: headless SaaS
Sanity, Storyblok, Prismic, DatoCMS, Strapi Cloud. A content API, an editing studio, and you plug whatever you like into it.
For: mature products, rich editors, serious visual editing on several of them, and free tiers generous enough for a brochure site.
Against: price. As surveyed on 4 July 2026, the market’s paid floor sat between $10 and $18 per month per project, with a desert until the $49-99 bracket. Additional languages are an upsell tier almost everywhere. Across twenty brochure sites the bill often exceeds what you charge for maintenance.
A less visible limit: none of them puts the site back online. They publish into their API; triggering the build, following the deployment and telling the editor “it is live” is your job. Most integrations stop at a webhook.
When it is the right call: a single project, a budget that absorbs it, a need for advanced visual editing.
Family 3: CMSes built for static
The newest family, and the one we belong to. The shared principle: content is only needed at build time, and the CMS takes responsibility for getting the site online.
For: the site stays static with no runtime dependency, the editor never has to understand the repository, and per-site pricing suits a fleet.
Against: publishing goes through a build, so one to three minutes between the click and the live page. Not built for content that changes every minute.
When it is the right call: several brochure sites, non-technical clients, a requirement that operations stay simple.
Family 4: no CMS
Do not dismiss it. If content moves three times a year and you are the one editing it, markdown files in the repository are the right answer. The best CMS is the one you never install.
When it turns against you: the day a client waits two weeks for a price change, and you work out that those interruptions cost more than a subscription.
The decision table
| Situation | Family |
|---|---|
| I am the only editor, content rarely moves | No CMS, or git-based |
| Developer editors, one project | Git-based |
| One project, comfortable budget, advanced visual editing | Headless SaaS |
| Non-technical clients, several sites | Static-first CMS |
| Content changing by the minute | Server rendering, none of these families |
The question underneath all four families
Before the table, there is one question that decides more than the families do: is your client’s content a set of pages, or a set of things?
A brochure site is pages. A home page, a services page, a contact page, maybe a handful of case studies. The structure is designed once and rarely changes, and the client edits text and photographs inside it.
A catalogue is things. Products with variants, sessions with dates, members with permissions. The structure is relational, the volume grows, and queries matter.
Almost every bad CMS decision I have seen came from answering this wrong. A brochure site forced into a relational back end gets an admin interface nobody can use. A product catalogue forced into flat files gets a build that takes six minutes and a set of hand-written filters you now maintain.
Answer it first, out loud, before comparing anything.
What each family does to your build
A dimension that rarely appears in comparisons and matters daily.
Git-based content is local files, so the build reads from disk: fast, deterministic, and offline. The cost is that images live in the repository and are processed during the build, which is what actually makes these builds slow as a site ages.
Headless SaaS means the build calls an API over the network. Usually fine, occasionally slow, and dependent on a third party being healthy at the moment you deploy. Worth asking what happens to your Friday deploy if their status page goes yellow.
Static-first CMSes vary, and the distinction is worth probing: does the build call the CMS’s live API, or read a frozen artefact from a CDN? The second is strictly more robust, because a vendor outage stops mattering.
No CMS is just files, which is the fastest possible answer.
What “static-first” actually has to prove
The third family is the newest and therefore the least well defined, so it is worth saying what separates a serious member of it from a marketing claim.
Content frozen at publish, not fetched live. If the build calls a live API, the vendor’s outage is your failed deploy. If it reads an immutable artefact from a CDN, an outage is irrelevant. Ask whether they have tested it by switching their own API off, rather than whether it should work in principle.
Publishing tracked to completion. The editor should end at a state and a time, not at a confirmation that a row was written. Anything else leaves your client believing a change is live when a build may have failed quietly.
An export you can run today. Content in a format your next tool reads, available on the free tier, without asking anyone. This is the only real protection against a vendor’s price rising once your fleet is committed.
A tool in this family that cannot demonstrate all three is a headless CMS with different marketing.
Two criteria everyone forgets
The exit. Before choosing, ask how you get all the content back if you leave, and in what format. A proprietary JSON dump is not an exit. An export as markdown and JSON in content-collections format is.
What happens when the CMS goes down. On a well-architected static site the answer should be “nothing, the site keeps running and a build still succeeds”. If the answer is “the site goes down too”, you have introduced a dependency you did not need.
The cost that decides it, and never appears in a comparison
Across a fleet, the dominant cost is none of the above. It is support time.
Every tool your clients touch produces a stream of small interruptions: a forgotten password, a HEIC photo from an iPhone that will not upload, a change that “did not save”, a page that is not live because a build failed quietly and nothing said so.
Twenty sites with two editors each, at one interruption per editor per quarter, is roughly one hundred and sixty interruptions a year, each costing ten minutes plus a context switch. That is several working weeks, and it appears on no comparison table.
The lever that reduces it is not features. It is the opposite: fewer screens, fewer settings, fewer states an editor can reach. Every option you expose to a non-technical client is a question they can ask you later.
Which reframes the whole comparison. The family that wins for client work is usually not the most capable one, it is the one that produces the fewest questions.
Where Menestrel sits
We are in the third family, dedicated to Astro and nothing else. Content travels to the site at build time, never on a visitor’s request, and publishing runs all the way to the site actually being live. The free plan covers a full site with two languages, no card required.
If your site is not on Astro, we are not the right tool, and it is better to say so straight away.
The limits worth weighing before you take the free plan seriously: publishing goes through a build, so one to three minutes between the click and the live page. There is no visual page builder, so a client who composes layouts will be happier on Storyblok. There is no content API at request time. And there is no self-hosted version, so a client who requires content on their own infrastructure needs a git-based CMS or Strapi instead.
Per-vendor detail, including what each one does better than us, is in the comparisons.