In Produktion seit 2025 · früher Zugang
Ein Headless CMS.
Eine Binary.
Content-Typen als JSON5-Schema. Inhalte als Dateien neben dem Code — diffbar, reviewbar, im Git-Verlauf. Ausgeliefert über eine REST-API. Kein Node-Runtime, keine Pflicht-Datenbank, kein Container-Zoo.
- 1
- Prozess — API und Admin-UI auf einem Port
- 3
- Speicher-Backends, in beide Richtungen migrierbar
- 0
- externe Dienste im Minimalbetrieb
// types/artikel.json5 — Datei rein, Collection da
{
name: "artikel",
fields: [
{ name: "titel", type: "string", localized: true },
{ name: "text", type: "content" },
{ name: "bild", type: "image" },
{ name: "autor", type: "reference", to: "person" },
],
}# kein Build, kein Migrations-Schritt
$ curl rustycms.local/api/collections/artikel
{ "items": [ … ], "total": 42 }Ein CMS sollte kein Infrastruktur-Projekt sein
Die meisten Headless-CMS lösen das Redaktionsproblem und schaffen dafür ein Betriebsproblem. RustyCMS dreht das um.
Der Betrieb frisst die Marge
Node-Prozess, Datenbank, Redis, Object Storage, Reverse Proxy — fünf Dinge, die nachts kaputtgehen können, für eine Website mit 200 Seiten.
Der Content liegt woanders
Code im Git, Inhalte in einer fremden Datenbank. Kein Diff, kein Review, kein sauberer Rollback. Staging und Produktion driften auseinander.
Die Rechnung wächst mit
Pro Sitz, pro Projekt, pro API-Call. Beim SaaS-CMS zahlst du am meisten genau dann, wenn das Projekt endlich läuft.
Drei Schritte, kein Zwischenbau
- 01
Typ definieren
Eine JSON5-Datei in types/ beschreibt die Felder. Datei rein — die Collection existiert. Kein Generator, kein Migrations-Lauf, kein Neustart-Ritual.
- 02
Redaktion arbeitet
Die Admin-UI baut das Formular aus dem Schema: Listen mit Suche und Filtern, bedingte Felder, sortierbare Arrays, Referenz-Picker, Versionshistorie mit Ein-Klick-Restore.
- 03
Frontend holt sich das
REST mit Filtern, Sortierung, Pagination und Volltextsuche. OpenAPI-Spec erzeugt die TypeScript-Typen. Astro, SvelteKit, Next — was du willst.
Was drin ist
Kein Baukasten, den du erst zusammenstecken musst. Das hier ist der Stand der Dinge, in Produktion im Einsatz. Jeder Punkt hat eine eigene Seite mit Details.
Modellieren
- Schemas ohne Migration
- String, Zahl, Boolean, Datum, Rich-Text, Array, Objekt, Referenz, Multi-Select, Bild, Datei, Geo-Koordinate, Zeitraum. Bedingte Felder, wiederverwendbare Partials.
- Vererbung
- Schema-Pakete, die Kollektionen erweitern — pro Feld gemergt, pro Umgebung überschreibbar.
- Mehrsprachig pro Feld
- Ein Feld als localized markieren; die API liefert die angefragte Sprache mit Fallback.
- Schema-Migrationen
- Feld umbenennen oder löschen, über alle Einträge und Umgebungen — mit Dry-Run, bevor etwas passiert.
Redigieren
- Echte Admin-UI
- Aus dem Schema generierte Formulare, bedingte Felder, Bulk-Aktionen, Cmd+K-Suche über alles.
- Alles rückgängig
- Jeder Schreibvorgang wird versioniert: Feld-Diff, Ein-Klick-Restore, Audit-Log über Einträge hinweg.
- Geplantes Publizieren
- published / draft / archived, dazu Publish-at und Expire-at, die ein Hintergrundlauf ausführt.
- Volltextsuche
- Eingebauter Index mit Präfix-, Phrasen- und Feldsuche — pro Sprache, ohne externen Suchdienst.
- Medienverwaltung
- Ordner, Tags, Bildnachweis, Upload-Tickets fürs Handy, Ingest-Optimierung beim Hochladen.
Ausliefern
- Bild-Pipeline
- On-the-fly resize und crop, AVIF/WebP nach Accept-Header, Fokuspunkt, DPR, Blurhash-Platzhalter, zweistufiger Cache.
- Draft-Preview
- Signierte Kurzzeit-Links; die Live-Vorschau streamt den ungespeicherten Formularstand des Editors.
- REST-API
- Filter, Sortierung, Pagination, Referenz-Auflösung, ETags, Batch-Endpoint, OpenAPI-Spec für typsichere Frontends.
- Integration
- MCP-Server für KI-Werkzeuge, Webhooks, Prometheus-Metriken.
- Zugriff & Schlüssel
- API-Keys mit Rollen pro Collection und Space, Sessions, CSRF-Schutz, Brute-Force-Bremse.
Erweitern
- Mehrere Sites, eine Instanz
- Spaces mit eigenem Content, eigenen Sprachen und geteilten Schema-Bundles.
- Fremddaten einbinden
- Externe Collections mappen beliebige HTTP-JSON-APIs read-only ein, mit Cache und Zeitreihen-Historie.
- Plugins
- Kommentare, Formulare, Redirects, Wiki — optional, pro Feature einkompiliert, jeweils mit eigener Admin-Seite.
- Drei Speicher-Backends
- Dateien, SQLite oder PostgreSQL — gleiche API, gleiche Schemas, per store-migrate in beide Richtungen wechselbar.
- Konfiguration zur Laufzeit
- Einstellungen in der Admin-UI ändern, Hot-Reload ohne Neustart, jede Änderung versioniert mit Rollback.
- Export, Backup, Git-Spiegel
- Ganze Instanz als ZIP raus und rein, automatische Backups, Lesekopie des Contents als Git-Arbeitsbaum.
Die API ausprobieren
Dieselbe Listen-Abfrage, die deine Frontend-Fetches machen: filtern, sortieren, blättern, Felder auswählen. Klick dich durch oder schreib die Query selbst.
Läuft vollständig in deinem Browser auf einem Demo-Datensatz — kein Server, keine Anmeldung. Die Query-Syntax ist die der echten API.
Beispiele
GET /api/content/article?
Suffixe: _prefix · _contains · _min · _max · _in · _ne · _exists. Systemparameter beginnen mit _.
Antwort
Die Oberfläche, mit der die Redaktion arbeitet
Mitgeliefert, nicht zugekauft. Gleicher Prozess, gleicher Port.
Für wen das gebaut ist
Entwickler & Freelancer
Du willst ein CMS, das du nicht betreiben musst.
- Eine Binary neben dem Frontend, fertig — kein Node-Prozess, kein Compose-Stack
- Inhalte liegen im Git-Repo: Branch, Diff, Review, Rollback wie beim Code
- Typen kommen aus der OpenAPI-Spec, das Frontend bleibt typsicher
Agenturen
Du hast zwanzig Kundenprojekte und zwanzig Betriebsverträge.
- Spaces: mehrere Sites auf einer Instanz, getrennte Inhalte, geteilte Schemas
- Ein Host statt einer Instanz pro Kunde — der Betriebsaufwand skaliert nicht mit der Kundenzahl
- Kein Sitzplatz-Preismodell, das deine Marge frisst, sobald das Team wächst
Vereine, KMU & Kommunen
Sie brauchen eine Website, die jemand pflegen kann.
- Redaktionsoberfläche in deutscher Sprache, ohne Schulungswoche
- Läuft auf einem Server in Deutschland — Ihre Inhalte bleiben bei Ihnen
- Keine laufende Lizenz pro Redakteurin, keine Vertragsbindung an einen Anbieter
Klein anfangen, ohne sich einzumauern
Drei Speicher-Backends, eine API, ein Schema-Format, eine Testsuite. store-migrate bewegt eine Installation zwischen allen dreien — in beide Richtungen. Die Entscheidung am Projektstart ist damit keine Einbahnstraße.
Für die, die es genau wissen wollen
Rust mit Axum. Ein statisch gelinktes Binary, API und Admin-UI auf demselben Port. Kein Node zur Laufzeit, kein Interpreter, keine Pflicht-Datenbank. Läuft auf dem kleinsten vServer, den man mieten kann.
Dateien
Ein Projekt, ein Server, Inhalte im Git
JSON5 auf der Platte. Diffbar, reviewbar, per rsync deploybar. Kein Datenbankdienst im Spiel.
SQLite
Wenn viele Einträge das Dateisystem müde machen
Gleiche API, gleiche Schemas. Eine Datei, ein Backup.
PostgreSQL
Mehrere Instanzen, SQL-Abfragen, echte Last
Indiziert, per SQL abfragbar, mehrere Prozesse auf einer Datenbank — plus read-only-Spiegel zurück ins Git.
Läuft bereits
Kein Prototyp. Diese Seiten werden täglich von Nicht-Entwicklern gepflegt, auf einem einzigen vServer.
Früher Zugang
RustyCMS ist noch nicht allgemein verfügbar. Sag kurz, was du damit vorhast — ich melde mich mit einer ehrlichen Einschätzung, ob es zu deinem Projekt passt.
- · Kein Newsletter, kein Tracking, keine Weitergabe.
- · Die Anfrage landet direkt in meinem Postfach — betrieben auf RustyCMS.
- · Preismodell steht noch nicht fest. Wer früh dabei ist, redet mit.
Fragen, die zuerst kommen
- Ist RustyCMS Open Source?
- Aktuell nicht. Der Quellcode ist geschlossen, das Lizenz- und Preismodell steht noch nicht fest. Wer früh dabei ist, wird bei der Entscheidung gefragt.
- Was brauche ich zum Betreiben?
- Einen Linux-Server und die Binary. Im kleinsten Aufbau kein Datenbankdienst, kein Node, kein Docker. Wer Container will, bekommt ein Image.
- Womit baue ich das Frontend?
- Womit du willst. RustyCMS liefert nur die REST-API und eine OpenAPI-Spec. Im Einsatz sind derzeit SvelteKit und Astro.
- Kommen wir da wieder raus?
- Ja, und das ist Absicht. Im Datei-Modus sind deine Inhalte lesbare JSON5-Dateien in deinem Git — auch ohne RustyCMS. Export und Import gibt es zusätzlich.
- Wie viele Inhalte verträgt das?
- Der Datei-Modus trägt normale Websites mit Tausenden Einträgen. Darüber wechselst du per store-migrate auf SQLite oder PostgreSQL — gleiche API, gleiche Schemas.
- Gibt es eine Demo?
- Noch nicht öffentlich. Auf Anfrage zeige ich die Admin-UI an einer echten Installation.