So funktioniert es

PaaSbox Clusters ist Software, die kleine k3s-Cluster in deinem eigenen Hetzner-Projekt anlegt und aktuell hält. Drei Teile erledigen die Arbeit: das PaaSbox-Portal, ein kleines Programm namens pbx-agent auf dem Server jedes Clusters, und dein Hetzner-Projekt mit deinem S3-Bucket. Diese Seite erklärt, wie sie zusammenarbeiten, und warum der Cluster dabei deiner bleibt.

In Arbeit: noch nicht buchbar (Stand: 2026-10-10)

Was diese Seite beschreibt, ist am 2026-10-10 Ende-zu-Ende auf echten Hetzner-Servern gelaufen, im Labor: in einem Wegwerf-Projekt bei Hetzner, mit dem Portal so, wie es in Produktion laufen würde. Wo ein Teil noch nicht gelaufen ist, sagt es sein Status. Es ist nicht veröffentlicht und erst buchbar, wenn das Portal live ist. Stand jedes Teils listet, was gelaufen ist und was nicht. Sag mir, wenn es buchbar ist.

Die drei Teile

Das Portal ist die Webanwendung von PaaSbox. Sein Provisioner verwahrt dein Hetzner-API-Token und ist der einzige Teil, der es benutzt: Er legt Server, privates Netz, Firewall und IP-Adresse des Clusters in deinem Projekt an, dazu den DNS-Namen der Kubernetes-API, und löscht sie wieder. Sein Hub antwortet pbx-agent. Auf seinen Seiten bittest du um einen Cluster, einen Snapshot, ein Upgrade oder eine Kubeconfig; In Arbeit eine REST-API und MCP-Tools geben deinen Agenten dieselben Anfragen.

pbx-agent ist ein Programm auf dem Server, gestartet von systemd. Es ist kein KI-Modell. Etwa alle 30 Sekunden ruft es das Portal über HTTPS an, meldet den Zustand des Nodes und bekommt zwei Dinge: wie der Cluster aussehen soll, und höchstens eine Operation. Es lauscht auf keinem Port, und das Portal verbindet sich nie mit dem Server. Die Operationen sind eine feste Liste: einen Snapshot machen, einen wiederherstellen, upgraden, eine Kubeconfig ausstellen oder widerrufen, den Bucket prüfen, die eigenen Schlüssel wechseln, und Diagnosedaten sammeln, nachdem du es erlaubt hast. Einen Kanal für beliebige Befehle gibt es nicht.

Dein Hetzner-Projekt und dein Bucket halten alles, was läuft. Auf dem Server läuft Garden Linux, mit k3s im Image. Snapshots vom Zustand des Clusters gehen vom Server direkt in einen S3-Bucket, der dir gehört; über das Portal laufen sie nie. Den Server rechnet Hetzner direkt mit dir ab, wie alles andere in deinem Projekt.

Wie ein Cluster entsteht

Wenn du einen Cluster anlegst, arbeitet das Portal diese Schritte ab und zeigt jeden auf der Seite des Clusters:

1. Es prüft das Token und kopiert das Node-Image in dein Projekt. Hetzner hält ein Image immer nur in einem Projekt, darum wartet der erste Cluster eines Projekts darauf; spätere Cluster nehmen die Kopie.
2. Es legt das private Netz, die Firewall, die IP-Adresse und den DNS-Namen an, dann den Server.
3. Die User-Data des Servers enthalten kein dauerhaftes Geheimnis: nur, woher pbx-agent geladen wird, mit Prüfsumme, die Adresse des Portals und ein Registrierungs-Token, das einmal gilt und nach 30 Minuten verfällt.
4. pbx-agent erzeugt seine eigenen Schlüssel und registriert sich mit dem Token, und das Portal prüft, dass der Server genau das Image des Releases gebootet hat. pbx-agent bekommt seine Konfiguration, startet k3s und meldet, sobald die Kubernetes-API antwortet. Dann ist der Cluster bereit.

Im Laborlauf vom 2026-10-10 dauerte das auf einem cpx22 2 Minuten 46 Sekunden, 69 Sekunden davon das Kopieren des Images. Einen Cluster anlegen geht jedes Feld des Formulars durch.

Wie ein Cluster aktuell bleibt

Das Portal hält fest, wie jeder Cluster aussehen soll: sein Release, seine Add-ons, Zeitplan und Ziel seiner Snapshots, sein Wartungsfenster. pbx-agent bringt den Server in diesen Zustand und meldet, wenn er dort ist. Daraus folgen drei Dinge:

• Upgrades ersetzen das ganze Image. Das Root-Dateisystem des Nodes ist schreibgeschützt. Ein Upgrade macht darum einen Snapshot, schreibt das Image des neuen Releases neben das laufende, startet in das neue und prüft, ob der Node gesund ist. Die Daten auf der Platte des Servers bleiben. Jedes Upgrade startet den Node neu: Im Labor war die Kubernetes-API 34 Sekunden lang nicht erreichbar. Upgrades laufen sofort, wenn du es willst, oder in deinem Wartungsfenster In Arbeit. Einen Cluster upgraden.
• Releases sind signiert. Ein Release nennt das Image, die k3s-Version und die Add-ons und ist mit einem Schlüssel signiert, der offline liegt. pbx-agent lehnt ein Release ab, dessen Signatur nicht stimmt, und ändert dann nichts; im Labor hat er eine manipulierte Kopie abgelehnt. Releases und Kanäle.
• Verwaltete Objekte werden überschrieben. Die Add-ons, die das Portal installiert, werden alle 10 Minuten neu angewendet, eine Änderung von Hand an ihnen verschwindet also wieder. Was du selbst deployst, wird nie angefasst. Add-ons auswählen.

Ist das Portal nicht erreichbar, bleibt nichts stehen: Der Cluster läuft weiter, und k3s macht weiter seine geplanten Snapshots. Wird pbx-agent mitten in einer Operation angehalten, setzt er sie an dem Schritt fort, in dem er war; im Labor hat ein abgeschossener Agent genau das getan.

Kubeconfigs, die das Portal nicht lesen kann

Wenn du eine Kubeconfig anforderst, erzeugt dein Browser ein Schlüsselpaar für genau diese Anfrage. pbx-agent stellt eine Kubeconfig mit einem Token aus, das verfällt, verschlüsselt sie für den Schlüssel deines Browsers, und das Portal reicht sie einmal weiter; nach der Übergabe oder nach 5 Minuten löscht es sie. Öffnen kann das Portal sie nicht. In Arbeit Ein Agent fragt über die API genauso, mit einem eigenen Schlüsselpaar. Eine Kubeconfig holen.

Was das Portal verwahrt

Das Portal verwahrt dein Hetzner-Token, die k3s-Tokens für Server und Agent (die eigenen Tokens von k3s, nicht die Schlüssel von pbx-agent), das Hetzner-Token, das im Cluster benutzt wird, die DNS-Tokens der Add-ons, die eines brauchen, und die S3-Schlüssel deines Snapshot-Buckets, wenn du sie nicht selbst hältst. Alles verschlüsselt, und die Geheimnisse, die es an pbx-agent schickt, sind so versiegelt, dass nur der pbx-agent dieses Clusters sie öffnen kann. Es verwahrt keine Admin-Kubeconfigs, nicht die privaten Schlüssel von pbx-agent, nicht deine Snapshots und nicht die Daten deiner Workloads.

Server-Token und S3-Schlüssel zusammen könnten einen Snapshot öffnen, und ein Snapshot enthält jedes Secret des Clusters. Hältst du die Schlüssel des Buckets selbst, kann das Portal deine Snapshots nicht lesen. Sicherheitsmodell sagt, was eine geleakte Datenbank oder ein kompromittiertes Portal könnten und was nicht.

Wer wofür einsteht

PaaSbox Clusters ist Software, die du nutzt, kein Betriebsdienst: Niemand beobachtet deinen Cluster für dich.

Ich stehe ein für	Dir gehört
Portal und pbx-agent verhalten sich wie dokumentiert	Der Server, der Cluster, seine Verfügbarkeit und deine Workloads
Ein Release ist getestet, bevor es deinen Cluster erreicht	Die Daten in deinen Volumes
Operationen sind standardmäßig sicher und melden ihr echtes Ergebnis	Der S3-Bucket für die Snapshots, seine Schlüssel und seine Lifecycle-Regeln
Die sichere Verwahrung deines Hetzner-Tokens, der S3-Schlüssel (wenn das Portal sie hält) und des Server-Tokens des Clusters	Die Hetzner-Rechnung
	Alles, was du auf dem Server von Hand änderst

Es gibt kein SLA. Der Cluster läuft auf einem Server in deinem Projekt: Fällt dieser Server aus, sind deine Apps weg, bis er wieder läuft, aus einem Snapshot wiederhergestellt oder als neuer Cluster neu aufgebaut ist.

Wenn es PaaSbox nicht mehr gibt

Dein Cluster läuft weiter. pbx-agent hat immer nur nach außen gerufen, auf dem Server wartet also nichts auf das Portal. Du hast root auf dem Server: Die Wege hinein sind kubectl debug auf dem Node, um einen SSH-Schlüssel hinzuzufügen, SSH, sobald ein Schlüssel da ist, und das Rescue-System von Hetzner (Root auf dem Server bekommen). Das k3s-Server-Token liegt auf der Platte des Servers, und die Snapshots liegen in deinem Bucket. Wegfallen würde der DNS-Name der Kubernetes-API, der in der Zone von PaaSbox liegt.

Du kannst auch jederzeit absichtlich gehen. In Arbeit Detach (Abkoppeln) beendet die Verwaltung durch das Portal und die Abrechnung, und der Cluster läuft weiter; sein DNS-Name bleibt 30 Tage. Delete (Löschen) entfernt alles, was das Portal für den Cluster angelegt hat; der Inhalt deines Buckets bleibt. Einen Cluster abkoppeln oder löschen und Ohne PaaSbox weiterbetreiben haben die Schritte.

Deinen ersten Cluster anlegenDer erste Schritt des Lernpfads: ein Cluster, den du behältst, und jedes seiner Teile wiedergefunden.

SicherheitsmodellWas das Portal verwahrt, und was eine geleakte Datenbank oder ein kompromittiertes Portal tun könnten.