I Went Through All 45 CMS Options for Astro. For a Static Site, the CMS Is Your AI Agent.

I installed Pages CMS on a client's Astro site, fixed a typo, and pressed Save. About 50 seconds later a full rebuild of the whole site had started.

For one typo.

Pages CMS writes every save as a git commit, and the host, Coolify, deploys on every push to main. Ten small fixes in a row would have been ten full deploys. So I went looking for a better CMS for a static site, and ended up reading through every one in Astro's docs. There are 45.

By the end I had a shortlist of two, neither of them quite right. And I kept coming back to the same thought: the best editor for this site was already sitting in the repo.

45 CMS Options, and the Static-Site Shortlist Is Two

My requirements were boring. Self-hosted, stays output: 'static', doesn't break the MDX components in the blog posts, and lets me edit five things and publish once. Here's where the 45 landed, plus one that isn't on the list:

Verdict	Count
Worth a test	1 (Keystatic), plus Sveltia, which isn't on the list
Works, but you pay in complexity	3 (Directus, Decap, Sitepins)
Self-hostable, wrong tool for a static site	17
SaaS only	24

Over half of the "CMS for Astro" list is someone else's cloud. Fine if you're happy paying per seat and keeping content on a US server. My client is German and didn't want another monthly bill per site, so those were out on day one.

The 17 in the middle are mostly full applications with their own database: WordPress, Strapi, Payload, Ghost, Statamic. Running one of those so somebody can edit a dozen Markdown files is a lot of server for very little. EmDash and StudioCMS are Astro-native, which sounds perfect until you read that both need output: 'server', and your static site stops being static. (I tried EmDash when it launched, if you want the longer version.)

The best fit I found was Sveltia CMS, and it isn't even on Astro's list. It's two static files in public/admin/ and the only git-based CMS I found with a real "Publish Changes" button. Its MDX support is listed on the roadmap as "TBD". The posts on that site use <CTABox> and <StatsBar> inside MDX, and nothing in the docs could tell me whether Sveltia would save them back unchanged.

I already compared the client-facing options by type of client in "But My Client Needs to Edit It." This post is about what happens when you stop looking for the right CMS altogether.

What a CMS Actually Does on a Static Site

The deploy-per-save problem wasn't Pages CMS's fault. It was my host's. Coolify, like Netlify, Vercel and Cloudflare Pages, deploys on every push by default. Switch that off and any git-based CMS just saves, and publishing becomes something you trigger on purpose.

Once I saw that, the job description of a CMS for a static site shrank to almost nothing. It's a form that writes text into a file in your repo, plus a button that starts a build. The login screen and the media library exist to support those two things.

And on a static Astro site, the CMS brings its own problems along:

• The schema exists twice. Your Zod schema in content.config.ts already defines what a post looks like. The CMS wants its own config that mirrors it, and when the two drift, the CMS writes front matter your build rejects.
• MDX gets mangled or re-modelled. Most editors show a JSX component as plain text, or make you rebuild it as a structured "block".
• TypeScript data files are off limits. No schema-driven git CMS edits a TypeScript object as form fields. You convert to JSON first, or that content stays developer-only.
• Someone has to hold the keys. Most git-based editors need the editor to have a GitHub account, and the deploy token has to live somewhere. On Coolify that token is team-wide, so a token sitting in an editor's browser can also restart every other app in the team.

An AI agent working in the repo does the same two jobs. It writes files and it can run a build. It edits the real source, so there is no second schema to drift. It reads MDX as text, because MDX is text. And you commit once when you're done, so even with push-to-deploy switched on, one editing session ships as one deploy.

What I Ship Instead: Three Skills in Every Template

I'm on the seller side here, so you know the stake: every one of the 65 Astro templates I sell at juststart.now (they're listed on astro.build/themes) ships without a CMS. Each one comes with three Claude Code skills instead. dev-workflow reads the project before changing anything, dev-test runs the test suites and writes new tests when a change needs one, and dev-review reads the uncommitted change with fresh eyes.

While writing this I opened the plumber template and searched for one price, the £89 annual boiler service. It appears in five files.

It's in the price list in src/data/prices.ts and in the booking flow's job list in src/data/booking.ts. It's in the priceNote of data/services/boiler-servicing.md. It's inside an FAQ answer in src/data/content.ts: "Our service is £89 fixed and we send a reminder a month before it is due." And it's in a sentence in the advice article how-often-to-service-a-boiler.mdx.

Sound familiar?

That's what real small-business sites look like. A price isn't a field, it's a fact that turns up in sentences. A CMS can give the owner a tidy field for the price list, and the FAQ will keep saying £89 for the next two years.

dev-workflow is written for exactly this. Its first step is reading the template's CLAUDE.md, which lists where every kind of content lives, file by file. For a content change it says most of the template's text is data, not markup, so look there before touching a component, and it tells the agent to grep for the string form of what it's changing as well as the symbol. For the booking picker, which is the feature the whole template is built around, the instruction is one line: "To change prices or options, edit the data file, not the maths."

Then dev-test runs what ships with the template: unique slugs, real dates, trailing slashes on every internal link, colour contrast that clears 4.5:1. A price change doesn't need a new test, and the skill says so rather than inventing one. Then dev-review reads the changed files in full, because, in the skill's own words, "A diff hides the consumer you broke."

A CMS form checks that a field isn't empty. The agent checks that the site still builds and that nothing on it still quotes the old number. The owner's side of it is one sentence: "The boiler service is £95 now."

If you've never looked at what goes into a CLAUDE.md, the Netflix one that shipped to production is a decent place to start. And I've used this kind of agent-in-the-repo setup on real client work, which is what I Migrated 3 Client Sites From WordPress to Astro is about.

Where This Falls Apart

The owner who will never open a terminal. I don't have a fix for that person.

Some site owners will happily type a sentence into Claude Code. Others will look at a blinking cursor, close the laptop and email their developer. If your client is the second kind, this post is wrong for them. The options in the client CMS post, or plain "email me the change", are the better answer.

The agent also costs a monthly subscription, where Sveltia costs nothing. And agents break things with total confidence. I wrote a whole post about that, Claude Is Great at Building Software. It's Also Great at Breaking It., and it's the reason dev-test and dev-review are in the templates at all. The skills don't make the agent careful. They make its carelessness show up before anything goes live.

And I haven't sat next to a non-technical buyer while they edit their own site with these skills. The part about owners is reasoning, not a measurement.

The CMS Was for When Nobody Technical Was in the Room

A CMS for a static site exists because the developer leaves and the owner needs a safe box to type into. That box is a form with guardrails that know nothing about the site. It doesn't know the price is also in the FAQ, or that the booking picker reads from a data file.

An agent with the project's instructions and its tests does know. For a static site, I think that's the better box. Whether the owner will open it is the part I can't answer for you.

If you're deciding what to hand a client after an Astro build, or you want this kind of skill setup on your own repo, tell me about the site and I'll tell you whether I'd give them an agent or a CMS.