Three open source headless CMSs split on where the content lives, and each one makes its own demands on your site. Strapi runs as a separate Node.js server: it keeps entries in a SQL database, serves them over an API to any front end, and keeps review workflows, SSO and audit logs for its paid plans. TinaCMS writes content as Markdown or JSON into your Git repository and turns every production save into a commit, either through its TinaCloud service, which only supports GitHub, or through a serverless backend you assemble yourself. StudioCMS also uses a SQL database but lives inside the Astro project: it requires Astro 7 and server rendering, and has only reached version 0.6.
A database behind an API, or files in the Git repo
Strapi keeps the schema and the content apart. You model types in the admin panel, which writes each one to a schema.json file committed with the code, while entries go to the database. Every type gets a REST API with filtering, sorting, pagination and relations, and the official @strapi/plugin-graphql plugin adds GraphQL on top. Whatever framework the front end uses, all it sees of the CMS is that API. The Content-Type Builder only works in development, so in production a new field means a code change and a redeploy.
TinaCMS treats the repository as the source of truth. Collections are declared in tina/config.ts, from which Tina generates a GraphQL API and TypeScript types, and the docs describe the database that indexes the files as "more of an ephemeral cache". In development, tinacms dev writes straight to the files; in production, a backend receives the edits and commits them. History, diffs and rollbacks therefore go through Git. With TinaCloud's Editorial Workflow, a save no longer lands on the protected branch: it opens a branch and a draft pull request instead.
StudioCMS stores content in a libSQL, MySQL or PostgreSQL database, like Strapi, but an API isn't its main way of serving it. Astro pages read content through a virtual module, studiocms:sdk, and the docs describe the REST API as "primarily used internally by StudioCMS". No front end other than Astro is documented. The project's docs start from two observations: no CMS makes full use of what Astro can do, and Astro alone "requires you to be a developer". Content translations aren't supported, a request open since May 2024, whereas Strapi ships internationalisation in its core.
What each one requires: framework, database, hosting
Read from the repositories and documentation on 7 October 2026.
| Tool | Licence | Content stored in | What you run | Documented front ends | Latest release |
|---|---|---|---|---|---|
| Strapi | MIT, except the ee/ directories | a PostgreSQL, MySQL, MariaDB or SQLite database | a Node.js 22, 24 or 26 server and its database; at least 2 GB of RAM | any, over REST or GraphQL | 5.57.0, 7 Oct 2026 |
| TinaCMS | Apache-2.0 | Markdown, MDX, JSON or YAML files in the Git repo | TinaCloud, or a serverless Node.js function with auth, a database (Vercel KV or MongoDB) and a Git provider | Astro, Next.js, Hugo, Gatsby; visual editing in React or Astro | 3.14.3, 7 Oct 2026 |
| StudioCMS | MIT | a libSQL, MySQL or PostgreSQL database | the Astro 7 site with server rendering, Node.js 22.12 or later; memory not documented | Astro only | 0.6.1, 1 Oct 2026 |
Strapi documents a minimum of 1 core, 2 GB of RAM and 8 GB of disk, and recommends 2 cores, 4 GB and 32 GB. It supports neither MongoDB nor "cloud native" databases such as Amazon Aurora, and publishes no official Docker image: you build your own, by hand or with the community tool @strapi-community/dockerize. The Strapi server is one more service to host alongside the front end.
TinaCMS needs a backend in production to receive edits and commit them. TinaCloud provides one, along with the file index and user management, and its FAQ names GitHub as the only Git provider it integrates with. The self-hosted backend is a Node.js API function, deployed to a serverless platform such as Vercel or Netlify. It combines an auth provider (Auth.js, Clerk or your own), a database adapter, with Vercel KV and MongoDB as the two official ones, and a Git provider that ships for GitHub only: any other forge means writing your own against the GitProvider interface. The FAQ lists three features you lose without TinaCloud: Git-backed media, switching branches at runtime, and search.
StudioCMS has no server of its own: the Astro site serves the dashboard, the login and the API. That site has to run with server rendering, using an Astro adapter that handles SSR routes, the site option, a reachable database and a CMS_ENCRYPTION_KEY, so static file hosting won't do. Since 0.5.0, StudioCMS requires Astro 7, which itself needs Node.js 22.12 or later, and it runs on neither Bun nor Deno. No published version has ever accepted Astro 6, and the project's homepage still says it works with "any Astro v5 project".
Where the projects stand
Strapi ships roughly one release a week: 5.57.0, out on 7 October 2026, is the 44th of the 5.x line since January. Strapi 4 reached end of life on 30 April 2026, and its final release, 4.26.2 on 9 June, patched a data exposure flaw (CVE-2026-27886). Moving to v5 combines an upgrade tool that runs codemods with manual fixes to the affected code. Strapi is also by far the most downloaded of the three: 258,813 npm downloads in the week of 28 September 2026, against 62,778 for tinacms and 660 for studiocms.
TinaCMS has published 39 releases of its main package in 2026, up to 3.14.3 on 7 October, but its breaking changes come through the companion packages. @tinacms/cli moved to 3.0.0 on 14 September, with a new rich-text type that breaks TypeScript code relying on any, then to 4.0.0 on 1 October. A v4 is being built in the same repository under a new npm name, @tinacms/tinacms, not yet on the registry as of 7 October 2026, and its README puts v3 in support mode, bug fixes only. A self-hosted backend that calls @tinacms/datalayer will then have to move to a Level adapter (MongoDB, SQLite or Upstash Redis).
StudioCMS is the youngest. Its 0.1.0 shipped on 15 January 2026, after betas published since September 2024, and six months passed between 0.4.4 and 0.5.0. Its minor releases break things: 0.5.0 dropped Astro 5, and 0.6.0 removed a field from the plugin API. Of the 1,700 commits on the main branch, one developer authored 905 and the Renovate bot 573; the next human contributor has 18.
What the cloud and enterprise plans hold back
Strapi is MIT on two conditions, set out in its licence file: you use no component from the ee/ directories, which ship in the same repository under the Strapi Enterprise licence, and you hold no Strapi Cloud account. The free Community edition keeps the APIs, roles and unlimited usage. Growth, at 45 dollars a month for three seats plus 15 dollars per extra seat, adds Live Preview, Releases, 14 days of content history and Strapi AI; admin SSO is an add-on there, from 150 dollars a month. Review workflows and audit logs exist only in Enterprise, priced on request. Strapi Cloud starts at 35 dollars per project per month, for an instance that sleeps when idle.
TinaCMS is under Apache-2.0, and its FAQ states that the whole CMS, data layer included, is open source. The paid plans are for TinaCloud, a hosted service whose repository, linked from the README, isn't publicly accessible. The free plan covers two users; past that, each project is billed yearly: 290 dollars for three users, 490 dollars for five, 2,990 dollars for twenty. Pull request review through Editorial Workflow starts at the 490-dollar plan, and SSO sits in the Enterprise plan, priced on request.
StudioCMS is under MIT, official plugins included, and its site sells neither a paid edition nor managed hosting.