Self-Hosting

Self-Hosting ist die richtige Wahl, wenn Sie Infrastruktur, Datenhaltung, Sicherheitsrichtlinien und Update-Prozesse selbst kontrollieren möchten.

Sie betreiben Workspace in Ihrer eigenen Umgebung und übernehmen Verantwortung für Betrieb, Backups, Monitoring, Updates und Rollback. Die eigentliche Installation erfolgt danach entweder über Linux-Pakete oder über Container.

Wann sollte ich Self-Hosting wählen?

Self-Hosting eignet sich besonders für:

• eigene Rechenzentren,
• private Cloud-Umgebungen,
• besondere Compliance-Anforderungen,
• Integration in bestehende Betriebsprozesse,
• zentrale Benutzer-, Netzwerk- und Geheimnisverwaltung.

Workspace Cloud eignet sich besser, wenn Sie keinen eigenen Plattformbetrieb aufbauen möchten. Weitere Informationen stehen unter Workspace Cloud.

Architektur

Workspace ist als zustandsarmer Server ausgelegt. Speichern Sie dauerhafte Daten außerhalb des Serverprozesses.

Sie benötigen

• Linux-Server oder Containerplattform,
• PostgreSQL,
• persistenten Speicher,
• TLS-fähigen Reverse Proxy oder direkten TLS-Betrieb,
• Backup- und Monitoring-Konzept.

Die Detailplanung umfasst:

Betriebsmodell wählen

Wählen Sie genau einen Installationsweg pro Workspace-Instanz:

Mischen Sie Linux-Paket und Containerbetrieb nicht innerhalb derselben Workspace-Instanz. Beide Wege verwenden dieselben fachlichen Betriebswerte, aber andere Laufzeit- und Storage-Mechanismen.

Betriebsrollen

In kleinen Organisationen kann eine Person mehrere Rollen übernehmen. Die Verantwortlichkeiten bleiben trotzdem getrennt.

Diese Werte sollten Sie dokumentieren

Planen und dokumentieren Sie diese Werte, bevor Sie den Setup-Assistenten starten:

Speichern Sie NUCLEUS_KEY, Datenbankpasswort, initiales Admin-Passwort und initialen API-Key in Ihrer Geheimnisverwaltung. Geben Sie diese Werte nicht in Tickets, Protokollen oder Screenshots weiter.

Ingress und TLS

Betreiben Sie Workspace hinter einem Ingress oder Reverse Proxy oder stellen Sie TLS direkt im Server bereit. Der Reverse Proxy ist in produktiven Umgebungen meist der einfachere Betriebsweg, weil er Zertifikate zentral verwaltet und öffentliche Header kontrolliert.

Direkter Ein-Server-Betrieb

Wenn Sie genau einen Workspace-Server direkt mit TLS betreiben, brauchen Sie keine Workspace-Cloud-Edge. Lassen Sie edge.domain_publication.mode auf self_hosted. Tragen Sie den Admin-Host in System Domains (CSV) ein und stellen Sie sicher, dass DNS und Zertifikat genau zu diesem Host passen.

Wenn derselbe Server auch eine öffentliche Site ausliefert, verwenden Sie für die Site einen eigenen Hostnamen und pflegen Sie ihn im Mandanten als Tenant Domain mit der Surface cms_public, zum Beispiel www.example.com neben app.example.com. Derselbe exakte FQDN kann nicht gleichzeitig Adminzugang und öffentliche Site sein.

Self-Hosting mit mehreren Nodes

Wenn Sie mehrere Workspace-App-Nodes betreiben, brauchen alle öffentlichen Hosts einen gemeinsamen Einstiegspunkt wie Reverse Proxy, Load Balancer oder Ingress. Dieser Einstiegspunkt verteilt Anfragen auf die App-Nodes und terminiert oder leitet TLS kontrolliert weiter.

Alle App-Nodes verwenden dieselbe Produktdatenbank, dieselbe verschlüsselte Konfiguration und denselben Wert für edge.domain_publication.mode. Verwenden Sie managed_cloud nur, wenn Sie die von schukai betriebene Edge-Control-Plane nutzen. Mit eigenem Einstiegspunkt bleibt der Modus self_hosted; der Betreiber verantwortet DNS, TLS, Routing und Health-Checks.

Weitere Details stehen unter TLS und Reverse Proxy.

System Domains

Tragen Sie die öffentliche Admin-Domain im Setup-Feld System Domains (CSV) als Hostnamen ein, ohne Protokoll, Pfad oder Port. Verwenden Sie also workspace.example statt https://workspace.example/.

Weitere Details stehen unter System Domains verstehen.

Erststart und Erstzugang

Beim ersten erfolgreichen Start legt Workspace den initialen System-Admin und einen initialen API-Key an. Der Server gibt diese Werte einmalig im Logblock SYSTEM INITIALIZED aus.

Sichern Sie direkt nach dem ersten Start:

• Login des initialen System-Admins,
• initiales Passwort, wenn es generiert wurde,
• initialen API-Key,
• NUCLEUS_KEY.

Wenn Sie das initiale Passwort vorher über NUCLEUS_ADMIN_PASSWORD setzen, gibt der Server das Passwort nicht erneut im Log aus. Der initiale API-Key wird beim ersten Anlegen trotzdem einmalig angezeigt.

Was muss gesichert werden?

Folgende Daten gehören in jedes Backup:

• PostgreSQL-Datenbank,
• verschlüsselte Konfigurationsdatei,
• NUCLEUS_KEY,
• Storage-Verzeichnis.

Wenn eines davon fehlt, ist eine Wiederherstellung möglicherweise nicht vollständig möglich.

Updates

Planen Sie Updates als kontrollierten Betriebsprozess:

• Release-Artefakte und Prüfsummen prüfen,
• Backup erstellen,
• Wartungsfenster festlegen,
• neue Version starten,
• Health-Checks und fachliche Smoke-Tests ausführen,
• Rollback-Pfad bereithalten.

Die vollständigen Update-Schritte stehen unter Updates und Rollback.

Self-Hosting erfolgreich eingerichtet

Prüfen Sie zum Abschluss:

• Workspace ist über die öffentliche Admin-Domain erreichbar,
• Anmeldung mit dem initialen Administrator funktioniert,
• PostgreSQL ist verbunden,
• Storage ist beschreibbar,
• TLS funktioniert,
• NUCLEUS_KEY und Erstzugangsdaten sind gesichert,
• Backup-Prozess ist dokumentiert,
• Update- und Rollback-Prozess sind geplant.

Nächste Schritte

• Installieren Sie Workspace per Linux-Paket mit Serverinstallation.
• Betreiben Sie Workspace im Container mit Container und Ingress.
• Richten Sie TLS und Reverse Proxy mit TLS und Reverse Proxy ein.
• Pflegen Sie öffentliche System-Domains mit System Domains verstehen.
• Planen Sie Updates und Rollback mit Updates und Rollback.