Git-Based CMS Options for Static Sites Compared

A static site's content lives in its repository, which is ideal for developers and a barrier for everyone else. Git-based content management systems put an editing interface on top of those files: editors fill in forms and press publish, the CMS commits to the repository, and the normal build and deploy pipeline does the rest. Content stays as Markdown and data files, history stays in Git, and leaving the CMS does not mean migrating content. There are several to choose from, and they differ more than their marketing suggests in how editors preview changes, how review works, how much setup they need and what they cost.

This comparison set up five Git-based CMSs on the same Astro marketing site and blog — Decap CMS, Sveltia CMS, TinaCMS, Keystatic and CloudCannon — and had three editors from the marketing team use each for a week of real tasks. It belongs to Content Workflows for Documentation Teams; the alternative, an API-based headless CMS, is covered in Wiring a Headless CMS to a Static Build.

Method

• Site: Astro 5, 180 blog posts (Markdown with front matter), 40 landing pages (MDX with five components), a team data file, images in the repository.
• Tasks for each editor: write and publish a post with images; change a landing page's hero text and button; add a team member; schedule a post; get a draft reviewed.
• Measured: setup time (one developer), time per task, editor ratings, build-to-live time, monthly cost at five editors.

The Five at a Glance

Setup

TinaCMS took longest because its visual editing needs the site's components to be editable through its React tooling; the payoff came later in the editors' ratings.

Editor Experience

Visual in-page editing (TinaCMS, CloudCannon) made the biggest difference on landing pages: editors clicked the text on the rendered page and changed it there, instead of finding the right field in a long form. For blog posts, form-based editors were nearly as quick. Sveltia was noticeably faster than Decap in daily use — editors mentioned load times and the image picker — with the same configuration.

Review and Publishing

All five can work through branches and pull requests so drafts are reviewed before publishing. Decap and Sveltia have an "editorial workflow" that maps draft, in review and ready to branches and pull requests automatically. TinaCMS and Keystatic save to branches and leave review to GitHub. CloudCannon has its own review flow on top of branches. Every option publishes by committing to the default branch, which triggers the site's normal CI build — on this site 2 minutes 10 seconds from publish to live — so tests and checks run on editor changes exactly as on developer changes. Previews of drafts come from the same per-branch preview deploys developers use, as in Previewing Headless CMS Drafts.

Cost and Lock-In

All five left content as plain files. The only format concern was TinaCMS's rich-text handling of MDX components, which rewrote some component props into its own serialisation on save; after configuring component templates explicitly, round-trips were clean.

Images and Media

Editors upload images far more often than developers expect, and each CMS handles them differently. Decap and Sveltia commit images to a configured media folder in the repository; Sveltia also resizes oversized uploads in the browser before committing, which kept the repository from filling with 6 MB phone photos. Keystatic stores images next to the entry. TinaCMS and CloudCannon can commit to the repository or use an external media store. Because the site's Astro image pipeline optimises everything at build time, committing originals to the repository worked well up to a point; at about 1.5 GB of images, the team moved large originals to Git LFS, which all five tools tolerated. Managing Images in Docs-as-Code Repos covers that trade-off.

Access Control

All five authenticate editors against GitHub (or the CMS's own accounts mapped to a GitHub app), so repository permissions decide who can publish. The site gave the marketing team write access only to content paths using a CODEOWNERS file and branch protection requiring review from the content lead for changes under src/content/, which applied equally whichever CMS made the commit.

Editors' feedback was consistent: they cared about finding the right field and seeing the result, not about Git.

Verdict

• Sveltia CMS for blogs and docs on a zero budget: the quickest setup, plain files, and a clear improvement on Decap, whose configuration it reuses.
• TinaCMS when editors spend most of their time on component-heavy pages and the team uses React; the setup cost buys visual editing.
• CloudCannon when visual editing matters and paying for it is easier than building it.
• Keystatic when developers want the schema in TypeScript next to the code.

The marketing team chose TinaCMS for landing pages; the blog stayed on Sveltia, configured to edit only the posts folder. Two CMSs on one repository worked without conflict because each was scoped to its own paths.

Pitfalls

• Judging on the demo. Run real tasks with real editors for a week.
• Forgetting builds. Publishing triggers a build; editors need to know it takes a couple of minutes.
• Letting the CMS rewrite content formats. Check round-trips on component-heavy files.
• No preview for drafts. Wire branch previews before rollout.

Conclusion

On the same Astro site, five Git-based CMSs all kept content as plain files in the repository, so the real differences were in editor experience and setup. Visual in-page editing (TinaCMS, CloudCannon) roughly halved landing-page editing time and earned the highest ratings; Sveltia gave the best result for posts and docs at no cost and with the least setup.

FAQ

What is a Git-based CMS?

A content editor that reads and writes the Markdown, MDX or data files in your repository, committing changes through Git rather than storing content in its own database. The site keeps building from the repository as before, and content changes go through the same history, review and deploy pipeline as code.

Do Git-based CMSs work with any static site generator?

Most do, because they only edit files. Generator-specific features vary, such as live visual preview, which needs integration with the site's rendering. Decap, Sveltia and Keystatic work with any generator through configuration; TinaCMS's visual editing works best with React-based frameworks; CloudCannon has dedicated support for many generators.

Can non-technical editors use a Git-based CMS?

Yes. The editors in this comparison never saw Git directly; they used forms, rich-text fields and a publish button. The difference from a database CMS is that publishing triggers a build, so changes appear after the build finishes, typically one to three minutes, and editorial workflows map to branches and pull requests.

What is the risk of lock-in with a Git-based CMS?

Lower than with a database CMS, because the content stays as files in your repository in your chosen format. Leaving means replacing the editing interface, not migrating content. Lock-in creeps back if the CMS requires its own content format, component syntax or hosted service for core features.

Related

• Parent: Content Workflows for Documentation Teams — how content gets from writers to production.
• Wiring a Headless CMS to a Static Build — the API-based alternative.
• Docs-as-Code Review Workflow for Writers — review without a CMS.
• Choosing an SSG for a Marketing Site with Non-Technical Editors — choosing the generator for these teams.
• Scheduled Content Publishing With GitHub Actions — scheduling posts the CMS creates.