← Blog
March 6, 2023· 12 min read·Fahim ShariarFahim Shariar

Open Source Headless CMS Options for 2026, Compared

headless cms optionsopen source headless cmsheadless cms comparisongraphqlrest apiself-hosted cms

Headless CMS options in 2026 still split into two jobs: a content studio (write, preview, publish) and an API-first backend (schema, auth, generated endpoints). This page compares open source software you can run yourself. It is for teams choosing an API, a database, a license, and an editor, not for a ranked “best CMS” list.

Try it: open the Apito playground to model a schema and get GraphQL + REST, or start in the console.

The comparison is in Open source headless CMS options compared (2026). If you already know the job, use the quick picks. For how GraphQL fits a headless CMS, see the GraphQL headless CMS guide. For the studio-versus-API split in more detail, see lightweight CMS vs headless CMS.

Quick picks

  • If you want a Node content studio with REST and GraphQL, and you are fine with the CMS creating its own SQL database, start with Strapi.
  • If the content should sit on a SQL database you already run, start with Directus. Read the license before you offer Directus as a competing hosted product.
  • If the CMS should live inside a Next.js app you own, start with Payload.
  • If the product is a publication (posts, pages, members) and a read-only Content API is enough, start with Ghost.
  • If editors should commit Markdown in Git, start with TinaCMS or Decap CMS.
  • If the product is the API, and a rich editorial studio is not the job, read Apito last. It is listed as an option, not as the winner.

Open source headless CMS options compared (2026)

Every cell below was checked against that project’s official docs, site, or GitHub license on 2026-10-08. Where a fact was not on those pages, the cell says “—” or “see docs”.

Tool License Language / stack API out of the box Database(s) Self-host / Cloud Admin / editor UI Best for
Strapi Community Edition is MIT when you do not use ee/ and do not use a cloud account. Enterprise Edition has its own license Node.js REST and GraphQL SQLite, MySQL 8+, MariaDB, PostgreSQL. MongoDB is not supported. Strapi creates the database; it is not meant for a pre-existing one You install and run the app Admin panel: Content Manager and Content-type Builder Content types and an editorial admin, with the CMS owning the SQL schema
Directus Monospace Sustainable Core License (MSCL-1.0-GPL). Use is allowed except a Competing Use against Monospace’s paid offerings of the software Node.js (engines field: Node 22) REST and GraphQL PostgreSQL, MySQL, Oracle, Microsoft SQL Server, SQLite, CockroachDB (pg/postgres, mysql, oracledb, mssql, sqlite3, cockroachdb) Self-host (Docker) or Directus Cloud Data Studio An admin on a SQL database you connect
Payload MIT TypeScript, Next.js REST, GraphQL, and a Node.js API from the config MongoDB and Postgres. Postgres uses @payloadcms/db-postgres (or the Vercel Postgres adapter) against a database you provide Self-host the Next.js app, including one-click Cloudflare or Vercel templates Admin Panel generated from the config A CMS that is also the Next.js app
Ghost MIT Node.js REST Content API (read-only published content). GraphQL: — MySQL by default; sqlite3 is a config option Self-host with Ghost CLI, or Ghost(Pro) Ghost Admin Publishing posts, pages, tags, authors, and members
TinaCMS Apache-2.0 TypeScript GraphQL over the content files Git files: Markdown, MDX, JSON, YAML. Not a separate database Run the app yourself, or use TinaCloud Visual editor with optional live preview Markdown in the repo, queried like structured content
Decap CMS MIT React — (no content REST or GraphQL API). Editors commit through the GitHub, GitLab, or Bitbucket API Git repository next to the site code The CMS is a React app on your static site. Netlify is optional Web editor that commits to Git Static sites whose source of truth is Git
KeystoneJS MIT TypeScript, Node.js, Next.js Admin UI GraphQL at /api/graphql. REST is not generated; you can add routes on the Express app PostgreSQL, MySQL, SQLite (Prisma). SQLite is not intended for production Self-host the Node app. Managed cloud: — Admin UI A GraphQL API plus an admin, defined in code
Cockpit MIT PHP GraphQL and REST MongoDB or SQLite Self-host (Docker image or a PHP install). Managed cloud: — Admin UI for collections, singletons, and trees A small self-hosted content API on PHP
Squidex MIT ASP.NET Core (.NET 8) HTTP API with OData filters and Swagger. GraphQL: — MongoDB, PostgreSQL, MySQL, or SQL Server Self-host (Docker, Kubernetes, IIS, and other listed platforms) or Squidex Cloud Admin for content models A .NET content hub with its own API
Webiny MIT for the repo outside enterprise/ and outside per-package licenses. enterprise/ has its own license TypeScript, React, Node.js, GraphQL, Pulumi GraphQL DynamoDB (content). S3 for assets. Optional OpenSearch Self-host in your AWS account (Lambda, DynamoDB, S3, CloudFront). A generic non-AWS host: — Admin UI; models in the UI or in code An AWS serverless content platform you extend in code
Apito Open-source self-host (see pricing). SPDX name: see docs see docs GraphQL, plus a REST shim where it is exposed Project database follows the published model plan. Named engines: see docs Open-core Engine (CLI or Compose) or Apito Cloud (Free / Pro) Console: model, review, publish When the product is the API, not the editor

Strapi

Strapi is an open-source headless CMS with an admin panel. The Content Manager and Content-type Builder are how editors and developers work with content types. The docs describe REST and GraphQL as part of that setup.

The database config supports SQLite, MySQL 8+, MariaDB, and PostgreSQL. MongoDB and other NoSQL databases are not supported. The same page says Strapi is not meant to be connected to a pre-existing database: Strapi creates and owns that SQL schema.

You install and run the Strapi app yourself. The Community Edition license on GitHub is MIT only when you are not using the Enterprise Edition code under ee/ and you are not using a cloud account. Enterprise Edition has a separate license file.

Strapi fits a team that wants content types and an editorial admin in Node. It is a weak fit when the requirement is “point the CMS at tables that already exist.” A longer Apito comparison is on the Strapi alternative page.

Directus

Directus connects to your database and exposes REST and GraphQL. The admin is the Data Studio. The getting-started docs describe Directus Cloud and self-hosting with Docker. The self-hosting overview says you can run it on your own infrastructure or use Directus Cloud.

The database configuration accepts pg or postgres, mysql, oracledb, mssql, sqlite3, and cockroachdb. The app itself is Node.js: the repository package.json sets the Node engine to 22.

The license file is the Monospace Sustainable Core License, Version 1.0 (MSCL-1.0-GPL). It allows use, copying, and modification except a Competing Use: making the software available in a way that competes with Monospace’s paid offerings of Directus. Read that file before you embed Directus in a product you charge for.

Directus fits an admin on SQL you already operate. See the Directus alternative page if you are comparing that job with an API-first backend.

Payload

Payload’s own docs call it a Next.js framework: a config produces an Admin Panel, database migrations, REST and GraphQL APIs, and a Node.js API, in TypeScript you deploy yourself. The same page names MongoDB and Postgres as the databases.

The Postgres adapter (@payloadcms/db-postgres) talks to a Postgres database you provide, through Drizzle. There is a separate Vercel Postgres adapter. The README also documents one-click deploys on Cloudflare (Workers, R2, D1) and Vercel (Next.js, Neon, Vercel Blob). The license is MIT.

Payload fits when the CMS and the Next.js app should be one codebase. The Postgres docs treat schema changes as migrations Payload generates. Preserving an unrelated existing schema is a hook you write (beforeSchemaInit), not the default path. That is the limitation: you are adopting Payload’s schema workflow, not dropping an editor onto an untouched database.

Ghost

Ghost’s README describes it as an open-source Node.js CMS and points most production installs at either Ghost(Pro) or the Ghost CLI (ghost install on a server, ghost install local for a local instance). The license is MIT.

The config docs set the database client to MySQL by default and document sqlite3 as the alternative. The Content API is a read-only REST API for published content: posts, pages, tags, authors, tiers, and settings, at /ghost/api/content/. This comparison did not find a GraphQL API in that Content API overview, so the table does not claim one.

Ghost fits a publication. It is a poor fit when you need arbitrary collections, a general write API, or a database other than MySQL or sqlite3.

TinaCMS

Tina’s README describes a headless CMS for Markdown, MDX, JSON, and YAML, with a GraphQL API so you can query those files (for example post.author.firstName). It supports static generation and server-rendered pages, and an optional live preview. The license is Apache-2.0.

Content stays in the Git repository. There is no separate database in that description. You can run a starter with npx create-tina-app@latest, or use the TinaCloud demo the README links.

Tina fits a repo-first site where editors should see a visual editor and developers still review Git history. It does not fit a team that wants a hosted content database independent of the site repo.

Decap CMS

Decap CMS, formerly Netlify CMS, is an open-source React app for a Git workflow. The intro says you add it to a static site, editors get a web UI, and content is stored in the Git repository next to the code. The app uses the GitHub, GitLab, or Bitbucket API to make those commits. The license is MIT.

Decap is not tied to Netlify. The same page says you can use Decap without Netlify, Netlify without Decap, or both.

There is no content REST or GraphQL API in that overview. Clients do not query Decap for published content; they read the files the site build already has. That is the limitation, and it is also the point: the source of truth is Git.

KeystoneJS

Keystone’s getting-started guide generates a Node project with a Next.js Admin UI and a GraphQL API at /api/graphql. The first run creates a SQLite database. The system config documents three Prisma providers: postgresql, mysql, and sqlite. The same page says the SQLite provider is not intended for production, and lists field-type limits (decimal, timestamp range, text filters).

GraphQL is the API Keystone generates. REST is not generated for you. The Express extendExpressApp hook is how you add your own routes, including a hand-written REST handler that calls Keystone’s query API. You self-host that Node process. These docs do not describe a managed Keystone cloud. The license is MIT.

Keystone fits a team that wants lists, fields, and GraphQL defined in TypeScript. It is extra work when the client must be REST-only, and SQLite is the wrong production database according to Keystone’s own limitations.

Cockpit

The Cockpit Core README (Cockpit-HQ/Cockpit) describes a headless CMS with collections, singletons, and trees, GraphQL and REST APIs, and either MongoDB or SQLite. The quick start is a PHP install or the cockpithq/cockpit:core-latest Docker image. The license on that repository is MIT.

The README’s feature list includes an admin for those content models, assets, roles, and localization. This comparison did not find a managed Cockpit cloud on that page, so the table leaves cloud as “—”.

Cockpit fits a small self-hosted content API on PHP. It is the wrong default for a Node or .NET team, and you operate the PHP app yourself.

Squidex

Squidex’s README calls it a headless CMS and content hub built with ASP.NET Core and CQRS, tested on Windows and Linux. The install prerequisites list MongoDB, PostgreSQL, MySQL, or SQL Server, and the .NET 8 SDK. The API it describes is an HTTP API with OData filters and Swagger definitions. This README does not mention GraphQL, so the table does not claim it.

Deployment options in the README include Docker, IIS, Kubernetes, Render, and others, plus a SaaS at cloud.squidex.io. The license is MIT.

Squidex fits a .NET shop that wants its own content service and an admin for models. It is a mismatch when the rest of the stack is Node and you need GraphQL specifically.

Webiny

Webiny’s README describes an open-source content platform you self-host on AWS: Lambda, DynamoDB for content, S3 for assets, and CloudFront, provisioned with Pulumi. The stack line is TypeScript, React, GraphQL, Node.js, and Pulumi. The headless CMS section says models can be defined in the admin UI or in code, and that the API is GraphQL.

The license is MIT for material outside the enterprise/ directory and outside packages that carry their own license. The enterprise/ tree has a separate license. Do not treat the whole repository as MIT.

Webiny fits a team that already wants AWS serverless and is willing to extend a TypeScript framework. The limitation is that “self-host” here means your AWS account, not an arbitrary VPS running one container. The README’s architecture section does not describe a non-AWS install.

Apito: when the product is the API, not the editor

Apito is the last row because it is a different job. The docs describe a path from an idea, to a schema you edit locally, to a review of every change, to a human publish. The CLI does not publish on its own. Models are the source of the generated GraphQL API and of a REST shim where that shim is exposed. You run the open-core Engine yourself (apito init / apito start, or Compose) or you use Apito Cloud (Free or Pro). The pricing page describes that self-host path as open source. The docs cited here do not name a SPDX identifier or a list of database engines, so the table does not invent either. The project database follows the model plan you publish.

Use Apito when clients need GraphQL and REST, and schema changes should look like a review before they go live. A lightweight headless CMS page states that product in those words. If you are comparing GraphQL backends rather than content studios, the Hasura alternative page is the closer match. Self-hosting steps are in the self-hosting guide.

Do not pick Apito when the team’s daily work is a rich content studio: preview, blocks, and an editor that non-developers live in. Strapi, Directus, Payload, or Ghost match that job more directly. Apito’s Console is for modeling, review, and publish, not for replacing those editorial tools.

Hosted (not open source) options people also compare

The table above is limited to open source software. These names show up in the same searches. This section does not describe their features.

  • Contentful is a hosted CMS. It is not in the open source table.
  • Sanity Studio is open source under the MIT license in the sanity-io/sanity repository, and the Studio docs call it an open-source content workbench. Content Lake is Sanity’s hosted datastore. Because the content store is hosted, Sanity is not a row in the self-hosted table.
  • Storyblok is a hosted CMS. It is not in the open source table.
  • Hygraph is a hosted CMS. It is not in the open source table.
  • Prismic is a hosted CMS. It is not in the open source table.

How to choose a headless CMS

Use this as a checklist. Stop at the first item that removes an option.

  1. API shape. Do clients need GraphQL, REST, or both? Strapi, Directus, Payload, Cockpit, and Apito document both GraphQL and REST (Apito’s REST is a shim). Keystone and Tina and Webiny document GraphQL. Ghost documents a read-only REST Content API. Decap documents Git commits, not a content API. Squidex documents an HTTP API with OData and Swagger.
  2. Who owns the database? Directus connects to SQL you already run. Strapi’s docs say it is not for a pre-existing database. Payload generates migrations for MongoDB or Postgres you provide. Ghost is MySQL or sqlite3. Tina and Decap store files in Git. Webiny stores content in DynamoDB in your AWS account. Apito’s project database follows the published model plan.
  3. Where it runs. Note Docker or a Node/PHP/.NET process (Strapi, Directus, Ghost, Keystone, Cockpit, Squidex), a Next.js app (Payload), Git on a static host (Decap, Tina), or AWS specifically (Webiny). Apito is the open-core Engine or Apito Cloud.
  4. Editor. If non-developers publish every day, weigh the admin those projects document (Strapi admin, Directus Data Studio, Payload Admin Panel, Ghost Admin, Keystone Admin UI, Cockpit, Squidex, Webiny). If they do not, an API-first Console is enough.
  5. License. MIT or Apache-2.0 covers Payload, Ghost, Tina, Decap, Keystone, Cockpit, and Squidex, with the Strapi and Webiny splits noted above. Directus is MSCL, which restricts competing hosted use. Read the license file linked in the table comment before you ship.
  6. Team stack. Match PHP (Cockpit), .NET (Squidex), Next.js (Payload, Keystone’s admin), or Node (Strapi, Directus, Ghost) to the people who will operate it.

FAQ

What are the main headless CMS options?

For open source software you can run yourself, this page compares Strapi, Directus, Payload, Ghost, TinaCMS, Decap CMS, KeystoneJS, Cockpit, Squidex, and Webiny, plus Apito as an API-first backend. Hosted products that people also compare include Contentful, Sanity, Storyblok, Hygraph, and Prismic. “Main” here means “commonly compared,” not a quality ranking.

Which open source headless CMS supports GraphQL?

From the docs cited above: Strapi, Directus, Payload, TinaCMS, KeystoneJS, Cockpit, and Webiny document GraphQL. Apito’s docs say models generate a GraphQL API. Ghost’s Content API overview documents REST only. Decap’s intro documents Git, not GraphQL. Squidex’s README documents an HTTP API with OData and Swagger, not GraphQL.

Can I self-host a headless CMS on my own database?

Directus is built for that: you connect PostgreSQL, MySQL, Oracle, SQL Server, SQLite, or CockroachDB. Strapi’s database docs say the opposite: Strapi creates the database and is not meant for a pre-existing one. Payload’s Postgres adapter uses a database you provide, and Payload manages schema changes. Ghost can point at your MySQL (or sqlite3) server, but the config is Ghost’s own client settings, not an arbitrary existing schema. Apito’s cited docs say the project database follows the published model plan; they do not, in those pages, list engine names.

Is an open source headless CMS the same as a hosted CMS?

No. The tools in the table publish source you can run, under the license linked for each row. Contentful, Storyblok, Hygraph, and Prismic are hosted products and were left out of the table on purpose. Sanity splits the two: Studio is MIT-licensed open source, and Content Lake is the hosted datastore.

Pick a studio when editors are the user. Pick an API-first backend when the API is the product. Model that second path in the Apito playground, or open the console.