At a glance — how these 5 alternatives compare
Our read on each project's adoption, maintenance activity and commercial-use risk, derived from GitHub signals and SPDX license terms rather than star count alone. Sorted by stars. How we score.
| Project | Adoption | Maintenance | Commercial use |
|---|---|---|---|
| ★ 73,290 · TypeScript | Flagship | Active | Low risk Embed in a proprietary product with no copyleft obligation. Split licence — this rates the core component; read the † text for the separately licensed parts |
| ★ 45,141 · TypeScript MIT | Flagship | Active | Low risk Embed in a proprietary product with no copyleft obligation |
| ★ 38,259 · TypeScript | Flagship | Active | High risk Non-OSI terms restrict commercial or hosted use — read first |
| ★ 13,825 · TypeScript Apache-2.0 | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation |
| ★ 6,352 · TypeScript MIT | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation |
† Licenses marked † were read from the repository's LICENSE file on 2026-09-05 (linked, pinned to the commit we read) because the GitHub API returned no SPDX id for them. Unmarked licenses are the GitHub API's SPDX classification.
The alternatives
🚀 Strapi is the leading open-source headless CMS. It’s 100% JavaScript/TypeScript, fully customizable, and developer-first.
strapi/strapi Updated 2026-10-08 payload
Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a headless CMS or for building powerful applications.
payloadcms/payload Updated 2026-10-08 The flexible backend for all your projects 🐰 Turn your DB into a headless CMS, admin panels, or apps with a custom UI, instant APIs, auth & more.
directus/directus Updated 2026-10-07 tinacms
TinaCMS is the leading open-source headless CMS that supports Markdown and Visual Editing. Your content is stored in your own GitHub repo 🦙 ❤️
tinacms/tinacms Updated 2026-10-08 sanity
Sanity Studio – Rapidly configure content workspaces powered by structured content
sanity-io/sanity Updated 2026-10-08 Editor's take
Yusuke Morinaga · last revisited · star counts quoted in the text (≈) are as of that date; the cards above are refreshed daily
Five headless CMSes, but the real question is which one owns your content model.
Every project on this list will serve structured content over an API, so the star counts tell you almost nothing useful about which to choose. The axis that actually decides it is: where does your schema live, and who is allowed to change it? Contentful keeps the model in Contentful’s cloud, edited through its web UI. The open-source replacements answer that question five different ways, and that answer — not feature parity — is what you are picking.
Strapi (≈73.1k★, TypeScript, MIT for the Community Edition) is the
obvious default, and for most teams leaving Contentful it is the right one.
The GitHub API returns no SPDX id for it, so the card shows what we read in
the LICENSE — the Community Edition is MIT, with the ee/ tree under
separate Enterprise Edition terms. The schema lives in your database, edited
through an admin UI that non-developers can use, which is the closest
operational match to Contentful’s “editors manage content types” workflow.
If your blockers were the per-API-call pricing and the lock-in, Strapi
removes both, and it is the project with the deepest plugin ecosystem here.
Payload (≈44.6k★, TypeScript, MIT) flips the model: the schema is code, defined in TypeScript config and version-controlled with your app. This is fantastic if your content model is owned by engineers and you want schema changes to go through code review and CI like everything else — and actively annoying if a marketing team expected to add fields without a deploy. Payload is also a genuine MIT license with no enterprise asterisk on the card, which makes it the cleanest licensing story in this group. Pick it when “developers own the model” is a feature, not a bug.
Directus (≈37.7k★, TypeScript) is the database-first bet — you point it at an existing SQL database and it wraps your real tables in an admin and an API. This is the only project here that fits the scenario “I already have a production database and I just want a CMS layer on top of it” without forcing a migration into the CMS’s own schema. It is the wrong pick if you are greenfield and wanted the CMS to define the data model for you.
TinaCMS (≈13.8k★, Apache-2.0) and Sanity (≈6.3k★, MIT) are the two I would only reach for in specific cases. Tina’s bet is Markdown + visual editing on top of a Git-backed content source — excellent for a docs site or a marketing site whose content sensibly lives in the repo, a poor fit for a high-volume content operation with hundreds of editors. Sanity’s open-source piece is the Studio (the editing UI); the structured-content backend it talks to is Sanity’s hosted service, so “self-hosted Sanity” is not really the same independence story as the other four. If avoiding a hosted backend was the whole reason you left Contentful, that nuance matters.
The honest gap
The one thing none of these hands you for free is Contentful’s globally CDN-cached delivery API with sub-50ms responses worldwide. With self-hosted Strapi or Directus you are responsible for the caching tier in front — a CDN, edge caching, or a read replica strategy. For a content-heavy marketing site with global traffic, budget that as real infrastructure work, not an afterthought. It is the single most underestimated part of the migration.
Comparison notes
Three open-source CMSes cover most of what Contentful does, each from a different angle. Strapi is the most widely adopted, with a configurable content-type builder, REST and GraphQL APIs, and a plugin ecosystem. Directus comes at it database-first, wrapping an existing SQL database, while Payload CMS is TypeScript-native and defines schemas in code. The harder things to match are the performance and polish layers. Contentful's CDN-delivered API answers globally in under 50ms, and reproducing that on self-hosted Strapi takes real infrastructure work; its rich-text editor and asset pipeline (image resizing and format conversion through the Images API) are also more mature. Localization is a similar story — Contentful's reach across 50+ locales is achievable in Strapi but only with extra setup.
Migration tips
- Export Contentful content using the contentful-export CLI tool — exports content types, entries, and assets as JSON
- The contentful-import CLI can import this JSON into another Contentful space; for OSS tools, a custom transformation script is required
- Map Contentful content type field validations to your target CMS's equivalents — required fields, regex patterns, and range limits
- Migrate assets (images, PDFs) to your target storage — update asset URLs throughout content entries
- Update all frontend API calls from Contentful's CDN endpoints to your new CMS API — test each content type's query and response shape
Which alternative should you pick?
Replacing Contentful isn't a single call — it's a trade between license terms, team size, and how much early-stage roughness you can absorb. The 5 projects above split along those lines:
- You want the project with the most GitHub stars in this list → strapi. 73,290★ — the most of the 5 projects here. Stars measure attention, not quality or maintenance; check the last-push date and the Editor's take before reading more into it.
- You ship commercial software and need to ship modified code without releasing source → payload. MIT licensed — modify and embed without copyleft obligations.
- You want the project with the most recent push activity → tinacms. Last push 2026-10-08 — the freshest activity in this list.
License & commercial-use notes
When replacing Contentful, the license usually decides more than the feature list — whether you can modify it, ship it inside a product, or host it as a service. The 5 projects here fall into:
- Permissive (strapi, payload, tinacms, sanity) — MIT / Apache / BSD / ISC — modify and embed inside a commercial product with no copyleft obligation. The safest bucket for shipping in a proprietary codebase.
- Source-available (restricted) (directus) — BUSL / Elastic / Polyform / Commons Clause — the source is public but commercial or hosted use is restricted by non-OSI terms. Read the license before any production or commercial use; these are not freely reusable the way an OSI-approved license is.
Split licences: strapi (MIT (Community Edition) + Enterprise Edition terms for ee/). This project is grouped above by the core licence; the separately licensed directories (enterprise or EE parts) are not covered by that bucket — check which files you actually ship.
License fields come from the GitHub API's SPDX classification and can lag a relicense. Where the API returned no SPDX id, the license marked † was read from the repository's LICENSE file on 2026-09-05; the † links to the exact file and commit we read. The repository linked on each card is authoritative — confirm its LICENSE file before any license-sensitive deployment.
Maintenance health of these 5 projects
Of the 5 projects listed, 5 shipped at least one commit in the last 12 months. See how we rank for the full criteria and our self-hosting cost reality check, which apply across every comparison on this site.
Frequently asked questions
How do these 5 alternatives compare on maintenance health?
5 of 5 have shipped a commit in the last 12 months. At least one project here has 5,000+ GitHub stars. Always check the last-pushed date in the cards above and read the latest closed issues — those two signals are the fastest public check we know of.
How this page was compiled
- Repository facts (stars, license, language, last push) come straight from the GitHub public API and are linked on each card as the primary source. Where the API returned no SPDX id, the licence marked † was read from the repository's
LICENSEfile (linked, pinned to the commit we read, with the date checked). - Editorial analysis (the intro, comparison notes and migration tips) is Claude-drafted from Contentful's use case and the alternatives' repository metadata — in Claude Code sessions or scheduled routines run under the operator's account. Samples are spot-checked against the upstream repositories; entries are not individually reviewed unless they carry a signature. See what Claude drafts and what the operator writes.
- Editor's take is signed by Yusuke Morinaga. It was drafted in a Claude Code session the operator ran, then read and confirmed by Yusuke Morinaga before publication, and carries the date it was last revised. It is written from each project's README, LICENSE, release history and issue tracker — not from running the project in production; where that distinction matters, the take says so.
- Maintenance signal: 5 of 5 projects shipped a commit in the last 12 months as of the latest rebuild (most recent activity: ).
- Last editorial review: by Yusuke Morinaga.
- Spotted an error? Email [email protected] with the page URL (subject prefix
[correction]) — we ship corrections within 14 days.