Sveltia CMS: Der sanfte Umstieg von Decap, ohne die Altlasten
Projektüberblick: Führendes Git-basiertes Headless-CMS. Nachfolger von Netlify/Decap CMS. Modernes UX, erstklassiger i18n-Support, mobiler Support + Hunderte Verbesserungen. Framework-unabhängig, Open Source und kostenlos.
Auf einen Blick
- Was ist das?
- Sveltia CMS ist ein Git-basierter Headless-CMS-Nachfolger von Netlify/Decap CMS. Der Artikel prüft, ob der vollständige Rewrite in JavaScript hält, was die README verspricht, und wo die Grenzen liegen.
- Für wen ist es gedacht?
- Sveltia CMS ist die erste Wahl für Teams, die ein bestehendes Decap- oder Netlify-CMS-Projekt modernisieren wollen, ohne die Inhaltsstruktur neu zu erfinden. Die i18n-Unterstützung und die mobile Bedienung sind echte Argumente, die README nennt 320 gelöste Decap-Issues.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Erbe, das nicht gepflegt wurde
Netlify CMS, später Decap CMS, war lange der Standard für Git-basierte Redaktionssysteme im Jamstack-Umfeld. Die README von Sveltia CMS sagt es deutlich: Decap wurde jahrelang vernachlässigt. Sveltia ist der komplette Neubau dieser Idee, in JavaScript geschrieben, unter MIT-Lizenz. Das Projekt versteht sich als de facto Nachfolger und löst laut README 320 gemeldete Probleme aus dem Decap-Repository, 740 inklusive Duplikaten. Für Betreiber alter Decap-Installationen ist das der zentrale Anreiz. Es geht nicht um ein weiteres CMS, sondern um das gleiche Konzept mit moderner Basis.
Wie die Architektur tatsächlich aussieht
Sveltia CMS ist eine Single-Page-Webanwendung, die von einem CDN ausgeliefert wird. Das ist ein entscheidender Unterschied zu klassischen CMS mit Server-Backend. Die Inhalte liegen in einem Git-Repository, die Redaktion bearbeitet Dateien direkt, und der Workflow bleibt versionierbar. Die README beschreibt das System als wartungsfrei, weil kein eigener Server betrieben werden muss. Framework-agnostisch bedeutet: Es funktioniert mit Astro, Eleventy, Hugo oder auch reinem JavaScript. Der Datenfluss ist simpel: Editor ändert Inhalt, Sveltia schreibt den Commit, der Static Site Generator baut die Seite neu. Diese Kopplung an Git ist gleichzeitig Stärke und Einschränkung, denn sie setzt voraus, dass das Team mit Pull Requests und Branching arbeiten kann.
Erste Schritte und reale Befehle
Die Dokumentation unter sveltiacms.app/en/docs/start beschreibt die Einrichtung. Konkrete Befehle aus der README gibt es nicht, aber der Ablauf ist aus dem Projektkontext ableitbar. Man installiert Sveltia CMS nicht als npm-Paket im klassischen Sinne, sondern bindet die Single-Page-App in die bestehende Site ein. Danach konfiguriert man die Inhaltsmodelle in einer YAML-Datei, wie man es von Decap kennt. Die Migrationsanleitung unter /docs/migration/netlify-decap-cms zeigt, dass bestehende Decap-Konfigurationen weitgehend übernommen werden können. Das ist der wichtigste technische Hebel: Wer Decap nutzt, muss die Struktur nicht neu erfinden. Die README verweist auf 150 migrierte Decap-Sites und 70 WordPress-Migrationen im Showcase, was die Kompatibilitätsbehauptung untermauert.
Wo die Grenzen sichtbar werden
Die zentrale Einschränkung liegt in der Git-Anbindung. Wenn Redakteure ohne technisches Verständnis arbeiten, brauchen sie klare Regeln, sonst entstehen Merge-Konflikte. Die README verspricht eine gute UX, aber sie kann nicht die Tatsache ändern, dass jeder Inhalt ein Commit ist. Ein weiterer Punkt ist die Abhängigkeit von der aktiven Pflege des Projekts. Die README nennt 320 gelöste Issues, das ist ein starkes Zeichen, aber es ist kein Garant für die Zukunft. Wer ein sehr spezielles Widget oder eine exotische Validierungslogik in Decap nutzt, muss prüfen, ob der Rewrite diese Fälle abdeckt. Die README spricht von hoher Kompatibilität, nicht von vollständiger. Für Teams, die ein reines Content-Management ohne Git-Kenntnisse suchen, ist Sveltia das falsche Werkzeug.
Der Unterschied zu Alternativen
Die naheliegende Alternative ist Decap CMS selbst, das weiterhin existiert. Der Unterschied liegt nicht im Konzept, sondern in der Pflege. Sveltia ist der aktive Zweig, Decap das verwaltete Erbe. Wer mit Decap zufrieden ist und keine Probleme hat, braucht keinen Wechsel. Eine andere Richtung ist TinaCMS, das ebenfalls Git-basiert arbeitet, aber einen anderen Ansatz wählt: Tina bindet sich eng an ein Framework und bietet eine visuelle Bearbeitung direkt auf der Seite. Sveltia bleibt bewusst generisch und setzt auf eine separate Oberfläche. Das ist ein Trade-off. Wer die visuelle Inline-Bearbeitung will, muss bei Tina suchen. Wer einheitliche Bedienung über viele Projekte hinweg braucht, ist mit Sveltia besser bedient.
Wartung und Lizenz in der Praxis
Die MIT-Lizenz erlaubt kommerzielle Nutzung ohne Lizenzgebühren, das ist für Agenturen und Firmenprojekte relevant. Der Wartungsaufwand ist gering, weil die App vom CDN kommt und kein Server-Upgrade nötig ist. Die README betont den wartungsfreien Betrieb, was im Vergleich zu serverbasierten CMS wie WordPress stimmt. Aber der Aufwand verschiebt sich: Die Konfiguration der Inhaltsmodelle und die Migration bestehender Daten erfordern einmalige Arbeit. Die Release-Historie zeigt eine hohe Frequenz, drei Versionen in drei Tagen. Das spricht für aktive Entwicklung, bedeutet aber auch, dass man Änderungen im Blick behalten sollte. Ein Versionssprung wie von v0.201.0 auf v0.201.2 kann Verhalten ändern, die Doku unter /docs/roadmap gibt einen Ausblick.
Redaktionelles Fazit
Sveltia CMS ist die erste Wahl für Teams, die ein bestehendes Decap- oder Netlify-CMS-Projekt modernisieren wollen, ohne die Inhaltsstruktur neu zu erfinden. Die i18n-Unterstützung und die mobile Bedienung sind echte Argumente, die README nennt 320 gelöste Decap-Issues. Wer kein Legacy-System hat und volle Kontrolle über den Editor wünscht, sollte zuerst prüfen, ob die Git-gebundene Arbeitsweise zum Workflow passt. Vor der Adoption muss man die eigene Konfiguration gegen die Kompatibilitätsliste der Doku abgleichen, insbesondere bei benutzerdefinierten Widgets und komplexen Validierungsregeln. Wer diese Prüfung scheut, bleibt besser bei Decap oder setzt auf ein Framework-spezifisches CMS wie TinaCMS, das einen anderen Ansatz wählt.
Community-Notizen