This chapter examines the "content in the repo" family of CMSs — systems where the canonical store of content is plain text (Markdown, MDX, YAML, JSON, TOML) committed to a Git repository rather than rows in a database. We cover the major 2025–2026 players (TinaCMS, Decap CMS, Keystatic, CloudCannon, Pages CMS, Outstatic), the underlying model of treating content as code, how editorial UX is layered on top of Git, the framework-native alternative of Astro Content Collections, and the engineering tradeoffs that decide when a Git CMS beats a database-backed one — including why this model is increasingly attractive in the LLM era.
A Git-based CMS makes the Git repository the single source of truth for content. Instead of SELECT * FROM posts, a post is a file — content/posts/hello-world.md — with structured front matter at the top and body content below. Editing the post means committing a change to that file; publishing means merging a branch and triggering a build. Version history, blame, branching, pull-request review, and rollback all come from Git itself rather than being reinvented inside the CMS.
This contrasts sharply with the API-first / database headless model (Contentful, Sanity, Strapi, Payload, covered elsewhere in this report), where content lives in a managed datastore and is delivered over a REST or GraphQL API at request or build time. The Git model trades the database's scalability and real-time editorial machinery for portability, transparency, and a unified Git-native developer workflow. As Strapi's own comparison frames it: Git is excellent for "rapid setup, guaranteed versioning, and simplicity," while API-first systems "provide more features, are more scalable, and offer more flexibility" (Strapi, Git-based vs API-first CMS).
The key insight is that the CMS becomes a thin editorial UI on top of files. The hard parts — storage, history, access control to the repo, CI/CD — are delegated to Git providers (GitHub, GitLab, Bitbucket, Azure DevOps) and the existing build pipeline. What the CMS adds is a friendly form-based or visual editor so that non-developers never have to touch a git command.
| CMS | Vendor / origin | Storage |
|---|
| Editor model |
|---|
| Hosting model |
|---|
| License |
|---|
| Pricing (2026) |
|---|
| TinaCMS | Tina (open source) | MD/MDX/JSON in Git, GraphQL data layer | Inline visual + sidebar forms | Tina Cloud (SaaS) or fully self-hosted | Apache 2.0 (editor) | Free (2 users) → Team $24/mo → Team Plus $41/mo → Business $249/mo → Enterprise custom |
| Decap CMS (ex-Netlify CMS) | Community (was Netlify) | MD/YAML/JSON in Git | Form-based, config-driven | Self-hosted JS widget + Git Gateway/OAuth | MIT | Free / open source |
| Keystatic | Thinkmill | MD/MDX/YAML/JSON in Git | Form-based, typed config | Local mode or GitHub mode + Keystatic Cloud (auth) | MIT | Free / open source (Cloud auth free tier) |
| CloudCannon | CloudCannon (commercial) | MD/data files in Git | Live visual editing + WYSIWYG | Managed SaaS (runs your build) | Proprietary SaaS | From ~$55/mo per site; 21-day trial, no free plan |
| Pages CMS | Open source (Hovenko) | MD/YAML/JSON in GitHub | Form-based responsive UI | Hosted (app.pagescms.org) or self-host (Vercel/Cloudflare) | MIT | Free |
| Outstatic | André Vitório (open source) | MD/MDX in GitHub | Dashboard, collection/document | Embedded in Next.js app or standalone | Open source | Free |
Sources: tina.io/pricing; github.com/decaporg/decap-cms; keystatic.com; cloudcannon.com/pricing; pagescms.org; outstatic.com.
TinaCMS is the most feature-rich of the open-source Git CMSs and the one that most directly challenges the "editors hate Git" objection. Its differentiator is inline visual editing: an editor can click directly on text in a live preview of the site and edit it in a sidebar, with the preview updating in real time (tina.io; Lucky Media, TinaCMS Review 2026). Content is stored as Markdown, MDX, or JSON in the repo, so "your content stays clean, portable, and AI-friendly from the moment you publish" (tina.io).
Architecturally Tina is more than a widget. It introduces a data layer: a GraphQL API that serves the Markdown/JSON files, backed by a database that acts as an ephemeral cache — the files remain the source of truth (tina.io self-hosted docs). This lets Tina offer fast querying and a typed schema while keeping content in Git. You can run this two ways:
mongodb-level), Auth.js authentication, and the GitHub Git provider, deployable on Vercel; MongoDB connection via MONGODB_URI replaces Tina's hosted KV (tina.io self-hosted overview). This eliminates per-seat SaaS cost at the price of running infrastructure.Tina's weak spots are setup complexity (the GraphQL schema + data layer is more moving parts than Decap's single config file) and that its richest experience assumes you adopt the Tina data layer rather than reading files directly.
Decap CMS is the rebranded Netlify CMS, renamed in February 2023 when Netlify handed the project to the community (netlify.com, Netlify CMS to Become Decap CMS). It is the historical default for Jamstack sites: a single JavaScript widget you drop into /admin, configured by one config.yml that declares collections and fields. It stores Markdown/YAML/JSON in Git and authenticates via OAuth or Netlify's Git Gateway.
Its strength is ubiquity and simplicity — Astro, Hugo, and Jekyll all document Decap integration (docs.astro.build). Its liability in 2026 is maintenance velocity: development "slowed materially after Netlify handed the project to the community," and current assessments rate its pace as "noticeably slower than Keystatic or TinaCMS" (Lucky Media, Decap CMS Review 2026). There are community concerns about forks and about the future of Git Gateway now that Netlify Identity is being deprecated (decaporg GitHub Discussion #7419). For new builds, Decap is still a reasonable, dependency-light choice — but teams should evaluate the auth/identity story carefully and not assume Netlify-hosted convenience.
Keystatic, from Sydney agency Thinkmill (the team behind KeystoneJS), is the cleanest modern take on the form-based Git CMS. Released in 2023, it stores content as Markdown, YAML, or JSON in the repo and is configured in TypeScript with 30+ field types — text, slug, date, image, rich text (Markdoc or MDX), arrays, blocks, conditionals, and relationships (keystatic.com; github.com/Thinkmill/keystatic).
Two design choices stand out:
It offers official Astro, Next.js, and Remix integrations and a CLI to scaffold projects. The honest limitation, per the Lucky Media 2026 review, is the absence of native content scheduling, approval workflows, and localization — and the shared scaling ceiling of all Git CMSs (every change is a commit).
CloudCannon is the commercial outlier: a fully-managed SaaS that runs your build for you. You connect a GitHub/GitLab/Bitbucket/Azure DevOps repo; CloudCannon's build farm clones it, runs hugo/jekyll build/astro build on every push, hosts the output on its CDN, and overlays a WYSIWYG visual editor that commits Markdown/data-file changes back to a branch and rebuilds (cloudcannon.com; onout.org, 2026). It has first-class support for Jekyll, Hugo, Eleventy, Astro, and SvelteKit, and uses Bookshop to map components/shortcodes into visual, drag-and-drop editing blocks.
CloudCannon explicitly positioned itself as the Forestry CMS successor (Forestry shut down; Tina was the spiritual successor but CloudCannon ran a "MIGRATE2CC" 50%-off migration). Pricing starts around $55/month per site with no free plan (only a 21-day trial), which is the cost of getting managed builds + the strongest visual editing for static-site generators in this category (cloudcannon.com/pricing). It is the right pick when you want Git-stored content and a polished editor for non-technical marketers but don't want to operate the build/auth infrastructure yourself.
Pages CMS (pagescms.org) is a 100% MIT-licensed, GitHub-native CMS aimed at the "no-hassle" end of the market. It provides a polished, fully responsive (mobile-optimized) UI for managing Markdown, YAML, JSON, and media in any GitHub repo, with fuzzy search, filters, granular per-content-type access control, and content scheduling (one-off or recurring) — features that Keystatic and Decap notably lack (pagescms.org; BrightCoding, Aug 2025). It can connect to AWS S3, Cloudflare R2, and other object stores for media, and editors are invited by email with no extra account.
Crucially, you can use the hosted version at app.pagescms.org for free, or self-host on Vercel or Cloudflare Pages in under five minutes — making it the lowest-friction way to put a real editorial UI on top of a GitHub repo without standing up a database or paying SaaS fees.
Outstatic is a Git-based CMS built primarily for Next.js: you embed a dashboard route in your app (or run it standalone), and it commits Markdown/MDX directly to your GitHub repo with no database or external backend (outstatic.com; github.com/avitorio/outstatic). It uses a collection / document / singleton schema — "a collection is like a table, a document is a record in it" — which mirrors how the other tools structure content. While it runs on Next.js, it can manage content for any consumer (Astro, Gatsby, Nextra) since the output is just files in GitHub. It is the most tightly-coupled-to-framework option here and best suited to teams already all-in on Next.js who want an in-app editor for clients.
Not every "content in the repo" setup needs a CMS at all. Astro Content Collections (and the Content Layer API, GA since Astro 5 in late 2024) give developers a typed, validated way to query local Markdown/MDX/Markdoc/YAML/TOML/JSON directly, with Zod schemas validating front matter and auto-generated TypeScript types (docs.astro.build). The glob() and file() loaders ingest local content; custom loaders can pull from APIs or other filesystems into the same persistent data store, and Astro caches the data between builds so there is "no performance hit" (astro.build, Content Layer: A Deep Dive).
This matters for the CMS conversation in two ways. First, for a developer-only or small-team site, Content Collections plus editing files in VS Code may be all the "CMS" you need — schema validation gives you the data-integrity guarantees a database would, for free. Second, the Git CMSs above (especially Keystatic) integrate into Content Collections as the editing UI, so the two are complementary: Keystatic/Tina/Pages CMS provides the editor; Astro's content layer provides the typed read API. This is the "CMS-agnostic" pattern — define your schema in Astro, swap the editor underneath.
The decision hinges on a small set of structural tradeoffs:
| Dimension | Git-based CMS | Database / API-first CMS |
|---|---|---|
| Source of truth | Plain text in repo (portable, greppable, diffable) | Managed DB (proprietary export) |
| Versioning / audit | Free, native (Git history, blame, PRs) | CMS-specific feature, varies |
| Editorial review | Branch + pull request (powerful but technical) | Built-in workflows, real-time |
| Concurrency / many editors | Weak — commits serialize; merge conflicts on shared files | Strong — row-level, real-time collab |
| Scale (10k+ entries) | Degrades — every change is a commit; build times grow | Designed for it; query at runtime |
| Localization (i18n) | Manual / limited in most tools | First-class in most |
| Scheduling / drafts | Limited (Pages CMS & Tina add it; others lack it) | Standard |
| Infra / attack surface | Minimal — static output, no runtime DB | DB + API to secure and scale |
| Lock-in | Low — your content is just files | Higher — bound to vendor's model/API |
| AI/LLM readability | High — Markdown/diffs are LLMs' native format | Requires API/MCP layer |
Choose Git-based when: the site is content-light to moderate (docs, marketing sites, developer blogs, brochure sites), content changes are reviewed alongside code, you want zero vendor lock-in and a minimal attack surface, the editing team is small, and you value the content being portable plain text. Red-Gate's Simple Talk analysis notes Git CMSs are "strong for docs and developer blogs where content changes are closely reviewed alongside code."
Choose a database CMS when: you have many simultaneous non-technical editors, tens of thousands of frequently-changing entries, real i18n needs, scheduled publishing at scale, or you must drive many diverse frontends from one content model — scenarios where commit-serialization and growing build times become real bottlenecks (StaticMania, Which Git-Based CMS Should You Use in 2025; Strapi).
A genuinely new argument has emerged in 2025–2026: Git-based content is the format AI tools read best. LLMs are trained overwhelmingly on Git repositories, so "Markdown, frontmatter, YAML, folder structures, and diffs" are their native language (CloudCannon, The CMS your AI tools can actually read). When content, code, and config all live as plain files in one repo, an AI agent can read and write content, trace how a content change affects layout, and propose fixes as ordinary commits with a real author, timestamp, and diff — no proprietary schema or translation layer in between.
This is producing a small wave of agentic Git CMS products: GitCMS offers a Notion-like editor plus an MCP app that turns ChatGPT or Claude into content agents while Git stays the source of truth (gitcms.dev); Tina advertises "AI features (coming soon)" on its paid tiers (tina.io/pricing). The database CMSs are responding with MCP servers of their own (Sanity's first-party hosted MCP, Payload's official MCP plugin) precisely because they otherwise lack this native readability (FocusReactive, Agentic CMS in 2026). For teams expecting heavy AI involvement in content operations, the content-as-files model has a structural advantage that did not exist when this category was first defined.