Die Frontend-URL ändert sich, ein Feature-Flag soll an, das Logo wird getauscht — und bisher hieß das: Env-Var anfassen, Container neu bauen, Neustart. RustyCMS trennt Betriebseinstellungen von Bootstrap-Secrets. Was sich im laufenden Betrieb ändert, liegt in _config/admin.json5 und wird ohne Neustart wirksam. Was geheim ist — Session-Secret, API-Keys, Datenbank-URL — bleibt Env-Var und landet nie auf Platte.
Drei Wege, eine Datei
Die Admin-UI rendert unter /admin/settings ein Formular aus dem Schema, das der Server unter /api/config/_schema bereitstellt. Felder, die erst nach einem Neustart greifen, tragen einen Hinweis. Dieselbe Konfiguration lesen und schreiben GET/PUT /api/config/admin, und für Skripte und CI gibt es das CLI:
admin-config --content-dir ./content show
admin-config --content-dir ./content get frontend.site-a.baseUrl
admin-config --content-dir ./content set frontend.site-a.baseUrl '"https://www.example.com"'
admin-config --content-dir ./content validateAlle drei schreiben über denselben atomaren Pfad — Temp-Datei plus Rename, kein halb geschriebener Zustand. Ein öffentlicher Teilausschnitt steht unter /api/config/public ohne Login bereit, damit Login-Seite und Frontend Branding und URLs abholen können; Flags mit dem Präfix _private. bleiben dort draußen.
Auf Platte geändert, im Prozess angekommen
Ein File-Watcher beobachtet _config/ und lädt die Datei innerhalb von etwa 300 ms neu — egal ob sie per rsync, Editor oder Deploy-Skript verändert wurde. Der Hot-Reload liest nur die Datei; er kann keine Rechte erweitern und keinen Code ausführen.
Jede Änderung hat eine Vorgeschichte
Vor jedem Speichern wird der vorherige Stand als Snapshot nach _config/.history/<Zeitstempel>-by-<Actor>.json5 gesichert, die 50 neuesten bleiben erhalten. In der Admin-UI listet eine Sidebar die Snapshots: anklicken zeigt die Vorschau, „Roll back” stellt den Stand wieder her — und sichert davor den aktuellen. Die API liefert dasselbe über /api/config/history und /api/config/history/<id>.
Plugins bringen ihre Sektion mit
Ein Plugin registriert beim Start ein Schema für seine Einstellungen und erscheint damit automatisch als eigener Abschnitt im Formular. Die Werte werden unter plugins.<id> in derselben Datei abgelegt — kein zweiter Konfigurationsmechanismus, kein eigener Endpoint je Plugin.
Was Env-Vars bleiben
Store-Modus, Port, Cache-TTL, Rate-Limits, Backup-Verzeichnis: alles, was der Prozess zum Starten braucht, bleibt Env-Var oder CLI-Flag. rustycms --help listet jede Variable mit Default. Bestehende Deployments, die die Preview-Konfiguration noch als Env-Var setzen, laufen weiter: beim ersten Start ohne admin.json5 wird sie übernommen, admin-config import-env schreibt sie in einem Schritt in die Datei.