What is TinaCMS and how is it different?
TinaCMS keeps content as files in your git repository, Markdown, MDX or JSON, and puts an editing interface on top. Editors change text in a form or directly on the page preview, and each save becomes a commit. Developers query the content through a GraphQL layer that Tina generates from a schema in code. There is no separate content database that holds the truth, so your repository stays the single source.
You can use TinaCloud, the vendor’s hosted backend for auth and indexing, or self-host that backend on your own Node.js function with a database adapter and your own auth. In the self-hosted setup the database is only an index. The files in git remain authoritative.
Who TinaCMS suits
It suits small teams that build with React, Next.js or Astro and want marketing pages, docs or blog content versioned like code. It also suits developers who dislike a CMS that lives in someone else’s database, and editors who want to click on the page and type.
It is a weaker fit for large editorial teams, heavy approval workflows, or content with thousands of records and complex relations. Git is a good store for hundreds of pages. It is a poor store for millions of rows.
What it costs to own
As of October 2026, tina.io/pricing lists a free plan with 2 users, a Team plan at $24 per project per month and a Team Plus plan at $41 per project per month, with higher tiers above that. Self-hosting avoids those fees and moves hosting and upkeep to you. Our cost drivers are the number of collections and templates, how much visual editing you want wired to components, and how many existing pages must be converted.
When we would pick something else
- Non-technical editors who need roles, scheduling and workflow: Sanity or Contentful.
- A lighter git-backed editor with fewer moving parts: Decap CMS.
- A large relational content set: Directus or Strapi.
We compare these approaches in our guide to the best git-based headless CMS platforms.
What we build with TinaCMS
- Fields and templates designed so the files stay clean enough to read in a pull request.
- Click-to-edit wired to your real React components, so what editors see matches production.
- Next.js or Astro sites that read content through the generated client, with draft branches for preview.
- TinaCloud setup, or a self-hosted backend with a database adapter and a git provider.
- Branch based review, so a change goes through the same pull request process as code.
- Existing posts and pages converted to Markdown or MDX with front matter intact, plus redirects. See our migration checklist.
How a TinaCMS project runs
We first look at the repository you already have, or plan the one you need. The content structure in folders and files becomes the schema, so folder naming, front matter and image handling are decided early and kept consistent.
Next we wire editing to your components and test it with the people who will use it, because editors stop using a form that confuses them. We also set the branch and review rules, so editors know whether a save goes live at once or waits for approval. Finally we document how to add a new page type, so the schema does not become a bottleneck.
Limits to know before you commit
Git-backed editing means concurrent edits on the same file can conflict, media lives in the repository or a separate store, and builds must run on each content change. Static output keeps pages fast, but a publish takes as long as a build. We design around this with incremental rebuilds and a media strategy chosen up front.
If you want a React engineer who already works this way, see how to hire a TinaCMS developer. The wider options are on our headless CMS hub.
