# Sveltia CMS: a Git-based headless CMS that replaces Decap CMS

> Sveltia CMS is an MIT-licensed, framework-agnostic rewrite of Netlify CMS that serves a single-page admin app from a CDN and commits content straight to your Git repository. It is a strong fit for static sites already on Decap CMS, and a poor fit for teams that want a hosted database and editorial workflows.

**sveltia/sveltia-cms** — Project brief: Leading Git-based headless CMS. Successor to Netlify/Decap CMS. Modern UX, first-class i18n support, mobile support + 100s of improvements. Framework-agnostic, open source & free.

- Repository: https://github.com/sveltia/sveltia-cms
- Website: https://sveltiacms.app/en/
- Stars: 2,883 · Forks: 217
- Language: JavaScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/sveltia-sveltia-cms

## What Sveltia CMS solves, and who it is for

Netlify CMS became Decap CMS, and the README states plainly that it "has been neglected for years." Sveltia CMS is a complete modern rewrite of that project, positioned as its de facto successor. The problem it addresses is narrow and real: a static site generator gives you fast builds and cheap hosting, but it leaves non-technical editors with no interface. They either edit Markdown in a text editor or ask a developer to do it.

Sveltia CMS supplies that interface as a single-page web application. The README describes it as "a small, maintenance-free, single-page web application served from a CDN," which is the architectural claim that matters most. There is no CMS server to run, patch, or pay for. Content is written into your Git repository, so the repository stays the source of truth and the build pipeline is unchanged.

The audience is split. On one side are content editors who need a form-based UI rather than a diff. On the other are developers maintaining a Jamstack site who do not want to add a database, an API layer, and a second deployment target just so someone can publish a blog post. The README also names people "moving away from a traditional CMS or website builder" and looking for something lightweight that pairs with Astro, Eleventy, or Hugo. Framework-agnostic is meant literally: the README says it works for vanilla JavaScript sites too.

## How the Git-based content flow actually works

The mechanism is commit-based, not database-based. The admin application runs in the browser, reads a configuration file that describes your collections and fields, renders editing forms from it, and writes the resulting files back to the repository through your Git provider. Because the app is static and CDN-served, the only server-side component in the picture is whatever handles authentication for the Git provider. That is why the README can call it maintenance-free: there is no application server in the request path.

This design has consequences worth stating directly. Every save is a commit, so your content history is your Git history, and review, revert, and blame come for free. It also means the CMS is only as available as your Git host and your static hosting. If the repository is unreachable or the OAuth flow breaks, editors cannot publish, and there is no offline queue.

Compatibility with existing installations is an explicit goal. The README says the project "incorporates numerous enhancements while maintaining high compatibility with existing installations," and claims 320 issues from the Decap repository have been solved here, or 740 including duplicates. Treat those numbers as the maintainer's own accounting, not an independent audit. The practical implication is that a Decap config is intended to be a starting point rather than a rewrite, which is the main reason migration is worth considering at all.

Internationalization is called out as first-class rather than bolted on, and the showcase includes a filter for sites using i18n support. If you run a multilingual site, that is the feature to evaluate first, because it is the area where a Git-based CMS usually forces the most awkward workarounds.

## Installing Sveltia CMS and publishing a first entry

The README points to the documentation for setup and does not inline the install steps, so the authoritative sequence lives at the Getting Started page. The repository does give you the package name and the build tooling: package.json declares the package as @sveltia/cms and defines a build script that runs vite build.

If you are working on the CMS itself rather than consuming it, the repository's own workflow starts with a build:

```bash
pnpm build
```

The package.json also defines a watch variant, build:watch, which runs vite build --watch, and a dev script that runs vite. Those are the commands the repository documents for building and previewing the project.

For a site that consumes the CMS, the setup is a static admin page plus a configuration file that declares the backend, the media folders, and the collections that become editing screens. Because the project maintains compatibility with existing installations, a config.yml carried over from Decap CMS is the intended starting point. Once the admin page and config are deployed, you open the admin URL, authenticate against your Git provider, and create an entry. What you should see is a new file committed to the folder named in the collection, on the branch named in the backend block. If the form renders but saving fails, the failure is almost always in the backend or authentication configuration rather than the field definitions.

## Where Sveltia CMS is the wrong tool

The commit-based model is the limitation, not a footnote. If your editorial process depends on drafts that exist in a staging database and are published on a schedule by someone other than the author, Git commits are a clumsy substitute. Sveltia CMS writes files to a branch; the notion of an unpublished draft that is not a commit is not what this architecture provides.

Authentication is the second constraint. A browser-based admin app must obtain credentials to write to your repository, and that requires an OAuth intermediary. The README does not document the full matrix of providers and hosting combinations, so anyone deploying outside the common path should confirm their provider is supported before committing to the tool. This is also the area where self-hosting gets less trivial than the "maintenance-free" framing suggests: the CMS itself is static, but the auth piece is not.

Third, content that is not file-shaped fits badly. If your content lives in a product database, is generated from a feed, or is queried by an application backend at request time, a Git-based CMS adds a synchronization problem instead of removing one. The README's own framing is Jamstack sites, static site generators, and marketing or knowledge-base content. Outside that, the tool is solving a problem you may not have.

Finally, the version history is worth reading before you plan a migration. The published releases in the repository are in the 0.201 range while package.json carries 0.212.1, so the project is pre-1.0 and the API surface should be treated as still moving. The last push to the repository was on 2026-08-29, which is recent.

## Sveltia CMS compared with Decap CMS and Pages CMS

The comparison that matters most is with Decap CMS, because Sveltia CMS exists to replace it. The README frames the difference as neglect versus active development: Decap CMS is described as having been neglected for years, while Sveltia CMS is a complete modern rewrite that continues to work through issues reported in the Decap repository. The compatibility claim is what makes this a migration rather than a greenfield decision. If your config.yml works, you change the script you load and keep your content. That is a much smaller project than switching to a CMS with a different content model.

The second comparison is with Pages CMS, which appears in the search data alongside Sveltia CMS. Both are Git-based and both target static sites, so the choice is not about the storage model. The distinction to check is which Git providers each supports and how each handles authentication, since that is where Git-based CMSs actually diverge. The README does not document a provider comparison, so this is something to verify against the documentation of both projects rather than assume.

The broader alternative is a traditional headless CMS backed by a database. That approach gives you server-side workflows, roles enforced outside Git, and content that does not require a build to appear. It also gives you a service to run and pay for. The honest split is this: if your content is files and your site is statically built, Git-based wins on cost and simplicity; if your content is relational or your workflow needs approval states, a database-backed CMS wins and Sveltia CMS is the wrong starting point.

## Licence, maintenance cost and upgrade path

The licence is MIT, stated in package.json and in the repository's LICENSE.txt. MIT is permissive: you can use, modify, and redistribute the code, including in commercial projects, provided the copyright notice and licence text are preserved. That is a summary of the licence text, not legal advice; if you are embedding the CMS in a product you distribute, have your own counsel review the notice requirements.

The maintenance cost is genuinely low on the hosting side, and that is the project's central pitch. There is no server process to monitor, no database to back up, and no runtime to patch on a schedule. Upgrades mean rebuilding the static admin page against a newer version of @sveltia/cms and redeploying it, which is the same operation as any front-end dependency bump. The repository's own scripts show the expected workflow: pnpm build runs vite build, and prepublishOnly runs the same build before publishing.

The cost that does not disappear is configuration drift. Your config.yml is coupled to your content structure, and the CMS is coupled to the config. When you add a collection or change a field, you are editing a file that both the CMS and your static site generator read. That is a shared contract, and it needs to be treated as one.

Because the project is pre-1.0, budget for reading release notes between upgrades rather than assuming drop-in compatibility across minor versions. The repository publishes releases frequently, with three in the final week of August 2026 alone, which cuts both ways: fixes arrive quickly, and so do changes.

## Conclusion

Adopt Sveltia CMS if your content already lives in Git, your site is built by a static site generator such as Astro, Eleventy or Hugo, and you either want to leave Decap CMS or start without a database. Do not adopt it if you need server-side editorial workflow, per-field permissions enforced outside Git, or content stored in a hosted database rather than committed as files. Before migrating, verify three things in your own repository: that your existing config.yml keys are accepted, that your Git provider and OAuth setup are supported for the deployment target, and that your editors can work with the commit-based model rather than a draft-and-publish queue.

## FAQ

### What is Sveltia CMS?

Sveltia CMS is an open source, MIT-licensed Git-based headless CMS for Jamstack sites, described in its README as a complete modern rewrite of Netlify CMS, now known as Decap CMS. It runs as a single-page web application served from a CDN and commits content to your Git repository.

### How does Sveltia CMS compare with Decap CMS?

Sveltia CMS is positioned as the de facto successor to Netlify/Decap CMS, which the README says has been neglected for years. It aims for high compatibility with existing installations, so a Decap config is intended to be a starting point rather than a rewrite.

### What is a headless CMS in simple terms?

A headless CMS provides an editing interface for content without controlling how that content is displayed. Sveltia CMS takes this further than most: the content is stored as files in your Git repository, and your static site generator builds the site from them.

### Is there a free CMS I can use with a static site?

Sveltia CMS is free and open source under the MIT licence, and the README describes it as suitable for personal blogs, portfolios, marketing sites and knowledge bases. It is framework-agnostic, so it works alongside static site generators such as Astro, Eleventy and Hugo.

## Sources

- [Official documentation](https://sveltiacms.app/en/)
- [Official README](https://github.com/sveltia/sveltia-cms#readme)
- [Project repository](https://github.com/sveltia/sveltia-cms)
- [Release notes](https://github.com/sveltia/sveltia-cms/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sveltia-sveltia-cms