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 |
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.
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.