Astro CMS: which one to use, and how to pick

The short answer

If only developers edit the site, use Markdown files and Astro’s content collections; you don’t need a CMS. If one or two people who don’t code edit it, use a Git-based CMS like Keystatic, Decap CMS or TinaCMS. If a team needs roles, previews and lots of structured content, use an API-based CMS like Sanity or Storyblok, or an Astro-native one like StudioCMS. If your team already writes in WordPress, keep WordPress as the editor and let Astro build the pages.

Does Astro have a CMS?

Not a dashboard. Astro supports Markdown out of the box, and its content collections organize, validate and type-check that content. Everything else, from a visual editor to user accounts, comes from a CMS you connect. Astro’s docs point you to a headless CMS: one that stores and edits your content but leaves the job of showing it to Astro.

On October 18, 2026, Astro’s docs had guides for 45 of them, though the docs say many are stubs. They fall into five kinds.

The five kinds of Astro CMS

1. Markdown files (no CMS)

Each post or page is a Markdown or MDX file in the project, and a content collection checks that every file has the fields you require, like a title and a date. It’s free, fast and has nothing to log into. The catch is that editing means opening the project in a code editor or on GitHub, which most business owners won’t do.

2. Git-based CMS

These give you an editing screen but still save your content as files in the project. Decap CMS, for example, adds a page (usually /admin) where signed-in users edit content, and it commits each change straight to the site’s repository. Keystatic syncs content with GitHub, and Pages CMS works on GitHub repositories. Astro’s docs call Keystatic, Decap CMS and Pages CMS open source; CloudCannon adds a visual editor for your components.

The site stays a set of static files with no database. The trade-off is that each save is a change to the project, and the site rebuilds before the edit goes live.

3. API-based CMS

Your content lives in the CMS, and Astro fetches it when it builds (or when a page is requested, if you render on demand). Sanity focuses on structured content; Storyblok builds pages from reusable components it calls Bloks; Contentful connects through its SDK, with no JavaScript sent to visitors; Payload is open source and can run on your own server. These have the most polished editors, with roles and previews. You also depend on their servers and their pricing, so check each plan before you commit.

4. Astro-native CMS

StudioCMS is a headless CMS built with Astro, with a dashboard for managing content. EmDash, also listed in Astro’s docs, is an open-source CMS built for Astro that adds database content, an admin screen, a media library, menus and taxonomies. These feel the closest to WordPress. StudioCMS needs an SSR adapter and a database (libSQL, MySQL or PostgreSQL), per its own setup guide.

5. WordPress as a headless CMS

WordPress comes with a REST API, so Astro can pull posts and pages from an existing WordPress install. Your team keeps the editor it knows, and visitors only ever load the Astro site. You still keep that WordPress install updated, and you run two systems instead of one.

What bushe.co uses

This site keeps its 730 blog posts and 630 answers in StudioCMS (version 0.4). It works in two modes. For editing, Astro runs as a server on my computer, with the StudioCMS dashboard and its database file. For the live site, a build script exports that database to a JSON file, and Astro builds every page as static HTML, so no CMS or database runs on the live server.

The catch: content can only be edited where that database file lives. That’s fine for one editor, and wrong for a team. Newer posts, like this one, are plain Astro files instead. For a client team, I’d pick a Git-based or API-based CMS so anyone with a login can edit from anywhere.

How to pick an Astro CMS

• Who edits, and how often? Developers only: Markdown. A couple of people who don’t code: Git-based. A team publishing daily: API-based or Astro-native.
• Does your content have a fixed shape? Products, team bios, locations and events need required fields. Every kind above can enforce them; API-based CMSs make it easiest for editors.
• Can the site rebuild on every change? Git-based setups and most API setups rebuild the static site. If edits must show instantly, you need pages rendered on demand, which means a server.
• Who owns the content? Files in your repository are yours outright. Content in a hosted CMS can be exported, but check how before you sign up.

Moving a WordPress site to Astro?

The CMS question comes first in any move off WordPress, because it decides how your team works afterward. You can keep WordPress as the editor, or move the content into one of the options above. See WordPress to Astro migration for how I handle it, and the Astro SEO checklist for keeping your rankings through the move.

Sources: Astro’s CMS guides and Why Astro pages, and StudioCMS’s getting started guide, checked October 18, 2026.