2 June 2026

What a git-based CMS actually is, and when to use one

Decap, Sveltia, Keystatic and Tina all commit content to your repository. How that works underneath, what it costs your client, and the point where the model stops paying off.

Ask for a CMS recommendation on any static site forum and someone will answer “just use a git-based one”. It is good advice about half the time, and the other half it quietly hands your client a problem they cannot solve. It is worth understanding what the model actually does before betting a project on it.

The idea in one paragraph

A git-based CMS has no database. The editor opens a web interface, fills in a form, clicks save, and the CMS writes a file into your Git repository through the hosting provider’s API. Your content is a markdown file with frontmatter, sitting next to your components. Your CI sees a new commit and rebuilds the site.

That is the whole architecture. There is no content API, no server to run, no data to back up separately, and nothing to pay for. For a category of project it is close to perfect.

What actually happens when someone clicks save

The details matter, because they are where the friction lives.

Authentication. The CMS needs permission to write to your repository. That permission has to come from somewhere, and the somewhere is your editor’s own account, or a proxy service acting on their behalf. Decap historically leaned on Netlify Identity, then on an OAuth app you host yourself. Sveltia authenticates the editor directly against GitHub or GitLab. Keystatic can run in a local mode with no auth at all, or against GitHub for the hosted flow.

Whichever route, the practical consequence is the same: your editor ends up with an account on a developer platform, and a consent screen asking them to authorise an application to write to a code repository. For a developer this is a two-second formality. For a shop owner it is a moment of genuine confusion, and often a phone call.

Writing. The save becomes one or more commits on a branch. Some setups commit straight to the default branch; others open a pull request so a human reviews before publishing, which is a lovely idea for a documentation site and an absurd one for a client updating their opening hours.

Media. Images go into the repository too, unless you configure an external store. This is the part people underestimate. A client who uploads photos from their phone will push twelve-megapixel JPEGs, and those live in your Git history forever. A brochure site’s repository can reach several hundred megabytes in a year of ordinary use, and Git does not forget: every clone pulls every version of every photo ever uploaded.

Publishing. A commit fires your CI. What happens next is between you and your build logs. Nothing in the CMS knows whether the build passed, whether the deploy went out, or whether the page the editor changed is actually being served. The editor clicks save and then, from their point of view, waits for nothing in particular.

Where the model genuinely wins

I want to be fair here, because these tools are good and free.

You are the editor. If you write the content yourself, committing through a form is strictly better than a hosted service: no account, no subscription, no third party, and your content is versioned with your code. For a personal blog or a documentation site this is the correct answer and everything else is overhead.

Content must live in the repository. Some clients require it. Some audits require it. If “the content is in Git, under our control, and leaves with us” is a hard contractual requirement, the discussion ends there and a git-based CMS is what you want.

Your editors are technical. A team of developers editing a docs site will never trip on the GitHub account, will understand the pull request flow, and will actively like that content review works exactly like code review.

The budget is zero and must stay zero. Nothing competes with free.

Where it stops paying off

The GitHub account problem compounds. One client, once, is a support call. Twenty clients is a recurring category of support call, and it arrives at the worst possible moment: the client is trying to fix a typo on their homepage, they are already annoyed, and the answer involves the words “two-factor authentication”.

Content and code share one history. This sounds elegant until you need to restore last month’s price list and find yourself doing archaeology in a repository that also contains a fortnight of your own refactoring. Worse, a client’s mistake and a developer’s bad merge live in the same place and can conflict with each other. We keep content out of the repository on purpose: the schema is code and belongs in review, the client’s copy is not and does not.

Every site is a hand-maintained configuration. A config file per repository, describing every field of every collection, in YAML or in a JavaScript file. Change the shape of a collection and you edit it by hand. Multiply by twenty sites and add the breaking changes that come with each major version of the CMS. This is the part that quietly consumes an agency’s margin: not a big visible cost, just a permanent low-grade tax on every project.

Nobody closes the loop. The editor saves, the commit lands, the build runs, and if it fails, the client’s site silently keeps serving the old page while they believe they published. They find out when a customer tells them. You find out when the client calls.

A word on the state of the tools

Figures surveyed on 4 July 2026, worth rechecking before you commit a client to one:

Decap (formerly Netlify CMS) is the veteran and is maintained at a minimum: releases are rare, the issue tracker is long, and the community has largely moved on.

Sveltia is the energetic successor. It has overtaken Decap in npm downloads and ships fast. It also runs on a single maintainer, has no 1.0, no paid offering, and an interface available only in English and Japanese. That last point rules it out for a French-speaking client regardless of anything else.

Keystatic is the most recent, built by the Thinkmill team, and technically the closest to what we do: schema declared in TypeScript, typed content, a real Astro integration.

Tina is the outlier: git-based underneath, but with a hosted paid tier and a genuinely good visual editing experience.

None of this is criticism. This is the normal, healthy life cycle of open-source tooling. It is simply a question worth asking out loud before twenty client sites depend on one maintainer’s spare evenings.

The decision, stated plainly

Ask one question: who edits, and how many sites are there?

That last row is the whole point. The tool is free, but free tools are paid for in something. With git-based CMSes across a fleet, you pay in onboarding friction, in configuration files maintained by hand, and in the calls you take when a build fails silently.

What we do differently, and what we give up

Menestrel keeps content out of your repository and in a database, which is the single biggest philosophical difference. The schema stays in your repo as TypeScript, so it lives in code review and Git history like the rest of the project. The content does not, because a client’s copy has no business in a codebase.

Your client signs in with an email address. There is no developer platform, no consent screen, no two-factor setup on an account they will use four times a year.

And publishing runs to completion: the click freezes an immutable snapshot, triggers the rebuild at your host, and follows the deployment until the page is genuinely being served. The editor sees “live”, not “saved”.

What we give up in exchange is real and worth stating. We are not free: three euros a month per site. Your content is not in your repository, though it exports in one command as markdown and JSON in content-collections format, on every plan including the free one. And we only support Astro.

If you are already running Decap or Sveltia on an Astro site, the move is the easiest one we support, because your content is already markdown in content collections. menestrel import reads them directly, images included, and builds the schema from what it finds.

The longer version of this comparison, with what each tool does better, is on the git-based CMS comparison page.