Astro CMS: content collections, a headless CMS, or both

TL;DR

Choosing where content lives in an Astro project, the essentials:

• Astro is the one mainstream framework where “no CMS” is a first-class answer. Content collections give you a typed, queryable content layer over markdown and MDX files in your repository, out of the box. Most developer-maintained Astro sites should start there and add nothing.
• The decision rule is who edits, not what the site does. Developers author the content: use content collections. Marketers publish weekly without engineering help: add a CMS. Both: run the hybrid, collections for docs and long-form, a CMS for marketing pages.
• The quick CMS picks: Storyblok when marketers need visual editing; we shipped Carbon Removal Alliance on exactly this pairing. Sanity when content is structured data reused across surfaces. Contentful when governance and procurement lead. DatoCMS for multi-locale marketing sites with strong defaults.
• We write this as an official Astro partner that also implements every CMS above and resells none of them. This site itself runs on Astro with content collections and no CMS, which is its own small proof of the first bullet.

If your front end is React or Next.js rather than Astro, the parallel guides are React CMS and best CMS for Next.js.

Why the Astro version of this question is different

For most frameworks, “which CMS” is the natural first question because the framework offers nowhere for content to live. Astro does. Content collections are a built-in content layer: markdown, MDX, JSON, or YAML files in your repo, validated against a schema you define, with type-safe queries in your pages. Frontmatter typos fail the build instead of shipping. That is a meaningful slice of what teams buy a headless CMS for, provided the people editing content are comfortable in a git repository.

This changes the shape of the decision. Elsewhere the choice is which CMS; on Astro it is whether the content belongs in the repository or in a service, and only then which service. That repository-versus-service question is the git-based versus API-first split that runs through the whole CMS layer of our stack, and Astro is the framework where the git side of it is strongest.

The other Astro-specific fact worth knowing before you evaluate platforms: Astro’s content layer can load from external sources, not just local files. Loaders let a collection be populated from a CMS API at build time, which means the CMS decision is not all-or-nothing. More on that hybrid pattern below.

Start with content collections

Our default recommendation for a new Astro site is to start with content collections and no CMS, and let a real publishing bottleneck justify the upgrade. What you get for free:

• Versioned content. Every edit is a commit; every launch is reviewable and revertible. Content and the code that renders it change together in one pull request.
• A typed schema. Collections validate frontmatter at build time. This is the discipline a CMS content model gives you, without the platform.
• Zero platform cost and zero integration surface. No webhooks, no preview infrastructure, no API keys, no vendor. Preview is a branch deploy.
• A clean exit path. Structured markdown migrates into any CMS easily. The reverse trip is harder, so starting in the repo keeps your options open.

The honest limits: editing requires git fluency or tooling on top of it, there is no in-context preview for a non-technical editor, no roles or approval workflow, and publishing cadence is tied to your deploy pipeline. Those limits are irrelevant right up until a marketing team hits them, and then they are the whole problem.

The test we use in audits is the same one from our React CMS guide: count the people who need to publish without a developer in the next twelve months. Zero or one, collections. A marketing team with a campaign calendar, keep reading.

The shortlist, when marketers need to publish

Every major headless CMS works with Astro; the platforms below are the ones that keep earning their place in our Astro builds. Component-shaped content modeling, which applies to any component-based front end, is covered once in the React guide and matters just as much here.

Storyblok: the marketer-led default on Astro

Storyblok is our most common answer when an Astro site has a marketing team behind it. The visual editor lets editors compose pages from your Astro components and see the real front end while editing, and the official Astro SDK makes the integration a supported path rather than a science project. Folder structures, roles, and locale handling hold up on multi-market estates. We built Carbon Removal Alliance on Astro and Storyblok in production. Skip it when your content is relational data rather than pages.

Sanity: structured content feeding more than a website

Sanity fits Astro projects where content is really a dataset: reused across the site, an app, and other channels, with an authoring experience worth engineering effort. The official Astro integration is solid, and Astro’s server-first rendering pairs well with content-as-data. The considerations are the same as on any framework: someone must own the code-defined Studio, and the editing experience is as good as the effort invested in it. One nuance: Sanity’s Studio is a React application, which is no obstacle in Astro but does mean the authoring tool lives outside your Astro codebase’s zero-JS philosophy.

Contentful: when governance leads

Contentful comes up when the organization, not the website, sets the requirements: roles, workflows, environments, audit trails, and a vendor procurement already knows. The Astro integration path is plain API consumption and well documented. Pick it for multi-team estates that need guardrails; budget honestly for the cost curve at scale. The head-to-heads are at Sanity vs Contentful and Contentful vs Storyblok.

DatoCMS: multi-locale marketing sites with strong defaults

DatoCMS delivers clean structured content, a GraphQL API, and localization as a first-class model dimension, with less configuration ceremony than the bigger platforms. It suits content-heavy Astro marketing sites in several languages where you want good defaults rather than a platform to tailor. Skip it when procurement wants a bigger vendor footprint.

Also seen in the wild: git-based CMS tools that put an editing UI on top of repository content are a middle path for small teams, and self-hosted options like Strapi or Payload apply to Astro exactly as they do elsewhere; Payload’s strongest case is on Next.js, covered in that guide.

The hybrid pattern: collections and a CMS together

The choice is not binary, and the estates we build increasingly run both. Two patterns work well:

Split by content type. Documentation, changelogs, and engineering content live in content collections, authored by the people who commit code. Marketing pages, landing pages, and localized campaign content live in the CMS, owned by marketing. Each team gets the workflow that fits it, and neither blocks the other.

Load the CMS into the content layer. Astro’s loader API lets a collection be populated from an external API instead of local files, so CMS content arrives through the same typed, queryable interface as your markdown. Your templates do not care where content came from, which keeps the door open to moving content between repo and CMS later without rewriting pages.

The hybrid costs you two workflows to maintain, so it earns its keep only when two genuinely different groups author content. When in doubt, start with collections alone; the hybrid is an easy retrofit.

At multi-brand, multi-market scale

Astro handles large estates well, and the CMS questions at that scale are mostly the governance and localization questions covered in the React guide. Three Astro-specific notes:

• Publishing cadence meets build times. Classic static builds rebuild on publish, and at tens of thousands of pages that latency becomes a marketing problem. Astro’s server rendering and incremental approaches change the calculus; decide the rendering strategy and the CMS webhook wiring together, not separately.
• A shared component library is the multiplier. One set of components themed per brand keeps five sites coherent and makes the CMS block library a governance layer. This is exactly the gap our open-source bejamas/ui fills: Astro-native, copy-and-own components with zero-JS defaults, built for monorepos and multi-brand systems.
• Protect what the estate has earned. At this scale the migration, not the platform, is the main risk to rankings and content; our headless CMS SEO guide covers what silently breaks.

Where we stand

Bejamas is an official Astro partner: we build client estates on Astro, maintain open-source Astro tooling, and have direct access to the Astro core team. We are also implementation partners of several CMS vendors above, and we resell none of them; in an audit, “stay on content collections and spend the CMS budget elsewhere” is a recommendation we actually make. The evaluation of Astro itself, including when we would steer you to Next.js instead, is at our Astro page and Astro vs Next.js.

Common questions

What CMS should I use with Astro?

Start with Astro’s built-in content collections if developers author your content: typed, versioned, free, and no integration to maintain. Add a CMS when non-developers need to publish independently: Storyblok for marketer-led visual editing, Sanity for structured content reused across surfaces, Contentful for governance-heavy organizations, DatoCMS for multi-locale marketing sites.

Does Astro need a headless CMS?

No. Content collections give Astro a typed content layer over markdown and MDX in your repository, which covers documentation, blogs, and developer-maintained marketing sites completely. A CMS becomes worth its cost when people who do not use git need to publish without engineering help.

Can I use Astro content collections and a CMS together?

Yes, and it is a pattern we recommend: repository content for docs and engineering-authored pages, a CMS for marketing-owned pages. Astro’s loader API can also populate a collection from a CMS, so both sources flow through one typed interface and templates stay source-agnostic.

Is Astro good for large, multi-brand websites?

Yes, with the right architecture: server-first rendering keeps pages fast by default, and a shared Astro component library themed per brand keeps a multi-site estate coherent. The decisions that matter at that scale are rendering strategy, CMS governance, and the migration plan for the traffic the estate already earns.

Storyblok or Sanity for Astro?

Storyblok when marketers compose pages and need to see the front end while editing; its visual editor plus the official Astro SDK is the strongest marketer experience on Astro today. Sanity when content is structured data feeding multiple surfaces and a developer team will invest in the authoring experience. Both are proven with Astro; the difference is who owns publishing.