Sveltia CMS: The Editor That Simply Lives in Your Git Repo

21.08.2026 · Wulf

There’s a category of website that doesn’t really need a heavyweight CMS: the company site with 30 pages, a team blog, a documentation site, a set of campaign landing pages. Generated statically, it’s fast, secure, and practically maintenance-free. Only one question remains open — and it often decides the entire setup: how do the people who don’t want to touch YAML edit the content?

That’s exactly the gap Sveltia CMS aims at.

What Sveltia CMS is

Sveltia CMS is a free, open-source, Git-based headless CMS for Jamstack projects. Content stays in your repository as Markdown, YAML, or JSON files; the CMS is simply an interface on top of it. It positions itself as a complete modern rewrite of Netlify CMS, now known as Decap CMS — not a fork, but built from the ground up with Svelte.

The result is remarkably unspectacular in the best possible way: a Git workflow, a YAML config file, a CDN-served app — no database, server, or build tool required. Anyone who has ever maintained a WordPress install with updates, plugin conflicts, and a backup strategy knows how much work is not hiding in that sentence.

The core idea: content belongs in the repository

The real appeal lies less in the CMS itself than in the architecture behind it. When content is files in a Git repo:

• Versioning is free. Every change is a commit, every mistake a git revert.
• Review processes already exist. Pull requests work for prose just as well as for code.
• No vendor lock-in. The content is yours, in an open format, on your platform.
• Nothing can be hacked that isn’t running. There’s no server component, no database, no runtime attack surface.
• Moving is trivial. Clone the repo, deploy it elsewhere, done.

None of this is a new promise — Netlify CMS made it years ago. What’s new is that it now also feels good for the editors.

What Sveltia does better

Sveltia CMS came about because Netlify CMS development stalled for an extended period, and client projects needed one thing above all: better multilingual support. Rather than forking, the app was rebuilt. The visible consequences:

Speed. No React baggage, no virtual DOM, a much smaller bundle. The app starts fast and stays fast even with larger content sets — partly because on GitHub it uses the GraphQL API to fetch entries and assets in one go.

Internationalization as a first-class feature. i18n isn’t bolted on; it’s part of the data model. Edit language versions side by side, control fields per locale, and use one-click AI-powered translation.

Digital asset management. A proper media library rather than a file upload box, including external media storage, stock photo integrations, and a built-in image optimizer.

A UI you actually want to use. Dark mode, keyboard shortcuts, real mobile and tablet support. Editing from your phone is no longer a compromise.

Backend variety. Alongside GitHub and GitLab, Gitea and Forgejo are supported too — relevant for anyone self-hosting their repositories or deliberately keeping data in Europe. There’s also a local workflow that lets you edit content straight from the file system, offline.

Migrating from Netlify/Decap CMS

The most pragmatic aspect: Sveltia is deliberately kept compatible. In many cases, swapping the script tag is enough and your existing config.yml carries over as is. How smoothly that goes depends on which features and custom widgets you rely on — but realistically, getting started costs an hour, not a sprint weekend.

When it fits — and when it doesn’t

Good fit when:

• the site is statically generated (Astro, Eleventy, Hugo, Jekyll, Next.js, SvelteKit …),
• a manageable editorial team maintains the content,
• multilingual content matters,
• operating cost and maintenance effort should stay low,
• content should be versioned traceably in Git.

Poor fit when:

• hundreds of concurrent editors need fine-grained roles,
• content is highly dynamic or must be pulled live from other systems,
• per-user personalized output is required,
• a multi-stage approval workflow with audit requirements is mandatory,
• the team should never touch Git in any form.

One detail worth knowing: the project still describes itself as beta and is largely driven by one person — Kohei Yoshino. Bug fixes land remarkably fast, but if you need a bus-factor argument for your evaluation process, there it is. On the other side of the ledger: it’s open source, it runs entirely client-side, and your content lives in your own repo. Walking away is far cheaper than with a traditional CMS.

Setup in brief

1. Set up a static site with the SSG of your choice.
2. Add a minimal HTML file at /admin/ that loads the CMS script.
3. Next to it, define a config.yml with your backend, media paths, and collections.
4. Set up authentication — GitHub OAuth via a small auth worker, or a fine-grained personal access token.
5. Deploy. From then on, every editorial change becomes a commit, and every commit a build.

Conclusion

Sveltia CMS doesn’t solve a new problem, but it solves an old one considerably better. If you run a static site and have been stuck between “editors can just write Markdown in an IDE” and “fine, let’s use WordPress after all,” here’s a third option: a modern, fast interface with no server to run, no database, and no monthly license.

The best test is the practical one anyway. An existing repo, a config.yml, one afternoon — after that you’ll know whether it fits.