Open Source Headless CMS
A headless CMS is not really a website tool; it is a content API that your front ends depend on, which makes the content model a long-term commitment rather than a design detail. Change it carelessly a year in, when a thousand entries and several front ends read from it, and things break in production. The open source options here keep that content store, its schema, and its API on infrastructure you run, so the data your whole front end consumes lives in a database you can query and back up directly. They also differ sharply in philosophy, from visual admins over a database to content kept as files in Git, so the real choice is which model your developers want to live with.
Strapi
Model content visually and Strapi generates REST and GraphQL APIs with a self-hosted admin
Payload
A Next.js native headless CMS that installs in your app folder with a TypeScript backend
Directus
Wraps any SQL database in instant REST and GraphQL APIs, a no-code admin app, and auth
TinaCMS
Git-based headless CMS that edits Markdown, MDX, JSON, and YAML with a GraphQL API
KeystoneJS
Define a content schema in code and get a GraphQL API plus an admin UI for Node.js
Webiny
Self-hosted headless CMS that runs on AWS serverless and is extended with TypeScript
Gentics Mesh
Headless CMS built around content trees, with REST and GraphQL APIs and Elasticsearch search
Our picks
Pick by how your team wants to store and edit content.
Best editor-friendly admin: Strapi Strapi is the editor-friendly default: you design content types visually and it auto-generates REST and GraphQL APIs, with roles, a media library, internationalization, and draft and publish built in. The MIT core self-hosts on SQLite, PostgreSQL, MySQL, or MariaDB.
Best for an existing database: Directus Directus points at a new or existing SQL database without a migration and layers instant REST and GraphQL APIs, auth, and a no-code admin over your real tables. Its source-available license needs a commercial tier for larger companies.
Best for Next.js teams: Payload Payload installs into a Next.js app folder so the CMS and site share one codebase, giving a typed TypeScript backend and React admin you can query straight from React Server Components. It is MIT licensed with auth, drafts, versions, and localization built in.
Best for Git-based content: TinaCMS TinaCMS edits Markdown, MDX, JSON, and YAML files that live in your Git repository and exposes them through a GraphQL API, so every change is tracked like code. Optional visual editing maps fields onto the rendered page.
Choosing a headless CMS that fits your stack
The first fork is where your content should physically live, because these tools disagree about it. TinaCMS keeps content as Markdown, MDX, JSON, and YAML files in your Git repository, so every edit is a commit and version history comes free. Strapi, Directus, and Payload store content in a real database instead: Strapi and Payload generate an admin and APIs from a schema you define, while Directus points at a new or existing SQL database and layers instant REST and GraphQL over your actual tables. Git-based suits developer-led sites with few editors; database-backed suits larger editorial teams that need roles, drafts, and a friendly admin.
Then decide how tightly the CMS should couple to your framework. Payload installs directly into a Next.js app folder so the CMS and site share one codebase, and KeystoneJS is a Node.js backend framework where the schema is the single source of truth for both a GraphQL API and an admin UI. Webiny goes the opposite way, deploying into your own AWS account on serverless services for teams that need that ownership. Each choice trades convenience against how much infrastructure you agree to run and understand.
Finally, test the editorial path and the exit with real content. Confirm how the tool handles relations, localization, drafts, and media before you model a thousand entries around it, and verify that content, assets, and revision history export together rather than piecemeal. A content model is easy to enter and hard to leave, so prove the export works early.
Related categories
Frequently asked questions
How is a headless CMS different from WordPress or a traditional CMS?+
A traditional CMS owns both your content and the final page rendering through themes and templates. A headless CMS manages only the content, its structure, and an API; your site, app, or other client fetches that content and renders it however you like. That separation frees your front-end team from the CMS's templating, but it also means preview, search, caching, and the deployment pipeline become your responsibility rather than built-ins.
Should content live in Git or in a database?+
It depends on who edits and how often. TinaCMS stores content as Markdown, MDX, JSON, and YAML in your repository, so changes are commits with full version history, which fits developer-led sites and a handful of editors. Strapi, Directus, and Payload use a database and a real admin interface, which scales better to large editorial teams that need roles, drafts, and non-technical authoring. Match the storage model to the size and skill of your content team.
Do these support REST, GraphQL, or both?+
Most give you a generated API the moment you define content. Strapi auto-generates both REST and GraphQL per content type, Directus layers instant REST and GraphQL over a SQL database, and KeystoneJS and TinaCMS lead with GraphQL. Payload goes further, letting you query the database straight from React Server Components without an HTTP round trip. Pick based on how your actual front-end stack prefers to consume data, and confirm the API stays stable and permission-aware.
Can I wrap a database I already have?+
Directus is the tool built for that. It points at a new or existing SQL database, keeps your real table structure intact with no forced migration, and layers REST and GraphQL APIs, authentication, and a no-code admin app on top. That lets one database back a website, an app, and internal tools at once, and it means your data is not trapped in a CMS-specific schema you would have to unwind later.
Which fit a Next.js project most naturally?+
Payload installs directly into an existing Next.js app folder, so the CMS and the site live in one codebase and deploy together, including serverless on Vercel or Cloudflare. TinaCMS also works well with Next.js and other frameworks, editing repo-based content with visual, on-page editing. If keeping the CMS and front end in a single TypeScript codebase matters, Payload is the closest fit here.
How does content preview work when the front end is separate?+
Preview has to render unpublished content in the real front end, not just inside the admin screen, which usually needs draft-aware APIs and secure preview tokens. Tools with built-in draft and publish, like Strapi and Payload, expose draft content the front end can request behind a token. TinaCMS takes a different route with visual editing that maps form fields onto the rendered page. Test preview against your real routing and any statically generated pages before committing.
What happens if the CMS project loses momentum?+
Your exposure depends on how deep the CMS sits in your stack. Because these tools store content in standard databases or, in TinaCMS's case, plain files in Git, you keep readable data and documented APIs you can migrate from. A file-based or SQL-backed CMS can also run safely for a while on its last release. The real cost of a stall is that security patches and dependency updates become your team's job, so weigh how much custom code you have built on top.