Tool Directory / CMS
Pick a headless CMS your editors will actually use
A headless CMS is the one piece of your stack that non-developers touch every day, which makes it the only layer where the editing experience outranks the developer experience. This page covers the five options worth shortlisting in 2026, what each one really costs, and the honest case for shipping no CMS at all.
Reviewed August 2026. Back to the tool directory.
What this layer decides
Three things. First, where content lives: in your own database, in a vendor's cloud, or as files in your Git repository. That choice determines your backup story, your migration cost, and whether a content change triggers a deploy. Second, who can publish without you: a marketer with a login, or an engineer with a pull request. Third, what you pay per editor, which is the line item that quietly grows with the team.
The API shape barely matters anymore - REST and GraphQL are table stakes everywhere. What separates these tools is the operational model, so pick by hosting and by team, not by feature checklist.
The five worth shortlisting
Payload
The Next.js community default
Payload installs into your Next.js App Router project and deploys as one application, so there is no second service to host and no network hop to fetch content. Collections are TypeScript config, which means your content types and your app share generated types. MIT licensed and self-hostable on any Node host; Payload Cloud starts around $35 a month if you would rather not. Figma acquired the company in 2025 and the weekly open-source release cadence has continued, with a 4.0 line in beta since spring 2026. payloadcms.com
Sanity
Best real-time editing experience
Fully managed: Sanity hosts the content lake, the asset pipeline, and the CDN, and you customize the Studio as a React app you deploy yourself. Two editors in the same document see each other's changes live, which no self-hosted option here matches. GROQ takes an afternoon to learn and then handles queries other systems cannot express. It is consistently the number two headless CMS by measured usage, and the per-editor pricing (roughly $15 a seat on the paid plan) is predictable for a small team and a real budget line for a large one. sanity.io
Strapi
Fastest-growing open source option
A standalone Node admin panel and API that is framework-agnostic, which is exactly the point: your Astro site, your mobile app, and your Rails service can all read from it. Self-hosting is free and the community edition covers most needs, with Strapi Cloud from roughly $18 a month if you want it managed. It grew faster in self-hosted deployments than anything else in the category this year. The cost is that you are now operating a second application with its own database, upgrades, and uptime. strapi.io
Keystatic
Git-based, no server, no database
Content stays in your repository as Markdown, MDX, YAML, or JSON, and the editing UI commits to a branch through the GitHub API. There is no database, no hosting bill, and no separate backup plan - your content history is your Git history. Free and open source from Thinkmill, with first-class Astro and Next.js integrations. The limits are real: no scheduled publishing, no granular editorial workflow, and every save is a commit, so it suits developer-adjacent teams rather than a marketing department. keystatic.com
Contentful
The enterprise incumbent
Mature, multi-locale, multi-brand, with the roles, audit logs, and compliance paperwork that procurement asks for. If your organization already has a contract, this page is academic. If it does not, list pricing starting in the high hundreds per month plus usage on records, API calls, and locales makes it hard to justify against Payload or Sanity for a single product. Migrating off it later is a genuine project, so enter deliberately. contentful.com
No CMS at all
Markdown in the repo
If the only people editing are the people committing, content collections of Markdown or MDX files give you type-safe frontmatter, zero runtime cost, zero vendor, and review through pull requests. This is the correct answer for documentation sites, developer blogs, and changelogs far more often than the category admits. Add Keystatic later when someone non-technical needs a form. See the static site stack for the full setup.
Which one fits your framework
The right answer depends far more on how your site renders than on the CMS feature list.
| Your site | Use | Why |
|---|---|---|
| Next.js app with a database | Payload | Same deployment, same types, local database queries instead of an HTTP round trip, and an admin panel you can extend with your own React components. |
| Astro content site, developer-run | Keystatic | Keeps the site fully static with no runtime backend, and content lives in the repo where your build already reads it. |
| Astro or SvelteKit with real editors | Sanity | Framework-neutral hosted API with live preview and collaborative editing, and nothing extra for you to keep online. |
| Several apps sharing content | Strapi | A neutral content service that a web app, a mobile app, and a backend can all consume, self-hosted on infrastructure you already run. |
| Multi-brand enterprise | Contentful | Locales, environments, roles, and audit trails out of the box, plus the vendor paperwork a procurement team will ask you for. |
Our pick
Payload if you have a database, Keystatic if you do not
For a Next.js product that already runs Postgres, Payload is the least-regret option in 2026. It adds no new service, shares types with your application code, is MIT licensed so self-hosting stays free forever, and now has a funded team behind it without the license changing. That combination did not exist in this category three years ago.
For a static or Astro content site where the editors are developers, use Keystatic and keep content in Git - no database, no bill, no vendor. Choose Sanity instead when non-technical editors need live collaboration and preview, and Strapi when several separate applications must read the same content from a service you host yourself.
Related layers
Static site stack
Where a Git-based CMS fits into an Astro build.
See the stackNext.js vs Astro
The framework choice that decides this one.
Read the verdictDatabases
What Payload or Strapi will be storing content in.
Browse the layerHosting
Where the CMS and the site actually run.
Browse the layerBuilding the whole product rather than the content layer? The SaaS stack guide assembles every layer at once, and the email API directory covers the other service almost every content site eventually needs.