Plattform · CloudManager
CloudManager ist die Betriebsplattform für die eigene Cloud: Server provisionieren, containerisierte Produkte an Kunden ausliefern und den Bestand sichern, überwachen und patchen. Alles aus einer Hand und auf eigener Infrastruktur. Gebaut für Betreiber, die vom Anbieter unabhängig bleiben und die Hoheit über ihre Daten behalten wollen, ohne ein DevOps-Team zu beschäftigen.
Seit März 2026 jeden Tag im Produktivbetrieb. Ein laufendes System, keine Ankündigung.
Was CloudManager macht
Ein Werkzeug für den ganzen Betrieb statt zehn einzelner.
Server bei Providern anlegen, bestehende Server per SSH aufnehmen oder neue physische Server ohne Bildschirm über das Netz installieren lassen.
Produkt-Katalog, Wizard inklusive KI-Generierung, Rollout mit Rückweg.
Sicherung über Restic auf zwei getrennte Ziele, mit geprobtem Restore.
Dashboard, durchsuchbare Logs, Alarme als Push aufs iPhone (Begleit-App PocketCM) und per E-Mail. Ein externer Push-Dienst bleibt nur Notausgang, falls die Plattform selbst ausfällt.
Host-OS-Patches, Schwachstellen-Scans der Images, Selbst-Update der Plattform. Wo es riskant wird, nur mit Freigabe.
Riskante Vorgänge bestätigt der Betreiber in der App PocketCM mit Face ID: Vorschläge der Plattform, Sicherungen, Container-Neustarts, Host-Patches und Neustarts, Plattform-Updates, Produkt-Rollouts, Umzüge von Anwendungen und SSH-Zertifikate. Die Freigabe ist an das Gerät gebunden.
Ein neuer physischer Server wird in der Oberfläche scharf geschaltet, startet per Netzwerk (offizieller Debian-13-Boot mit geprüfter Signaturkette, Secure Boot) und installiert sich ohne Bildschirm. Zur Wahl stehen Profile, etwa Debian, Ubuntu oder Proxmox VE 9; die Installationsdaten sind signiert.
Jeder Host bekommt im privaten Netz genau den Zugriff, den seine Rolle braucht. Neue Hosts werden automatisch in die Zugriffsregeln eingetragen; eine Wache vergleicht Soll und tatsächlichen Stand.
Standorte, Präfixe, Bereiche und Adressen mit gesperrter Vergabe, stündlicher Abgleich mit DHCP, Hosts und VPN. Neue Proxmox-VMs und Bare-Metal-Server beziehen ihre Adresse von dort und geben sie beim Abbau wieder frei.
Ein Regelwerk für Host-Firewalls und die Cloud-Firewalls der Anbieter: Bestand einlesen, Altregeln markieren, Vorschau „was würde sich ändern“, Übernahme erst nach Prüfung und Bestätigung, mit Aussperrschutz. Ein Vollautomat ist das nicht, und es ist noch im Ausbau.
Systemsicherungen laufen als Hintergrundlauf auf dem Agenten und überstehen einen Neustart der Verwaltung. Eine Liste zeigt, welcher Host keinen Sicherungsplan hat. Wöchentliche Wiederanlauf-Proben holen verpasste Läufe nach und melden sich, wenn keine gelingt. Geprobt wird nicht am laufenden System: Jede Probe startet eine frische virtuelle Maschine in einem abgeschotteten Netz, spielt eine echte Sicherung ein und baut sich danach wieder ab. Die Szenarien wechseln: System, Datenbank, Secret-Store, Quellcode-Server, Produkt.
Kleinkram erledigt die Plattform selbst: volle Platten aufräumen, hängende Container neu starten. Alles darüber hinaus kommt als Vorschlag mit Begründung und wird erst nach der Freigabe ausgeführt, auch per Face ID am iPhone.
Größere Plattform-Updates und solche mit neuer Datenbank-Migration brauchen eine Freigabe, auch vom iPhone; reine Patch-Releases spielen sich selbst ein. Der Fortschritt ist live abrufbar, die Cosign-Signatur wird vor dem Herunterladen geprüft, und wer den Antrag gestellt hat, kann ihn zurückziehen. Nach einem grünen Build lässt sich Staging automatisch ausrollen; Produktion bleibt freigabepflichtig.
SSH-Zugang über eine eigene CA mit Sperrliste und zweitem Faktor, CrowdSec als Standard auf den Hosts, eine interne Zertifizierungsstelle für interne Webdienste, die an alle Linux-Hosts verteilt wird.
Erfolgs- und Infomeldungen landen im Betriebslog statt im Alarmkanal; Checkmk-Probleme laufen als Alarme in die Plattform, inklusive Quittieren und Wartungsfenster.
Ein kleiner Router vor Ort bindet das Kleinnetz einer Außenstelle ans Mesh an, entweder über das Mesh-VPN oder über eine WireGuard-Verbindung zu einem Gateway-Host. Die Einrichtung läuft in der Oberfläche. Für Router der GL.iNet-Reihe lassen sich DHCP, DNS und LAN-Firewall zentral festlegen. Die Übertragung aufs Gerät ist gebaut, an einem echten Gerät aber noch nicht abgenommen; den Split-Tunnel überträgt sie noch nicht. Andere Router verwaltet die Plattform nicht.
Ein Umzug baut die Anwendung auf dem Ziel neu auf und überträgt nur die Daten, die sie wirklich nutzt. Umgezogen wird die Anwendung, die Festplatte wird nicht kopiert. Der Umzug läuft noch nicht über die Auftragswarteschlange, ein Neustart der Verwaltung bricht ihn ab.
Ein Sicherheitsvorfall wird als Vorgang geführt, mit den gesetzlichen Fristen ab Erkennung: 24 Stunden Frühwarnung, 72 Stunden Meldung, ein Monat Abschlussbericht.
Der Weg einer Bestellung
Die Plattform kann das Projekt ohne Zwischenschritt selbst provisionieren. Ob sie das tut oder ob eine Bestellung erst als offene Aufgabe wartet und von Hand freigegeben wird, ist eine Einstellung. Im eigenen Betrieb ist die Automatik eingeschaltet (Stand 02.10.2026).
1
Der Kunde öffnet den Katalog ohne Anmeldung. Sichtbar ist dort, was Sie ausdrücklich freigegeben haben.
2
Vier Schritte: Produkt → Plan → Name → Bestätigen.
3
Produkt, Plan, Ressourcen und Preis auf einen Blick. Danach legt die Plattform Server, Netz, Zertifikat und Container an, oder der Auftrag wartet auf Freigabe, je nachdem, wie Sie es einstellen.
4
Eigenes Portal, eigener Login. Die Instanz läuft bereits.
Auf Wunsch beginnt der Weg noch früher: Eine KI erzeugt aus einer Spezifikation einen deploybaren Compose-Stack. Die Funktion ist jung, aber echt: 6 produktive Läufe, zuletzt am 01.09.2026.
Was CloudManager unterscheidet
Jede Behauptung hier ist belegt: gemessen am laufenden Betrieb oder, wo es keine Zahl gibt, am Code benannt.
Ein Kunde bestellt im öffentlichen Katalog in vier Schritten, und die Plattform provisioniert das Projekt selbst: Server, Cloud-Init, Agent, Mesh-Beitritt, Deploy per Compose. Wo die Automatik eingeschaltet ist, braucht es kein Ticket und keinen Handgriff dazwischen.
Beleg6 abgeschlossene Provisionierungs-Jobs im September · 831 Rollouts seit Betriebsbeginn, 702 erfolgreich (im September 221 erfolgreich, 5 mit Fehler)
CloudManager sichert, stellt regelmäßig automatisch wieder her und misst, ob es klappt. Die Sicherungen werden auf ein zweites, unabhängiges Ziel repliziert.
Beleg529 erfolgreiche automatische Restore-Tests (6 fehlgeschlagen) · 1.239 erfolgreiche Replikationen (41 fehlgeschlagen). Gezählt wird jetzt im Backup-Katalog über den gesamten Betrieb seit Mai, nicht mehr in der Job-Historie.
Patch-Releases ohne neue Migration spielen sich automatisch ein. MINOR/MAJOR und neue Migrationen hält eine Risikobewertung an und verlangt eine bestätigte Freigabe, auch per Face ID am iPhone. Nach jedem Update laufen Gesundheitsprüfung und Rauchtests, bei Fehlschlag geht es automatisch zurück auf die alte Fassung.
Beleg342 getaggte Releases seit dem 03.09.2026. Wie viele davon über die Selbst-Update-Funktion eingespielt wurden, wird nicht gezählt. Die Zahlen zum KI-Gate auf der Startseite betreffen die Updates der Hosts, nicht dieses Selbst-Update.
Jeder Host trägt einen Agenten. Die Plattform spricht ihn nur über gegenseitige TLS-Zertifikate (mTLS) aus einer eigenen CA an, seine Rückmeldungen sind signiert. Alle Hosts hängen in einem privaten Mesh-VPN mit Zugriffsregeln, je Host nach Rolle als Profil gewählt. Das Sicherheitsmodell zieht mit, egal bei welchem Provider.
Beleg18 Knoten im Mesh, 17 online (im September waren es 29, seither wurden Doppelknoten bereinigt)
Provider und Dritt-Dienste sind Adapter hinter einheitlichen Schnittstellen. Server anlegen, DNS setzen, Zertifikate holen funktioniert überall gleich. Ein Anbieterwechsel ist eine Frage der Konfiguration, der Kern bleibt unverändert. Die Adapter unterscheiden sich in dem, was der jeweilige Anbieter kann, und das merkt man ihnen an.
Beleg12 registrierte Provider-Adapter, 11 davon einsatzfähig; produktiv im Einsatz Hetzner und Proxmox · 24 Integrations-Adapter in 14 Kategorien, 12 Integrationen im eigenen Betrieb aktiv
Jeder Verwaltungsvorgang steht im Prüfpfad, verkettet über eine HMAC-Kette. Eine nachträgliche Änderung fällt auf. Drei getrennte Auth-Schemata, Anmeldung mit Passwort und TOTP-Zweitfaktor, Credentials nur verschlüsselt in der Datenbank.
Beleg300.516 auditierte Vorgänge · 1.436 Scope-Prüfstellen im Routencode (bis auf eine sind alle Lese-Routen an Berechtigungen gebunden)
CloudManager führt Netze, Bereiche und Adressen selbst, statt sie in einer Tabelle neben dem Betrieb zu pflegen. Eine neue Proxmox-VM in einem verwalteten Netz bekommt ihre Adresse vor dem Klonen reserviert und gegen den Hypervisor geprüft; bei Fehlschlag oder Abbau wird sie wieder frei. Stündlich gleicht die Plattform den Bestand mit Proxmox (auch ausgeschaltete Maschinen), DHCP, Hosts, VPN, Firewall-ARP-Tabelle und Netz-Scan ab. Ist eine Quelle nicht lesbar, bleibt ihr Bestand unangetastet, statt still freigegeben zu werden.
BelegVergabe unter Sperre je Netz, Eindeutigkeit in der Datenbank erzwungen, Verlauf je Adresse. Eine Zahl zu den verwalteten Adressen steht hier bewusst noch nicht.
Ein neuer physischer Server wird in der Oberfläche scharf geschaltet, startet über das Netz und installiert sich ohne Bildschirm, mit Debian oder Ubuntu als Grundprofil (oder Proxmox VE 9). Die Installationsdaten sind signiert, bei Ubuntu mit Ed25519, bei Debian mit OpenPGP, und werden auf dem Gerät geprüft, bevor sie ausgeführt werden. Der Server kommt fertig eingebunden an: mit Adresse aus der Adressverwaltung, Agent, Mesh-Profil nach Rolle, CrowdSec und SSH-Zertifikaten. Für ein Rechenzentrum heißt das: Hardware ist ein Auftrag, kein Projekt.
BelegJe Betriebssystem ein eigener Signaturschlüssel, private Schlüssel im Secret-Store. Eine Zahl so aufgenommener Server steht hier bewusst noch nicht.
Was in der Oberfläche passiert, läuft über eine REST-API mit OpenAPI-Beschreibung, die größtenteils aus dem Code erzeugt und in der Pipeline geprüft wird. Zugriff gibt es über Token mit eng geschnittenen Rechten: API-Token mit Scopes für eigene Werkzeuge, projektgebundene Tenant-Token für Kunden. Neue Anbieter und Dienste kommen als Adapter mit Registry dazu, ohne Eingriff in den Kern. Eingehende Webhooks aus Git, CI und Zahlungsdienst werden per Signatur oder geheimem Token geprüft. Ausgehende, abonnierbare Webhooks für Kunden gibt es nicht.
Beleg1.629 Operationen auf 1.344 Pfaden · 1.436 Scope-Prüfstellen im Routencode · 12 Provider-, 24 Integrations-Adapter
Sicherheit
Nachvollziehbar bis in den einzelnen Vorgang.
auditierte Vorgänge in Produktion, HMAC-verkettet
Was auf einen Host kommt und was von ihm zurückkommt, ist geprüft. Jedes Glied nennt, wogegen es schützt.
Agent und Plattform sprechen nur mit Zertifikaten aus der eigenen CA. Widerrufene Zertifikate sperrt jeder Agent über eine Sperrliste. Das Zertifikat ist an die Rolle gebunden (Pinning): Das Zertifikat eines Hosts taugt nicht als Schlüssel für einen anderen.
Die Richtung Plattform zu Agent ist über gegenseitiges TLS, Pinning, Sperrliste und eine Positivliste erlaubter Befehle abgesichert. Eine Signatur je Befehl gibt es nicht; das steht hier, damit niemand sie voraussetzt.
Aufrufe vom Agenten an die Plattform tragen eine HMAC-Signatur mit Zeitstempel. Ein abgefangener Aufruf lässt sich nicht später wiederholen (Fenster: fünf Minuten).
Beim Plattform-Update wird die Cosign-Signatur der Images geprüft, bevor sie geladen werden. Ohne gültige Signatur bricht das Update ab. Fehlt der Prüfschlüssel, bricht es standardmäßig ebenfalls ab.
Der Agent installiert Updates und Erweiterungen nur mit gültiger Signatur und meldet ein Sicherheitsereignis, wenn sie fehlt. Er prüft außerdem sich selbst: Eine veränderte Agent-Datei fällt auf.
Jede Verwaltungsaktion steht im Prüfpfad, verkettet über eine HMAC-Kette. Ein Prüfdienst vergleicht die Kette; eine nachträgliche Änderung fällt auf.
Der technische Aufbau
Ein fester Kern orchestriert; alles Anbieter-Spezifische ist ein austauschbarer Adapter; auf jedem verwalteten Host führt ein schlanker Agent aus, was der Kern über mTLS anweist.
Core (fest): Express/TypeScript-API, drei Auth-Schemata (der OIDC-Login ist abgeschaltet), pg-boss-Job-Queue für alles Langlaufende, Provisionierungs-Orchestrierung, Headscale-Mesh-Verwaltung, PostgreSQL 16. Adapter (austauschbar): Provider- und Integrations-Adapter implementieren je ein einheitliches Interface und werden in einer Registry mit Credential-Entschlüsselung und Cache registriert. Ein neuer Anbieter ist ein neuer Adapter und kein Eingriff in den Kern.
Auf jedem Host läuft ein schlanker Agent, eine einzelne gebündelte Datei, die mit Node.js läuft. Die Plattform ruft ihn nur über mTLS mit Zertifikaten der eigenen CA an, und die Host-Firewall lässt diesen Zugang nur aus dem eigenen Mesh-Netz zu, von außen ist er geschlossen. Hosts, die eingehend nicht erreichbar sind, melden sich stattdessen selbst, mit Token und signierten Aufrufen. Deploys sind Agent + Docker Compose.
Gewünschte und tatsächliche Konfiguration liegen getrennt in der Datenbank. Abweichungen zwischen beidem werden gemeldet, mit der Zahl der verglichenen Ressourcen, damit „nichts gefunden“ nicht mit „nichts angesehen“ verwechselt wird. Live-Fortschritt läuft über Socket.IO in die Oberfläche.
OpenBao (Vault-kompatibel) als Secret-Store, mit In-Memory-Cache, Health-Poller und Dual-Write-Fallback, damit ein Secrets-Ausfall die Plattform nicht mitreißt. Feld-Verschlüsselung in der Datenbank: AES-256-GCM.
Produkt = Vorlage im Katalog. Projekt = laufende Instanz eines Produkts auf einem Host. Tenant = der Kunde, mit eigenem Login, eigener Oberfläche und eigener Token-Art. Betreiber- und Kunden-Oberfläche sind vollständig getrennt.
Betrieb in Zahlen
Auch die Fehlschläge stehen hier.
| Kennzahl | Stand |
|---|---|
| Verwaltete Hosts | 14, alle online |
| Knoten im Mesh-Netz | 18, davon 17 online |
| Produkte im Katalog | 13 |
| Automatisch geprobte Restores (erfolgreich) | 529 |
| Sicherungen im Katalog | 2.232, davon 2.175 erfolgreich (97,4 %) |
| Schwachstellen-Scans | 6.315 |
| Auditierte Vorgänge | 300.516 |
Alle Zahlen gemessen am 02.10.2026 gegen das Produktivsystem. Bezugsgröße geändert: Restore-Tests werden jetzt im Backup-Katalog über den gesamten Betrieb seit Mai gezählt (am 03.09.: 28 Proben in der Job-Historie).
Median 72 Sekunden über 28 erfolgreiche Wiederanlauf-Proben zwischen dem 10.06. und dem 30.09.2026; schnellste 23, langsamste 309 Sekunden. Je nach Fall: eine Systemwiederherstellung 44 Sekunden, eine Datenbank 159, der GitLab-Stack 218.
Von 44 Proben waren 28 erfolgreich, 15 fehlgeschlagen, 1 teilweise. Die Fehlschläge verteilen sich nicht gleichmäßig: Probe der Plattenverschlüsselung (LUKS) 6 von 12, Datenbank 4 von 10, OpenBao 2 von 5, Produkt 2 von 5, GitLab-Stack 1 von 5 (dazu eine teilweise). Die Systemwiederherstellung (5 Proben) und der Bau der Vorlage (2) liefen ohne Fehlschlag. Das ist der Grund, warum hier eine Quote und keine Zusicherung steht.
Zur Plattenverschlüsselung: Die Probe legt in der abgeschotteten Sandbox eine verschlüsselte Testplatte an und prüft, ob sie nach einem Neustart wieder entsperrt wird. Wer seine Platten verschlüsselt, will genau das vorher wissen.
Es gibt eine OpenAPI-Beschreibung mit 1.344 Pfaden und 1.629 Operationen. Sie wird auf Anfrage herausgegeben. Für die Frage, ob sich Ihre eigenen Werkzeuge anbinden lassen, reicht sie aus. Was sie kann und wie der Zugriff begrenzt wird, steht unter Punkt 09.
Zum Zustand: Sie wird inzwischen aus dem Code erzeugt und in der CI-Pipeline geprüft. Der Generator löst 151 von 170 Routendateien auf und erzeugt damit 1.370 der 1.629 Operationen; die 19 Dateien mit Sub-Routern löst er noch nicht auf, dort wird von Hand nachgepflegt. Am 03.09.2026 war die Beschreibung noch ausschließlich von Hand gepflegt und unvollständig.
Für wen
Ausblick
Was hier steht, gibt es noch nicht als Angebot. Termine nenne ich nicht, weil es keine belastbaren gibt.
Heute lassen sich ein OpenNebula-Frontend und ein KVM-Knoten über die Bare-Metal-Aufnahme installieren; das ist an Testmaschinen abgenommen. Geplant ist als spätere Stufe, OpenNebula auch als Provider anzubinden, also Server dort wie bei Hetzner oder Proxmox aus der Plattform anzulegen. Das ist vorgemerkt, nicht zugesagt.
Entschieden ist der Weg: Cluster API verwaltet den Lebenslauf, jeder Kunde bekommt eigene Control-Plane-Maschinen, zuerst auf Proxmox, danach bei Hetzner. Gebaut ist davon noch nichts; der Schritt davor ist ein Machbarkeitsversuch von Hand. Der Kubernetes läuft ausdrücklich nicht über OpenNebula.
Kontakt
Ich zeige Ihnen das laufende System. Statt einer Preisliste gibt es ein Gespräch.
Eine Preisliste gibt es nicht. Die Abrechnung ist in CloudManager noch nicht fertig: Mandanten, Tarife und Verbrauch stehen in der Datenbank, eine Rechnungsstellung daraus ist noch nicht gebaut. Im Gespräch zeige ich das echte Produktivsystem, keine Demo-Umgebung.