Plattformarchitektur
Die gh0stcloud-Architektur auf hoher Ebene, ohne interne Implementierung als Käuferzusage zu formulieren.
gh0stcloud trennt Produktsteuerung, Tenant Intent und Runtime Reconciliation.
Das Portal zeigt und beantragt Tenant-Zustand. gh0stplane ist die Control-Plane-API. Runtime-Änderungen werden über Plattformautomation und GitOps reconciled, nicht über direkten Browserzugriff auf Infrastruktur.
Kernbereiche
| Bereich | Zweck |
|---|---|
| Portal | Öffentliche Website, Registrierung, Dashboard, Tenant Workflows, Billing und Request-Flächen. |
| Control Plane | Autoritative API für Tenant State, Policy Checks, Billing State, Status und Workflow-Entscheidungen. |
| GitOps | Versionierter gewünschter Anwendungszustand und plattformverwaltete Reconciliation. |
| Runtime | Tenant Workloads, Namespace Policy, Service Exposure, Data Services und Observability-Integration. |
Warum diese Form wichtig ist
Diese Architektur hält Verantwortungen klar:
- Nutzer brauchen keinen direkten Cluster-Admin-Zugriff;
- Tenant-Änderungen laufen durch Policy und Organization Scope;
- Git bleibt der Audit Trail für gewünschten Anwendungszustand;
- Plattformautomation besitzt Reconciliation und Guardrails;
- Portal-Seiten können Zustand zeigen, ohne Source of Truth zu werden.
Öffentliche Architekturgrenze
Diese Seite beschreibt Produktarchitektur. Interne Komponenten-Versionen, Repository-Pfade und generierte API-Details können sich ändern, ohne die kommerzielle Produktfläche zu verändern. Für Produktionsentscheidungen gelten Tenant-Zustand, Verträge und aktuelle Supportkommunikation.
Fragen oder bereit loszulegen?
Mit uns sprechen