Decap CMS vs TinaCMS in 2026: Git-Based CMS Compared

Decap CMS and TinaCMS solve the same problem — give editors a friendly UI on top of markdown files in a git repo — but they take very different routes there. One is a free, config-driven admin panel that commits to GitHub on your behalf; the other is a GraphQL layer with live visual editing and a paid cloud service behind it.

TL;DR verdict: Pick Decap if you want a zero-cost, set-and-forget editing panel for a small static site and you can live with a dated UI and slower maintenance pace. Pick Tina if you want in-context visual editing and typed content queries, and you'll accept either a cloud dependency or some self-hosting work. Neither is the right call once you need relational queries, instant publishing without rebuilds, or content in the thousands of items — that's where git-based hits a wall, and we'll be honest about it below.

Quick side-by-side before we go deep:

Architecture: config.yml vs a GraphQL content layer

Direct answer: Decap is a single-page React app you drop into /admin — it reads a YAML config, talks to the GitHub API, and commits markdown. Tina compiles a TypeScript schema into a GraphQL API that sits between your framework and your markdown files, adding typed queries and a sync layer via Tina Cloud.

Decap's architecture is almost aggressively simple. You add an admin/index.html that loads the Decap bundle, write a config.yml describing your collections and fields, and you're done. There's no server of your own. When an editor saves, Decap calls the GitHub (or GitLab/Bitbucket) API and creates a commit. Your static site generator — Hugo, Eleventy, Astro, whatever — doesn't know Decap exists. It just sees markdown files.

That decoupling is the appeal and the limitation. Decap can't know how your page renders, so editing happens blind in a form, with a best-effort preview pane you have to wire up yourself.

Tina takes the opposite bet. You define your content schema in TypeScript (tina/config.ts), and Tina generates a GraphQL API over your markdown and JSON files. Your site queries content through that API — typed, with autocomplete — instead of reading files directly with fs and gray-matter. In production, Tina Cloud indexes your repo so queries stay fast and editors get auth, and edits still land as git commits underneath.

The trade: Tina is wired into your framework (it grew up around Next.js, with support for others varying in depth), so it shapes how you build. Decap stays out of your build entirely. If you're weighing this against API-first hosted options too, our piece on headless CMS for Jamstack covers when that third path makes sense.

Editing UX: forms vs visual editing

Direct answer: Tina wins this one, clearly. Its contextual editing shows the real rendered page next to the form, updating live as editors type. Decap gives you a competent but plain form-based panel with a markdown preview that rarely matches production styling unless you invest in custom preview templates.

This is the dimension where the two projects feel a generation apart. Decap's editor is the same basic shape it had in its Netlify CMS days: a list of entries, a form with your configured widgets, a rich-text/markdown toggle, and a preview pane. It works. Editors who've used WordPress will find it spartan but learnable. The preview pane renders through your own React preview components if you register them — most teams never do, so editors see unstyled output and learn to ignore it.

Tina's pitch is "click on the thing you want to change." With contextual editing set up, the editor browses the actual site, enters edit mode, and edits content blocks in a sidebar while the real page updates live. For marketing teams editing landing pages with reusable block sections, this is dramatically less error-prone than guessing how a form field maps to a page region.

The honest caveats: Tina's visual editing needs your components to be wired for it — data-tina-field attributes, the right hooks — so it's a build cost, not a checkbox. And markdown-heavy editing (long-form posts, docs) doesn't gain much from visual mode; a form plus preview is fine for an article body.

Local development

Direct answer: Tina is better for local-first workflows. tinacms dev runs the GraphQL API against your local files with zero cloud involvement — edits write straight to disk. Decap needs its separate proxy server (decap-server) to edit local files, and the experience feels bolted on rather than designed.

With Tina, local dev is the default path, not a workaround. You run the dev command, the content API spins up locally, and the admin UI at /admin edits the files in your working tree. Commit when you're happy. This means developers can author content with the same tooling editors use, and you can test schema changes without touching any remote service.

Decap can do local editing via npx decap-server, a small proxy that lets the admin UI write to your local repo instead of going through GitHub OAuth. It works, but it's a second process to remember, and the docs treat it as a development convenience. Day to day, most Decap content edits happen against the live GitHub backend — which means every saved draft is a real commit (or a PR, if you enable editorial workflow), even while you're just fiddling.

One practical note: because both tools ultimately write markdown, your escape hatch is always a text editor. That's a genuine advantage of the whole git-based category — there's no export problem.

Media handling

Direct answer: Both default to committing images into your repo, which gets ugly past a few hundred megabytes. Decap supports external media via integrations (Cloudinary, Uploadcare); Tina offers repo-based media plus Tina Cloud media or external providers. Neither gives you real asset management — no focal points, no on-the-fly transforms out of the box.

Git was never meant to be an image host. Both CMSs will happily commit your editor's 8 MB hero PNG into the repo, and a year later your clones are slow and your git history is bloated. There's no built-in image optimization pipeline in either — that's your static site generator's job or a CDN's.

Decap's answer is media library integrations: point media_library at Cloudinary or Uploadcare in config.yml and uploads bypass the repo. It's a config change, which is nice, but you're now paying for and managing a second service.

Tina ships repo-based media by default, with Tina Cloud offering hosted media management on paid plans (as of 2026), plus support for external providers like Cloudinary and S3. The media manager UI is more modern than Decap's, but the fundamentals are the same: git-based CMSs treat media as files, not as a managed asset pipeline.

If your site is image-heavy — photography, real estate, e-commerce-ish catalogs — this dimension alone should push you toward a database-backed or API-first CMS.

Auth and backends

Direct answer: This is Decap's roughest edge and Tina Cloud's main selling point. Decap relies on GitHub/GitLab OAuth — every editor needs repo access or a Git Gateway setup, and since Netlify deprecated its Identity service, the once-easy path got harder. Tina Cloud handles editor accounts for you; self-hosting Tina means building your own auth.

Think about who's editing. With Decap, the clean path is "every editor has a GitHub account with write access to the repo." For a developer-run blog, fine. For a marketing team of five non-technical people, you're now provisioning GitHub accounts and explaining what a pull request is, or you're standing up an OAuth proxy and an identity service yourself. The community has solutions (self-hosted OAuth providers are a well-trodden path), but it's glue work, and the Netlify Identity deprecation orphaned a lot of older tutorials — as of 2026, expect to do some reading.

Tina Cloud's job is exactly this: editors log into Tina's hosted auth, get role-based access, and never see GitHub. Edits flow through Tina Cloud into commits on their behalf. That convenience is what the subscription pays for. Tina also supports a self-hosted backend mode where you bring your own database (for the content index) and your own auth provider — real flexibility, but you've now signed up to operate a content backend, which erodes the "it's just files in git" simplicity that drew you here.

Hosting and pricing

Direct answer: Decap is free in every sense — MIT-licensed, no hosted service, no tiers. Tina is open source at the core, free for local dev, and monetizes Tina Cloud with a free tier for small teams and paid tiers as seats and projects grow (as of 2026 — check current pricing before committing).

Decap's cost is zero dollars and some of your time. There's nothing to subscribe to because there's no server component at all. Your costs are hosting (which you'd pay anyway) and the occasional afternoon spent on OAuth glue or config debugging.

Tina's model is open-core. The editor and CLI are Apache-licensed and free. Tina Cloud — the hosted content API, auth, and media — has a free tier suitable for small projects, with paid plans adding seats, projects, and support. Pricing specifics shift, so verify on their site rather than trusting any blog post, including this one. Self-hosting the Tina backend avoids the subscription but, as covered above, trades money for ops.

The budgeting question isn't really "free vs paid." It's "whose time gets spent": Decap spends developer hours on setup quirks; Tina Cloud spends dollars to make editors self-sufficient.

Project health and maintenance

Direct answer: Both projects have had bumpy stewardship. Decap is the community-led continuation of Netlify CMS (handed to PM-led maintainership in 2023), and its release cadence has been modest — maintained, not fast-moving. Tina has an active company behind it, though it went through team changes after its acquisition. As of 2026, check recent commit activity yourself before betting a client project on either.

History matters here because both tools have already lived through identity crises. Netlify CMS was the category leader, then Netlify stopped investing, and the project was rebranded Decap CMS under new maintainership. The project survived — issues get triaged, releases happen — but the energy is "stable community project," not "venture-funded roadmap." If you need a feature Decap doesn't have, you're likely writing it or living without it.

Tina started life as a Forestry.io successor with VC backing, and the company has kept shipping — visual editing improvements, framework support, self-hosted backend. The flip side of company-backed: roadmap and pricing follow the business, and acquisitions (TinaCMS was acquired in 2025) can shift priorities. None of this is disqualifying for either project; it's just the standard open-source due diligence. Look at the last 90 days of commits and the open-issue response time, not at the marketing site.

Where git-based content hits its ceiling

Direct answer: Git-based CMSs degrade past roughly a thousand content items or the moment you need relational queries, per-edit publishing without rebuilds, user-generated content, or content that several systems read at once. The repo-as-database model is the feature and the bug.

Be clear-eyed about what you're buying into with either tool:

1. No relational queries. "Show posts by this author in this category, sorted by views" is a database one-liner and a git-based nightmare. Tina's GraphQL layer softens this with filtering and references, but it's an index over files, not a relational engine.
2. A build per edit. Every published change means a site rebuild and deploy. At ten posts a month that's invisible; with a five-person team editing daily, editors wait minutes to see changes live and your CI bill grows.
3. Scale limits. Thousands of markdown files slow down builds, git operations, and (for Decap) the admin UI itself, which lists entries by reading the repo.
4. No dynamic features. Comments, search-as-you-type against fresh content, scheduled publishing without cron-triggered rebuilds, personalization — all of these fight the static, build-time model.
5. Single-consumer bias. The content lives shaped for one site's build. Feeding the same content to an app, a newsletter, and a partner API gets awkward fast.

We've written a longer breakdown of this trade-off in flat-file CMS vs database CMS, and for the specific case of documentation — where git-based genuinely shines — see markdown vs CMS for docs.

Verdict by use case

• Developer blog or portfolio: Decap. Free, simple, and you're the only editor anyway — the auth friction doesn't apply to you.
• Docs site maintained by engineers: Decap, or honestly neither — engineers editing markdown in PRs is already a great CMS.
• Marketing site with non-technical editors: Tina with Tina Cloud. Visual editing plus hosted auth is exactly the gap Decap leaves open.
• Agency building client sites on a budget: Decap if clients edit rarely; Tina if clients edit weekly and will notice the UX.
• Content-heavy site (1,000+ items), multi-channel, or dynamic features: Neither. You've outgrown the category — work through a headless CMS selection checklist and look at database-backed options.

FAQ

Is Decap CMS still maintained in 2026? Yes — it's community-maintained, with releases and triage continuing since the 2023 handoff from Netlify. The pace is steady rather than fast. Check the repo's recent activity before starting a new project on it, as with any community-led OSS.

Can I use TinaCMS without paying for Tina Cloud? Yes. Local development is fully free, and Tina supports a self-hosted backend where you provide the database, auth, and git integration yourself. You trade the subscription for running and securing that backend. Tina Cloud also has a free tier for small projects (as of 2026).

Can I migrate from Decap to Tina, or the other way? More easily than between most CMS pairs — both store content as markdown with frontmatter in your repo. You'll rewrite the config (YAML to TypeScript schema or back) and adjust frontmatter field names, but there's no database export, and your content never leaves the repo.

Which is better for SEO? Neither has an edge. Both output content that your static site generator renders, so SEO depends on your site's templates, performance, and structured data — not the CMS. The build-per-edit model can slow down time-sensitive publishing, which matters if you do news-style content.

Disclosure: we build UnfoldCMS, a database-backed CMS, so we have a stake in the "when git-based hits its ceiling" argument — which is exactly why we don't sell either tool reviewed here. If your project fits the Decap or Tina profiles above, use them; they're good at what they do. If you've hit the ceiling — you need relational queries, scheduled publishing without rebuild hacks, database-backed search, or a REST API (/api/v1/*) serving multiple frontends — that's the gap UnfoldCMS exists to fill. Compare plans when you get there.

Sources & methodology

This comparison is based on the official Decap CMS and TinaCMS documentation, both projects' public GitHub repositories (commit activity, issue trackers, release history), and hands-on setup of each tool against a markdown content folder. Pricing and project-status statements reflect what was publicly visible as of mid-2026 and are hedged accordingly — verify current tiers and maintenance activity on decapcms.org and tina.io before deciding. We have no affiliate or commercial relationship with either project.