Stand jedes Teils

Der Status jedes Teils von PaaSbox Clusters, Stand 2026-10-11, mit den Belegen dafür. Das Angebot selbst ist In Arbeit: Es ist im Labor Ende-zu-Ende auf echten Hetzner-Servern gelaufen, in einem Wegwerf-Projekt bei Hetzner, mit dem Portal so, wie es in Produktion laufen würde, und es ist erst buchbar, wenn das Portal live ist.

Der Cluster und der Node

Teil	Status
Das Node-Image: Garden Linux mit k3s darin	Gebaut Es bootet auf Hetzner unter UEFI und bestand 20 von 20 Node-Prüfungen auf zwei Servertypen, cpx22 und cax11 (2026-09-27). Es trug die Laborcluster vom 2026-10-10, und ein Upgrade hat es an Ort und Stelle ersetzt, von Garden Linux 2150.6.0 auf 2150.11.0.
pbx-agent: Registrierung, signierte Anfragen, der Abgleich, die Operationen, seine eigenen Updates	Gebaut im Labor: Jede Operation dieser Tabelle lief auf echten Servern. Mitten in einer Operation abgeschossen, setzte er sie an dem Schritt fort, in dem er war; ein manipuliertes Release wurde abgelehnt; eine doppelt zugestellte Operation lief einmal; und er hat seine eigenen Schlüssel gewechselt und sich dreimal selbst aktualisiert. In Arbeit Ein Selbst-Update, das sich zurückrollt, hat noch nicht ausgelöst, ebenso wenig ein Update, das das Portal erzwingt.
Einen Cluster anlegen	Gebaut im Labor: 2 Minuten 46 Sekunden auf einem cpx22, 69 Sekunden davon für das Kopieren des Node-Images ins Projekt; die Firewall ließ genau 6443, 80, 443 und ICMP herein. Der Lauf startete das Anlegen über einen Verwaltungsbefehl; ein zweiter Laborlauf legte einen Cluster über die Anfragen des Formulars in 54 Sekunden an, das Node-Image schon im Projekt. In Arbeit Das Formular, in einem echten Browser benutzt.
Ein Cluster auf einem Server, den du schon hast	Gebaut im Labor: Ein Ubuntu-cpx22 wurde in 178 Sekunden zum Cluster und beim Löschen des Clusters zurückgegeben, weiter laufend.
Server mit arm64 (CAX)	In Arbeit Das Image bootet auf cax11; ein Cluster darauf ist noch nicht gelaufen.
Drei Server pro Cluster	Geplant später, mit eigenem Preis

Einen Cluster betreiben

Teil	Status
Befristete Kubeconfigs	Gebaut im Labor: eine view-Kubeconfig in 10,7 Sekunden und eine admin-Kubeconfig in 21 Sekunden, von der Anforderung bis zur Datei; abgewiesen binnen 11 Sekunden nach einem Widerruf. Eine view-Kubeconfig kann die Nodes nicht auflisten.
Snapshots in deinen eigenen S3-Bucket	Gebaut im Labor: Ein Snapshot war nach 25 Sekunden im Bucket. Für den Bucket stand ein selbst betriebener S3-Server. In Arbeit Hetzner Object Storage selbst, und Schlüssel, die du selbst hältst.
Ein Snapshot-Ziel, nach dem Anlegen hinzugefügt	Gebaut im Labor: pbx-agent schrieb das Secret des Buckets binnen 6 Sekunden, und der nächste Snapshot ging nach S3, ohne dass k3s neu startete.
Eine Wiederherstellung an Ort und Stelle	Gebaut im Labor: 160 Sekunden, mit unversehrten Daten in den Volumes.
Eine Wiederherstellung auf einen neuen Server	Geplant Keine Seite des Portals legt sie an.
Upgrades, mit einem Snapshot vorher	Gebaut im Labor: Ein Upgrade von Release 2026.10.0 auf 2026.10.1 dauerte 83 Sekunden, mit einem Snapshot vorher; die API war 34 Sekunden lang nicht erreichbar, während der Node neu startete. Ein Upgrade auf 2026.10.2, auf einem cpx32 in einem zweiten Laborlauf, dauerte 40 Sekunden, mit 24,7 Sekunden ohne API. In Arbeit Die automatische Rückkehr zum vorigen Image nach einem fehlgeschlagenen Start, und Upgrades und Neustarts, die auf das Wartungsfenster warten.
Die Schlüssel von pbx-agent und die des Buckets wechseln	Gebaut im Labor: neue Schlüssel von pbx-agent in 17 Sekunden; neue Schlüssel des Buckets, vorher am Bucket geprüft, in 8 Sekunden. Falsche Schlüssel wurden abgelehnt, und die alten blieben gültig.
Das Hetzner-Token des Projekts ersetzen, und das Token im Cluster	In Arbeit Code; auf keinem echten Cluster gelaufen.
Unter Settings ändern, wer die Kubernetes-API erreicht	In Arbeit Code: Speichern ändert die Firewall des Clusters sofort; auf keinem echten Cluster gelaufen. Die Firewall, die beim Anlegen entsteht, ist gelaufen.
Kuratierte Add-ons: Speicher, Ingress, Zertifikate, DNS-Einträge	Gebaut im Labor: lokaler Speicher und Traefik auf jedem Laborcluster; Hetzner-Volumes angeschaltet, mit einem gebundenen und eingehängten Volume; cert-manager mit einem Staging-Zertifikat von Let’s Encrypt über HTTP-01, an- und wieder abgeschaltet, die Zertifikate blieben. In Arbeit external-dns, und cert-manager über DNS-01.
Die Add-ons Flux und PaaSbox Platform	Gebaut im Labor, am 2026-10-10 und 11, mit einer Kopie von Image und Quelle der Plattform: Flux lief 71 Sekunden nach dem Speichern; die Plattform mit jedem Profil; upcheck als SaaSApplication bereit 82 Sekunden nach kubectl apply, über HTTPS mit einem Staging-Zertifikat von Let’s Encrypt ausgeliefert, seine Datenbank nach S3 gesichert und seine Daten unversehrt, nachdem seine Pods gelöscht wurden; ein Wildcard-Zertifikat über DNS-01 in 4 Minuten; Observability in 104 Sekunden; widersprüchliche und fehlende Add-ons von Portal und pbx-agent abgelehnt; Abschalten abgelehnt, solange eine Anwendung läuft; beide in einem Speichern abgeschaltet, in 70 Sekunden. In Arbeit Release 2026.10.2 ist nicht veröffentlicht: Controller-Image und Quelle der Plattform sind noch nicht öffentlich. Zertifikate aus dem Produktionsdienst von Let’s Encrypt, die Wiederherstellung einer Datenbank aus ihrem Backup und ein Update der Plattform auf eine neuere Version sind nicht gelaufen.
Add-ons für Monitoring und Logs	Geplant nach dem Start
Löschen	Gebaut im Labor: 14 Sekunden, und keine Ressource mit dem Label des Clusters blieb übrig, seine Hetzner-Volumes eingeschlossen. Im zweiten Laborlauf löschten die Seiten des Portals zwei Cluster in 19 und 20 Sekunden.
Abkoppeln und pbx-agent uninstall	In Arbeit
Die Anleitung für den Betrieb ohne das Portal	In Arbeit Geschrieben; ihre Schritte wurden noch nicht von Hand an einem Cluster durchgespielt.

Das Portal, Agenten und die Abrechnung

Teil	Status
Das Portal: deine Hetzner-Projekte, der Hub, der Provisioner, die Warteschlange der Operationen	Gebaut im Labor: Hub und Provisioner haben Cluster angelegt, gepflegt und gelöscht. Das Portal ist nicht live.
Die REST-API und die MCP-Tools für Agenten: API-Schlüssel mit Scopes, eingetippte Bestätigungen, Ratenlimits, das Audit-Log, Kubeconfigs versiegelt an den Schlüssel eines Agenten	In Arbeit Code mit Tests; nicht an einem echten Cluster gelaufen. Namen können sich noch ändern.
Die Abrechnung über Paddle als Merchant of Record	In Arbeit Code; nicht gegen Paddle gelaufen. Das Labor lief ohne Abrechnung.
Mails mit Warnungen an die Admins des Teams	In Arbeit Code; das Labor hat keine Mail verschickt.
Die Kopplung mit Cloud Viewer	In Arbeit Code auf beiden Seiten; noch nicht Ende-zu-Ende gelaufen.

„Gebaut“ heißt: Es lief Ende-zu-Ende auf echten Servern im Labor, hier in einem Wegwerf-Projekt bei Hetzner am 2026-10-10 und 11; veröffentlicht ist es nicht. „In Arbeit“ heißt: Der Code existiert und besteht seine Tests, ist aber noch nicht Ende-zu-Ende auf echten Servern gelaufen. „Geplant“ heißt: entworfen, nicht gebaut. Offen betrieben hat die Zahlen des Laufs.

Offen betriebenDie Laborläufe hinter diesen Ständen, Zeile für Zeile.

Was PaaSbox machtDer Ansatz, das Produkt und wo du anfängst.