★ 72,335TypeScriptNOASSERTIONupdated Jun 2026
best for the default pick: biggest plugin ecosystem and either REST or GraphQL out of the box
Strapi is the default pick for a reason: define a content type once and you get REST and GraphQL both, a plugin ecosystem that's actually used, and TypeScript support that reaches the admin panel as well as the API. If you don't have a strong opinion about this category, start here.
The rough edges show up once you're running it for real. There's still no official Docker image — you're pointed at a community tool to generate your own Dockerfile, a strange gap for a project this size. Schema changes made through the admin UI generate migration files that can conflict across team members in ways that are genuinely hard to debug, and the Enterprise Edition walls off audit logs, SSO, and review workflows faster than a mid-sized team expects.
Compare that to Directus, which hands you the same instant-API idea but assumes you already have a database schema, or Payload, which skips the separate admin process entirely by living inside your Next.js app. Strapi's advantage is breadth, not polish — the admin UI itself is noticeably slow to boot on first load, and you'll notice it every morning.
Our full take →GitHub ↗
★ 36,011TypeScriptNOASSERTIONupdated Jun 2026
best for teams with an existing Postgres/MySQL schema who want an instant API and admin UI wrapped around it, not a new content model
Directus solves a different problem than Strapi: you already have a Postgres or MySQL database, and you want an API and admin UI wrapped around it without touching your schema. It introspects what's there and builds on top, which makes it the right call for internal tools and legacy databases that a fresh content model like Strapi's would force you to migrate away from.
The catch worth knowing before you adopt it: Directus is licensed under MSCL 1.0, which is source-available, not open source in the usual sense, and organizations over $5M revenue or 50 employees need a commercial license for 'advanced' features — a line Directus defines, not you, and one that can move. The permission system, with roles, policies, and access layered together, is powerful but takes a real week to get comfortable with, and the docs don't shorten that. At scale you'll also need Redis for caching and pub-sub, which the one-click deploys hide and bare-metal production doesn't.
If you want the instant-API idea but with a cleaner license and no existing schema to protect, Strapi or Payload are the safer defaults.
Our full take →GitHub ↗
★ 42,960TypeScriptMITupdated Jun 2026
best for Next.js shops that want the CMS and the app living in the same TypeScript codebase
Payload installs directly into a Next.js app directory and gives you schema-as-code: define collections in TypeScript and get types flowing from config through to your frontend with no codegen step. The local API — querying Postgres directly from Server Components instead of going over HTTP — is the kind of thing you only appreciate once you've paid the latency tax everywhere else on this list.
The cost of that integration is coupling. Your CMS and your frontend share a process and a deploy, which is fine until you need to scale the admin panel independently of the site, or the admin becomes a performance drag on the app it lives inside. The v2-to-v3 migration was a genuine breaking change with real manual work attached, and the Lexical rich-text editor stores its own internal JSON format — converting that to clean HTML or Markdown means running Payload's own converters and hoping the output doesn't surprise you.
Where Strapi and Directus run as a separate service you talk to over HTTP, Payload only makes sense if you're already committed to Next.js and want one less deploy to manage.
Our full take →GitHub ↗
★ 9,931TypeScriptMITupdated Jul 2026
best for developers who want the content schema defined and type-checked in code, with GraphQL as the only API
Keystone's pitch is the cleanest schema-as-code story on this list: fields, access control, and hooks all live together in TypeScript with real type safety, and the document field stores a structured rich-text tree instead of raw HTML. If you want your content model to read like application code, this gets closer to that than Strapi or Directus ever do.
It's GraphQL-only, full stop — no REST layer exists, so if anyone on your client side isn't bought into GraphQL, you're wrapping it yourself. The migration tooling comes from Prisma, and Prisma migrations bite exactly when you need a complex schema change or have a teammate who doesn't know Prisma's mental model. Keystone 5 to Keystone 6 was a full rewrite that stranded projects on the old version, and there's no built-in caching, CDN hooks, or webhooks — past hobby-project traffic, you're building that yourself through the hook system.
Sanity also commits to a non-REST API, but ships a hosted backend to absorb the operational weight Keystone leaves entirely on you.
Our full take →GitHub ↗
★ 6,209TypeScriptMITupdated Jul 2026
best for teams who want real-time collaborative editing and are fine with Sanity's hosted content backend behind the open-source Studio
Sanity's Studio is open source, but it's a front end for a hosted, proprietary data store — the Content Lake — and that's the trade you're making. In exchange you get real-time collaborative editing built into the same infrastructure as the API rather than bolted on, and GROQ, which handles deeply nested references and joins in one query where GraphQL would make you do multiple round trips.
The lock-in is real: your content lives on Sanity's infrastructure, not yours, and if they raise prices or shut down, migrating out is painful — a different risk profile than every self-hosted option on this list. The free tier is generous but the jump to paid plans is steep and usage-based, so cost gets hard to predict as you grow. Portable Text, their structured rich-text format, is the right idea, but every frontend needs its own renderer and renderer quality varies a lot across the ecosystem.
If an editor is expecting something as simple as WordPress, Sanity's Studio is a large React app with real setup overhead — Decap or Tina's file-based models are closer to that simplicity, just without the real-time collaboration.
Our full take →GitHub ↗
★ 19,438JavaScriptMITupdated Oct 2026
best for static sites that want zero backend — content commits straight into the git repo
Decap — formerly Netlify CMS — is the purest git-as-database option here: content commits straight into your repo, there's no separate database to host or back up, and it supports GitHub, GitLab, and Bitbucket as backends with a real draft, review, publish workflow on top.
Watch the direction, though. The rename came with a new commercial 'Turbo' hosted backend pushed in the README, which signals where the project is headed and is worth knowing before you build years of content workflow on top of it. Performance drags on large content collections since every operation round-trips through your git provider's API and its rate limits, and the Slate-based markdown editor has a history of serialization quirks that surface at the worst time. The 'simple config' pitch also undersells things — customizing the admin UI still requires React and webpack knowledge, so it's not no-code for a team without a frontend developer on hand.
Tina covers the same git-based niche but adds a visual editing layer Decap doesn't have, at the cost of needing a hosted backend to get it.
Our full take →GitHub ↗
★ 13,677TypeScriptApache-2.0updated Jul 2026
best for markdown/git-based sites where editors still want live visual preview while writing
Tina stores content as Markdown, MDX, JSON, or YAML in your own repo, same as Decap, but adds a visual editing overlay — editors click on actual page elements and edit in place, implemented without iframes so it avoids the z-index and routing problems that killed earlier attempts at this. The GraphQL layer over flat files is well done; querying across file references the way you'd query a real database is something Decap can't do without preprocessing.
The catch is that the visual editing — the feature that makes Tina worth choosing over Decap in the first place — needs TinaCloud in production. Self-hosting the backend yourself is possible but underdocumented and clearly second-class, which undercuts the 'your content lives in your repo' pitch exactly when it matters. The schema lives in one TypeScript config file that grows large fast with no splitting strategy shown in the docs, the GraphQL API is read-only since writes go through the CMS and not the API, and the monorepo ships enough interdependent packages that version drift between them has caused real upgrade breakage.
If you don't need the live visual preview, Decap gets you the same git-backed model with less to maintain.
Our full take →GitHub ↗
★ 7,991TypeScriptNOASSERTIONupdated Jun 2026
best for teams who want to self-host on serverless AWS instead of running a persistent server
Webiny is the one pick here built entirely for serverless AWS — Lambda, DynamoDB, S3, provisioned through Pulumi you own and can modify. Multi-tenancy is a real primitive, not a bolted-on flag, and the typed extension model means AI coding agents, including the MCP server it ships for this, produce code that either compiles correctly or fails outright, instead of plausible-looking nonsense.
That AWS commitment is also the trap. There's no abstraction layer, so moving off later is a rewrite, not a config change, and DynamoDB's data model doesn't translate anywhere else — you'll also inherit its limits, like no ad-hoc filtering without scan operations or hand-maintained secondary indexes. The monorepo is enormous, local dev needs two separate watch processes running, and cold deploys for infrastructure changes run five to fifteen minutes. Worse, the README leads with multi-tenancy as a headline feature, but it's actually gated behind the $79/month Business Edition — teams that read the feature list and deploy the free Community Edition hit that wall late.
Nothing else on this list asks you to buy into AWS this deeply; Directus and Strapi both let you run on whatever infrastructure you already have.
Our full take →GitHub ↗
// questions people ask
Before you choose
Is Strapi still the best default choice for a headless CMS?
For most teams starting from scratch, yes — it has the biggest plugin ecosystem and gives you REST and GraphQL without extra setup. The exceptions are teams with an existing database schema, where Directus fits better, and teams already on Next.js who don't want a separate service, where Payload fits better.
What's the real difference between Strapi, Directus, and Payload?
Strapi creates a new content model and database for you from scratch. Directus wraps an existing SQL database you already have, with zero migration required. Payload runs inside your Next.js app itself rather than as a separate service, trading operational simplicity for tighter coupling between your CMS and your frontend.
Should I pick a git-based CMS like Decap or Tina instead of a database-backed one?
Only if your site is already static and you're comfortable with editors committing through Git. Decap is the simpler, more mature option; Tina adds live visual editing but needs TinaCloud to run that in production, which weakens the 'everything stays in your repo' argument.
Which of these only support GraphQL, with no REST API?
Keystone and Sanity are GraphQL-only. Strapi and Directus support both REST and GraphQL, and Payload exposes REST, GraphQL, and a local TypeScript API you can query directly inside Next.js.
None of these are wrong, but they solve different problems — which one fits depends more on your database, your frontend framework, and how much infrastructure you want to own than on star count. If you want repos like these flagged for you before they show up everywhere else, the weekly email does that.