Betrieb & Hosting

Diese Seite richtet sich an IT-Teams, die SunStack mit einer Enterprise-Lizenz selbst betreiben — On-Premise oder in der eigenen Private Cloud. SaaS-Kunden können sie überspringen: Dort übernehmen wir all das.

Systemvoraussetzungen

Komponente	Empfehlung (bis ~100 Nutzer)
Anwendungs-Server	8–16 vCPU, 32–64 GB RAM, 500 GB SSD (Linux, Docker + Docker Compose)
Datenbank	PostgreSQL 16+, 4–8 vCPU, 16–32 GB RAM, SSD; separate Instanz empfohlen
DMZ-Host	kleiner separater Host/VM für öffentliche Apps (2–4 vCPU) — bewusst getrennt vom internen Netz
Netz	Ausgehender HTTPS-Zugriff (Tunnel, Integrationen); kein eingehender Port erforderlich
Storage	SharePoint/OneDrive-Anbindung für Dokumente; lokales Volume für Caches und Arbeitsdaten

Deployment-Modell

SunStack wird als Satz versionierter Container-Images ausgeliefert und per Docker Compose orchestriert:

# Beispielstruktur (vereinfacht)
sunstack/
├── docker-compose.yml        # Module + Services + Proxy
├── docker-compose.dmz.yml    # öffentliche Apps (separater Host)
├── .env                      # zentrale Konfiguration (aus .env.example)
└── volumes/                  # Persistenz: DB, Caches, Render-Ausgaben

Ein Modul = ein Container. Module lassen sich einzeln aktualisieren und neu starten, ohne die anderen zu berühren.
Reverse-Proxy (Traefik): Pfad-Routing pro Modul unter einem Origin (portal.ihre-domain.de/vertrieb, …/finanzen); interne Module zusätzlich hinter IP-Allowlist.
Fach-Services (Dokument-Extraktion, Banking, Ertragssimulation …) laufen als eigene Container und werden nur intern angesprochen.

DMZ einrichten

DMZ-Host aufsetzen: Die öffentlichen Apps (Kundenportal, Investorenportal, Academy, Angebotsannahme, Landing-Pages) laufen auf einem separaten Host mit dem DMZ-Compose-File — sie enthalten keine Datenbank-Verbindung und keine Geheimnisse außer dem Gateway-Schlüsselpaar.

Outbound-Tunnel verbinden: Öffentliche Erreichbarkeit entsteht über einen Outbound-only-Tunnel (z. B. Cloudflare Tunnel) — es wird kein Port am Firmennetz geöffnet. Subdomains je App (z. B. kunden.ihre-domain.de).

Gateway koppeln: DMZ-Apps sprechen ausschließlich das API-Gateway im internen Netz; die HMAC-Schlüssel werden beim Setup generiert und rotierbar hinterlegt.

⚠ Empfehlung vor öffentlichem Go-Live

Schalten Sie eine Web Application Firewall (z. B. auf Tunnel-Ebene) vor kundendaten-führende Portale, aktivieren Sie MFA für Administratoren und lassen Sie Impressum, Datenschutzerklärung und Consent-Banner der öffentlichen Seiten juristisch freigeben. SunStack liefert die technischen Einbaupunkte — die Inhalte verantwortet Ihr Unternehmen.

Backups & Wiederherstellung

Datenbank: tägliche Voll-Backups plus WAL-Archivierung für Point-in-Time-Recovery; Aufbewahrung nach Ihren GoBD-/Konzernvorgaben.
Dokumente: liegen in SharePoint/OneDrive und erben deren Versionierung und Papierkorb; zusätzliche Spiegelung auf eigene Systeme ist als Automation vorgesehen.
Konfiguration: .env und Compose-Dateien versioniert ablegen (ohne Secrets — dafür Secret-Store oder verschlüsselte Ablage).
Wiederherstellungs-Probe: quartalsweise Restore-Test auf eine Staging-Instanz — ein Backup, das nie zurückgespielt wurde, ist keins.

Updates

Releases erscheinen als getaggte Image-Sets mit Changelog und Migrations-Hinweisen; Datenbank-Migrationen laufen versioniert und vorwärts-kompatibel.
Empfohlener Ablauf: Staging aktualisieren → Smoke-Tests (mitgelieferte Checkliste) → Produktions-Update im Wartungsfenster; Module einzeln, Core zuletzt.
Der Wartungsvertrag (18–22 % p. a.) umfasst Feature-Releases, Sicherheits-Patches und Support bei Update-Problemen.

Monitoring des Systems selbst

Alle Container exponieren Health-Endpoints; eine mitgelieferte Vorlage bindet Prometheus/Grafana und Uptime-Checks an.
Der Automations-Heartbeat (stündlich) macht einen Stillstand der Automations-Engine sichtbar; ein externer Watchdog überwacht das Anlagen-Monitoring quer über Hosts.
Fehlgeschlagene Automations-Läufe, liegengebliebene Review-Fälle und Integrations-Ausfälle erscheinen in den jeweiligen Admin-Ansichten — und optional als Digest-Mail an die IT.

Feature-Flags & Shadow-Mode

Risikobehaftete Funktionen (Zahlungsläufe, Mahnwesen, automatischer Mail-Versand, Bank-Einreichungen) stehen hinter Feature-Flags — standardmäßig im Shadow-Mode: Der Lauf protokolliert, was er getan hätte.
Scharfschalten erfordert je nach Funktion zwei Flags und/oder Vier-Augen-Freigabe in der Anwendung.
Globaler und gesellschafts-spezifischer Kill-Switch stoppen im Zweifel alle geldbewegenden Automationen sofort.

Sicherheits-Checkliste (Kurzfassung)

Interne Module nur per VPN/IP-Allowlist erreichbar; DMZ strikt getrennt
MFA für alle Administratoren (über Entra ID Conditional Access)
Secrets im Secret-Store; PIN-/Credential-Vaults mit Master-Key außerhalb von Cloud-Sync
Datenbank nicht öffentlich erreichbar; Verbindungen TLS-verschlüsselt
Audit-Log-Aufbewahrung definiert; Zugriff auf Audit-Daten beschränkt
Restore-Tests und Access-Reviews terminiert (Modul IT & Compliance hilft)