There is no single best CMS for Astro. For a small client who edits a blog and some text, a Git-based CMS such as Keystatic, Decap CMS or TinaCMS is usually the best fit: free or low cost, no extra server, and content stays in the project. For a marketing team that builds new pages every week, a visual headless CMS such as Storyblok or Sanity is worth the setup. And for sites that change twice a year, the honest answer is often no CMS at all.
Here is how to decide, based on who edits the site and how often.
First question: does this client need a CMS?
Many brochure sites change a handful of times per year: a new team member, updated opening hours, a price change. For those clients, the simplest setup is that you keep the content in Markdown or Astro content collections and make the changes yourself as part of a small support agreement.
That is not a lazy option. It means no editor to maintain, no accounts to manage and no risk of a client breaking a layout. Be clear with the client about turnaround time and you have a cheaper, more stable site.
Add a CMS when the client needs to publish without you: a blog, news, vacancies, events, or landing pages for campaigns.
The three types of CMS that work with Astro
Git-based CMS
The editor writes changes back into your repository as Markdown or JSON files. Your host rebuilds the site on every change.
- Pros: content lives with the code, full history in Git, no separate database, often free.
- Cons: every edit triggers a build, previews are less instant, and editors need a Git provider account behind the scenes in some setups.
- Good options: Keystatic, Decap CMS (formerly Netlify CMS) and TinaCMS, which adds visual, on-page editing.
Headless CMS (API-based)
Content lives in a hosted service. Astro fetches it at build time, or on request if you use on-demand rendering.
- Pros: polished editing, roles and permissions, scheduled publishing, image handling, and in some cases a visual page builder for editors.
- Cons: a monthly cost once you pass the free tier, a vendor dependency, and more setup work.
- Good options: Storyblok (strong visual editor), Sanity (very flexible content modeling), Contentful (common in larger organizations), and self-hosted open-source tools such as Strapi or Payload if you want to run it yourself.
Astro-native and emerging options
EmDash is an open-source (MIT) CMS built for Astro, which reached version 1.0 in 2026 and was introduced on the Cloudflare blog. It is worth watching if you want an editor that is designed around Astro rather than added on. As with any young tool, test it on a real project before you standardize on it.
The Astro docs keep a list of CMS guides if you want to compare more options.
You can also keep WordPress as a headless CMS and use Astro only for the front end. It gives clients the editor they know, but you still maintain a WordPress install, so most of the maintenance burden stays.
How to choose: five questions
- Who edits, and how often? One person, a few times a month: Git-based. A team, every day: headless.
- Do they edit text or build pages? Editing text in fixed sections is easy with any option. Letting a marketer assemble new landing pages from blocks needs a visual editor such as Storyblok or TinaCMS, plus components you design for it.
- What is the budget over three years? Free tiers change. Check the current plans for the number of users, locales and records the client needs.
- Who owns the content? With Git-based tools the content is in the client’s repository. With a hosted CMS, make sure the account is in the client’s name and that you can export the content.
- How much setup can you bill? A Git-based CMS can be configured in an afternoon. A visual headless CMS with reusable blocks is a project in itself.
Our picks for typical client work
| Situation | Pick | Why |
|---|---|---|
| Brochure site, changes a few times a year | No CMS, content in Markdown | Cheapest and most stable |
| Small business with a blog | Keystatic or Decap CMS | Simple editor, content stays in Git |
| Client wants to edit on the page itself | TinaCMS | Visual editing on top of Git-based content |
| Marketing team building landing pages | Storyblok | Visual editor with reusable blocks |
| Complex content model, several channels | Sanity | Flexible schemas and APIs |
| Client insists on the WordPress dashboard | Headless WordPress | Familiar editor, but WordPress maintenance remains |
Setting it up without regrets
Whatever you pick, a few habits save trouble later:
- Model content as fields, not as free HTML. A testimonial is a quote, a name and a photo, not a rich text blob. Your design stays intact when the client edits.
- Limit what editors can break. Offer a curated set of blocks instead of a blank canvas.
- Use Astro’s content collections with a schema for Git-based content, so a missing field fails the build instead of breaking the live page.
- Plan for images. Decide where uploads go and let Astro optimize them at build time.
- Write a one-page guide for the client with screenshots of the three things they will actually do.
Hosting and builds
With a Git-based CMS, every save starts a new build. On static hosts such as Cloudflare, Netlify or Vercel that usually takes a minute or two for a small site. See how to deploy an Astro site to Cloudflare for a setup that rebuilds on every push.
If you are moving a client from WordPress, the CMS choice is part of the migration plan. Our WordPress to Astro migration checklist covers content export, redirects and handover. And if you are still weighing the switch itself, start with Astro vs WordPress for client sites.
Build the site, then pick the editor
At Tado Studio, we are building a desktop app for Astro where AI chat, visual editing and code come together on plain project files, including pages, components, posts and your own collections with custom fields. Whatever CMS you choose later, the site stays a standard Astro project.
Tado Studio is not publicly available yet. Join the waitlist for launch news and an exclusive launch discount.