TinaCMS presents itself as “An open-source, headless CMS with built-in Git version control” — and, more boldly, as “GitHub’s #1 Headless CMS.” The proposition is the one every developer-maintained content site eventually needs: let a non-technical editor change text without taking the content out of the repository.
Content is stored as Markdown files in your Git repository, which the site argues keeps it “clean, portable, and AI-friendly.” The editing experience is described as being able to “Edit content visually while maintaining full developer control.”
Why Git-based matters more than the editor
The visual editing is the demo; the storage model is the decision.
With content as Markdown in your repository, every editorial change is a commit. Your history, review tooling, branch workflow and rollback story all keep working, and if you ever abandon the CMS the content is already in a format you own. Compare that to a conventional headless CMS, where the content lives in someone else’s database and migrating means an export script and a prayer.
That is the whole argument, and it is a strong one for a site that is mostly prose.
Scaffolding a project
One command scaffolds a project:
npx create-tina-app@latestListed framework integrations are Astro, Hugo, Next.js, Jekyll and Jamstack generally. TinaCloud exists as a hosted product alongside the open-source software.
What the site does not tell you
This is where an honest assessment has to stop short, because three things a developer needs are simply not on the homepage.
The licence is not named. The page links to the licence file in the GitHub repository but does not say what it is. For an “open-source” CMS that is an odd omission — open source spans permissive and copyleft, and the difference decides what you can do with a fork. Check the repository before committing.
Pricing is not stated. There are links to pricing and enterprise pages, and paid professional services are mentioned — priority support, onboarding, custom features — without figures. Since TinaCloud is the hosted half of the offering, the commercial terms are something to establish before you build an editorial workflow on it.
The technical shape of visual editing is unexplained. The homepage asserts click-to-edit and in-context editing through testimonials, but not how it works — what a developer marks as editable, what happens to components, what the build requirements are. Nor does it state any limitations. For a feature this central, that is a gap you will have to close from the documentation.
None of these are red flags. They are the reason a homepage is not a sufficient basis for a decision, and the reason this write-up cannot tell you whether TinaCMS suits your project.
How to evaluate it
If you maintain a site someone else writes for, Git-based editing is the right category to shop in, and TinaCMS is one of the two or three names in it — CloudCannon’s Astro offering is a comparable approach worth looking at alongside it.
Three questions to answer before you build:
- What licence does the repository actually carry, and does it permit what you intend?
- What does TinaCloud cost at your content volume, and what breaks if you self-host instead?
- What exactly must a developer annotate for visual editing, and does that work with your component structure?
Run npx create-tina-app@latest on a throwaway project and put a real editor in front of it for an hour. For CMS decisions, that hour is worth more than any amount of homepage reading — the question is never whether the feature list is adequate, it is whether the person who has to use it daily finds it tolerable.
