Mehrere Sites, eine Instanz

Eine Agentur betreut zwölf Kundensites. Zwölf CMS-Instanzen heißen zwölf Deployments, zwölf Updates, zwölf Backups. RustyCMS hält stattdessen zwölf Spaces auf einem Prozess: Jeder hat eigenen Content, eigene Assets, eigene Historie, eigene Sprachen — und teilt sich das Binary, die Schemas und die Wartung.

Getrennt, was getrennt sein muss

Ein Space ist ein eigener Content-Raum. Einträge, Bilder, Versionshistorie, Referenz-Index — nichts davon sieht den Nachbarn. Auf Platte ist das ein Verzeichnis pro Space:

content/
├── site-a/    assets/  .history/  page/  post/
└── site-b/    assets/  .history/  page/  post/

Welche Sprachen ein Space führt, entscheidet er selbst: { locales: ["de", "en"] } in seinen Einstellungen, sonst gilt die globale Vorgabe aus RUSTYCMS_LOCALES. Eine einsprachige Vereinsseite und ein dreisprachiger Shop laufen auf derselben Instanz, ohne dass einer die Sprachen des anderen erbt.

Geteilt, was geteilt sein soll

Schemas müssen nicht pro Space kopiert werden. Ein Schema-Paket wird einmal gepflegt, jeder Space abonniert es; wo eine Site abweicht, legt sie einen Override an, der nur das Abweichende nennt. Der Rest kommt weiter aus dem Paket — eine Änderung dort erreicht alle abonnierenden Sites sofort.

Ein Parameter im Request

Jeder Content- und Asset-Endpoint nimmt ?_environment=<name>. Ohne den Parameter antwortet der erste Space aus RUSTYCMS_ENVIRONMENTS, der Default. Das Frontend einer Site setzt den Parameter einmal in seinem API-Client und muss sonst nichts wissen.

GET /api/environments
# → { "environments": ["site-a", "site-b"], "default": "site-a" }

GET /api/content/post?_environment=site-b

Anlegen ohne Neustart

Spaces sind kein Deploy-Thema. Anlegen, duplizieren, umbenennen, löschen — alles zur Laufzeit per API oder auf der Seite „Spaces” in der Admin-UI. Duplizieren kopiert Content, Assets und Historie komplett; so entsteht in Sekunden eine Staging-Kopie der Produktion.

POST /api/environments/site-a/duplicate
{ "name": "site-a-staging" }

Namen bestehen aus a-z, 0-9, - und _. Der letzte verbleibende Space lässt sich nicht löschen, alle Schreiboperationen brauchen Schreibrechte.

Zugriff pro Space

Ein API-Key kann auf Spaces eingeschränkt werden: In RUSTYCMS_API_KEYS_JSON steht pro Key eine Liste erlaubter Environments, optional auch erlaubter Collections. Der Key im Frontend von Site B liest nur Site B. Dasselbe gilt für Benutzer der Admin-UI — allowed_environments bestimmt, welche Spaces jemand überhaupt sieht. Admin-Rollen sind von beiden Listen ausgenommen.

Was nicht passiert

Löschen ist endgültig — es gibt keinen Papierkorb für einen ganzen Space, dafür das Auto-Backup pro Environment. Im Postgres-Modus, wo der Content in Tabellenzeilen statt Verzeichnissen liegt, gehen Anlegen und Auflisten; Duplizieren, Umbenennen und Löschen antworten dort mit 422, weil sie Verzeichnisse bewegen würden.