Choosing a CMS for an Astro site sounds like it should be straightforward until you start looking.
The Astro docs list plenty of options. The wider Jamstack ecosystem lists many more. Some are API-first platforms. Some are visual page builders. Some are cloud products with their own admin interface, content database, permissions, pricing, and deployment assumptions.
They are not all solving the same problem.
For the kind of Astro sites I usually build, I do not need a whole content platform. I need a clean way to edit front matter, Markdown, blog posts, simple records, and structured fields that feed custom Astro components.
I want the CMS to make editing safer and easier. I do not want it to take over the architecture.
TL;DR
My current pick is Keystatic if you want a local Git-based CMS workflow for an Astro site.
If you do not care about running the CMS locally, and you are already using GitHub for your deployments, Pages CMS is the fallback I would be comfortable using. It is simple, works well, and is already good enough for a lot of Astro marketing sites.
The rest of the article explains why I narrowed the field down to Git-based CMSs and why I am not focusing on API-first headless CMSs for this kind of project.
This is a first-pass practical review, not a definitive ranking of every CMS in the ecosystem. I spent roughly an hour looking into each serious candidate, setting up the ones that looked closest to the workflow I wanted, and noting my first impressions. If I have misunderstood a tool or missed something important, I would update the view after deeper testing.
My criteria
Content should stay in Git: I want the site code and content to remain version-controlled, portable, and easy to inspect.
The public site should stay static: The CMS can help create or edit content, but the live site should be served as static HTML, CSS, and assets after deployment where possible.
No permanent public admin by default: The CMS should not require an always-on public admin endpoint unless there is a strong reason. For these sites, there usually is not.
Local or agent-friendly workflow: Ideally, I should be able to clone the repo, run the CMS locally, edit content, commit the result, and deploy through a script.
Clear occasional editing: The client editing experience should be understandable for occasional updates. It does not need to be a full visual page builder.
Works with custom Astro components: In these builds, the CMS is usually managing fields and content values, not designing the page.
Avoid unnecessary lock-in: Hosted services are not automatically bad, but they need to justify the dependency.
Why I am not focusing on API-based CMSs
API-based headless CMSs make sense for some projects. If you are building a larger content platform, a multi-channel publishing system, a directory, a dynamic application, or a site with lots of editors and relationships between content types, a structured content API can be the right tool.
That is not the main use case here.
For a mostly static Astro site, the CMS content is usually fetched at build time. After that, the public site is just static output. If the API is only feeding the build process, the benefit of an always-available content API is much smaller.
API-first CMSs also tend to move the source of truth out of Git and into the provider’s content database. That adds another account, another platform, another pricing model, and another operational dependency.
If the site needs genuinely dynamic data, such as ticket sales, bookings, availability, stock, or live pricing, I would normally keep that separate from the CMS. The CMS can manage the editorial content around an event or service. The live data should come from the system that owns it.
That is why this review narrowed down to Git-based CMSs.
The shortlist
The four tools I ended up testing or seriously considering were:
I also looked at wider lists, including the Astro CMS guide and the Jamstack headless CMS list, but a lot of the options were either API-driven, cloud-first, too expensive, too immature, or tied to another static site generator.
Pages CMS
Website
Documentation
Astro guide
GitHub
Pages CMS is my baseline because I am already using it.
It is simple, Git-based, and easy to understand. You define the CMS structure in a YAML config file, including the navigation, collections, fields, and editable content. It publishes directly to GitHub, which means content changes can trigger a deployment if your GitHub workflow is set up that way.
The editing model feels a bit like Advanced Custom Fields for a static site. You define the fields, the client edits those fields, and Astro handles the actual templates and components.
I have not had any major problems with it. For a lot of small business Astro sites, I would be happy to use it.
The main caveat is that it is tied to GitHub. If GitHub is down, the CMS cannot update the site. In practice, that may not matter much, because the remote repository and deployment workflow often depend on GitHub anyway. If GitHub is unavailable, I have bigger problems than the CMS.
The deeper concern is strategic dependency. Pages CMS is a third-party service built around GitHub. If GitHub changes its pricing, organisation requirements, or workflow assumptions, or if Pages CMS changes its own model, that affects the setup.
Pages CMS is still a very good option. It is just not the fully local, self-controlled Git workflow I was curious to find.
Verdict: strong baseline. I would still use it for many projects, especially if GitHub is already central to the workflow.
Keystatic
Website
Documentation
Astro guide
Keystatic is the strongest alternative I found in this first pass.
It has first-party Astro support, local mode, GitHub mode, and a clean configuration approach. The config file looked relatively minimal, and the local setup fitted the workflow I was looking for.
Once I got it running, it felt good. It loaded quickly. The UI was clean. It had dark mode. Search was built in. The settings and collections were grouped neatly. It felt similar in broad shape to Pages CMS and TinaCMS, but a little nicer for local editing.
The important point is that it can run locally inside the project. That means a developer, or a local AI agent, could start the web server, open the CMS at a local URL, edit the content, and commit the changed files to Git.
That is very close to the workflow I want.
There is also a possible middle ground. If the hosting platform supports on-demand private containers, Keystatic could potentially run only when editing is needed rather than being exposed as a permanent public admin. I have not verified that as a Bunny.net production pattern yet, so I would treat it as an architecture to test, not the first recommendation.
The simpler workflow is to keep Keystatic as part of the repository. When an AI tool or developer works on the site, it can run Keystatic locally, open the admin URL, edit content, and commit the file changes. For a client, there are a few possible paths: they can ask for changes through an AI-assisted workflow, they can be shown the local editor during a working session, or Keystatic can be connected through GitHub mode if direct client access is needed.
Keystatic Cloud and GitHub mode may also be worth exploring for client access, but I would start with local mode. I do not want the hosted layer to become the reason for choosing it unless it clearly improves the workflow.
Verdict: current winner. It feels like the best fit so far for local Git-based editing on a custom Astro site.
TinaCMS
Website
Documentation
Astro guide
Tina Astro framework guide
TinaCMS looked promising at first because it supports Astro and can run locally. It also has a richer editing model and visual editing options.
I got the local side working enough to see the shape of it. It can model content and run a local admin interface. It felt broadly similar to Pages CMS once the content model was visible.
The catch is that Tina feels heavier. TinaCloud is GitHub-based, which puts it in the same broad hosted GitHub-connected category as Pages CMS. Self-hosting Tina is possible, but it is not just a simple local file editor. It involves a data layer, authentication, a database adapter, a Git provider, and a GraphQL endpoint.
That may be technically sound, and it may be the right architecture for some teams. It just does not feel like the simplest answer for a mostly static Astro marketing site.
Tina also has visual editing for Astro, including contextual editing and click-to-edit behaviour. That is interesting, but it adds another layer of setup. For this use case, I am mainly trying to edit structured content and Markdown cleanly, not build a visual editing system.
Verdict: viable, but not compelling enough to replace Pages CMS or Keystatic for this workflow. I would use Tina if I specifically wanted its schema and editor model, but it is not my current first choice.
Decap CMS
Website
Documentation
Add to your site
Astro guide
Decap CMS is the mature open-source option in this space. It grew out of Netlify CMS, and it has a long history as a Git-based CMS for static sites.
I got it running, and it looked okay. It is usable, and it is clearly capable of managing Git-backed content.
My first impression was not as positive as Keystatic. The UI felt a bit chunkier. I did not find a dark mode. The default preview was turned on, and because the content was mostly Astro front matter, the preview did not look useful out of the box.
You can create custom previews, which could be powerful. In theory, you might be able to build something closer to a page preview. In practice, I suspect that would take quite a lot of work, especially if the site is built from custom Astro components. It may require rebuilding preview components or rendering logic separately, which is not what I want for this project.
There is an Astro guide on the Astro docs site, but I did not find a strong Astro-specific platform guide on the Decap site itself.
Verdict: credible and mature, but not the winner for this workflow. Keystatic felt better in the first pass.
Why I am not testing headless WordPress
Headless WordPress is worth mentioning because it is a common answer to this question.
It is also worth mentioning because WordPress development is one of the services I offer. I am not trying to dismiss WordPress. For many projects, WordPress is still the right choice.
It can work. If a large organisation already has WordPress in place, multiple editors using it every day, and established workflows for publishing news, articles, or simple structured content, WordPress may still be the right editorial system.
That is not the situation I am usually designing for with lean Astro marketing sites.
In fact, a lot of clients looking at an Astro rebuild would be moving away from WordPress because they want the site to be leaner. They do not want to stay tied to an expensive hosting contract or keep a VPS online just so one person can log in a few times a year to make updates.
For this kind of site, a public WordPress server plus a public Astro site feels like two systems to host, secure, and maintain. It keeps a lot of the operational weight that the Astro rebuild was meant to remove.
The WordPress editor is also not an obvious fit for a component-based Astro build. It works well for posts and simple page content, but custom sections and structured layouts are less clear.
You could model content with Advanced Custom Fields, build custom blocks, or use WordPress privately as an internal publishing system that deploys static output. That might make sense for a larger organisation.
For a small business trying to run a fast, low-maintenance marketing site, it feels like too much machinery. If the client rarely updates the site, and the updates usually come from one person, a simple Git-based CMS can cover the need without keeping WordPress online as a headless backend.
That is the more interesting transition for me: move the public site to Astro, keep the content in version control, and give the client a lightweight editing workflow instead of preserving the WordPress hosting burden.
Verdict: mention it, but exclude it for this workflow unless WordPress is already deeply embedded in the client’s organisation.
Other tools I looked at
Sanity is a serious structured content platform with Astro support, but it is centred around Sanity Studio, Content Lake, APIs, collaboration, and hosted content infrastructure. It makes sense for larger content systems, but it is heavier than I need here.
CloudCannon is featured in the Astro CMS guide and looks polished, but pricing ruled it out for this use case. At roughly $49 per month paid annually, or $55 month to month, it costs more than the kind of lightweight server this workflow is trying to avoid.
Contentful and Storyblok are strong platforms, but they are not really in the Git-based local editing category I am reviewing.
Publii looks more like a desktop static site CMS and site builder than a CMS layer for an existing Astro project.
Statamic is flat-file and Git-friendly, but it is also a Laravel/PHP CMS with a control panel. That makes it too heavy for this specific workflow.
Sveltia CMS looks interesting as a modern Decap-style project, but the Astro integration story felt too light for a client-facing recommendation at this stage.
VaultCMS is interesting because it connects to an Obsidian vault. I may look at it for my own workflow, but I would not recommend it for client sites yet.
Current recommendation
For the kind of Astro sites I am building, I would start with Keystatic for new local-first workflows, while keeping Pages CMS in place for existing sites that already use it.
Pages CMS is still a safe baseline. It already works, it is simple, and in terms of day-to-day functionality it is on similar footing to Keystatic for many small Astro sites.
Keystatic is the most promising alternative so far. It runs locally, feels quick, has a clean UI, supports dark mode, and fits the idea of a local Git-based editing workflow very well.
The main thing I do not love about Pages CMS is the reliance on GitHub. If GitHub is already central to the repository and deployment workflow, that may be acceptable. But if I am choosing a CMS from scratch, I would rather avoid making GitHub plus a third-party hosted editor the only practical editing path.
TinaCMS is viable, but I do not yet see enough advantage over Pages CMS or Keystatic for this use case.
Decap CMS is mature and credible, but it felt less polished in the first pass.
For existing Astro sites I have already set up with Pages CMS, I would continue with that for now rather than migrate for the sake of it. For new builds, especially where I want a local, self-controlled workflow that works well with a developer or AI agent, Keystatic currently looks like the better direction.