Zum Inhalt springen

FAQ

Kurze Antworten auf die Fragen, die Leute zu PaaSbox und PaaSbox Clusters stellen. Jede Antwort verweist auf die Seite mit den Einzelheiten.

Für DevOps mit Agenten auf kleinen, isolierten Kubernetes-Clustern. Jede Änderung, deine oder die eines Agenten, wird in einem Cluster getestet, der für den Test gebaut ist, und jede Stage jeder App läuft auf einem eigenen Cluster. PaaSbox Clusters ist die Software, die diese Cluster in deinem eigenen Hetzner-Projekt anlegt und aktuell hält. Siehe was PaaSbox macht.

Ein Cluster, der für einen Test gebaut ist, darf von diesem Test kaputt gemacht werden, ohne dass etwas anderes etwas davon merkt, und er beginnt jedes Mal im selben Zustand. Ein Agent kann darin frei installieren, upgraden, wiederherstellen und löschen, und danach löschst du den Cluster. Im Labor war ein Cluster 2 Minuten 46 Sekunden nach der Anfrage bereit und in 14 Sekunden gelöscht, seine Volumes eingeschlossen. Siehe warum isolierte Cluster für Agenten.

Ein kleiner Cluster pro Stage und pro App hält ein misslungenes Upgrade, einen kaputten Test oder eine laute App in diesem einen Cluster. Staging kann ein neues Release vor der Produktion bekommen, und eine Wiederherstellung trifft eine Stage einer App. Was du aufgibst, ist Hochverfügbarkeit: Jeder Cluster ist ein Server. Siehe das passende Setup.

Warum Kubernetes, wenn ein Cluster ein Server ist?

Abschnitt betitelt „Warum Kubernetes, wenn ein Cluster ein Server ist?“

Kubernetes beschreibt eine App mit ihrer Datenbank, ihren Zertifikaten und ihrer Konfiguration in Dateien, so entsteht dieselbe Umgebung jedes Mal auf dieselbe Weise, wird weggeworfen und neu angelegt. Das macht einen Cluster pro Test oder pro Stage billig zu wiederholen.

k3s betreibt die Control Plane von Kubernetes und deine Workloads auf demselben Server, mit wenig Platzbedarf; ein Server ist also ein vollständiger Cluster. Ein Server ist die kleinste nützliche Einheit und die, die ich zuerst gründlich testen kann. Cluster mit drei Servern kommen später, mit eigenem Preis; einen Preis für sie gibt es noch nicht.

Das Portal legt Server, Netze und Firewalls über die Hetzner-Cloud-API an, und das Node-Image ist für Hetzner Cloud gebaut und getestet. Dedizierte Server (Robot) und Cluster über mehrere Standorte gehören nicht zur ersten Version.

Noch nicht. Am 2026-10-10 ist es im Labor Ende-zu-Ende auf echten Hetzner-Servern gelaufen: Anlegen, Kubeconfigs, Snapshots und eine Wiederherstellung, Add-ons, ein Upgrade, Schlüsselwechsel, das Übernehmen eines Servers und das Löschen. Buchbar wird es, wenn das Portal live ist; das Formular zum Anlegen im Browser und die Abrechnung über Paddle sind noch in Arbeit. Sag mir, wenn es buchbar ist, dann schreibe ich dir einmal. Stand jedes Teils gibt jedem Teil seinen Status.

29 € pro Cluster und Monat inkl. MwSt., für einen Cluster mit einem Node; außerhalb der EU 29 US-$ zzgl. anfallender Steuern. Ein geplanter Preis. Paddle verkauft es als Merchant of Record und stellt die Rechnung. Abgerechnet wird ab dem Moment, in dem ein Cluster zum ersten Mal bereit ist, bis du ihn löschst oder abkoppelst. Hetzner rechnet den Server und den Rest deines Projekts direkt mit dir ab. Siehe Kosten und Abrechnung.

Neben einem Cluster, den dein Team behält, einen anteiligen Teil des Monatspreises, für die Zeit, die er bestand. In Arbeit Kommt ein Cluster hinzu, berechnet Paddle den Rest des Abrechnungszeitraums für ihn sofort; geht einer, schreibt es den Rest des Zeitraums gut. Der erste Cluster des Teams startet das Abonnement für einen ganzen Zeitraum, und geht der letzte Cluster deines Teams, läuft das Abonnement bis zum Ende des bezahlten Zeitraums und wird nicht gutgeschrieben: Ein Wegwerf-Cluster, der der einzige des Teams ist, kostet einen ganzen Monat. Hetzner rechnet den Server stundenweise ab, zu seinem eigenen Preis. Siehe Kosten und Abrechnung.

Ein Team kann 10 Cluster gleichzeitig halten, mehr auf Anfrage. Erreichst du die Grenze, sagt das Portal es dir: Lösch einen Cluster oder kopple einen ab, oder bitte um eine höhere Grenze. Gelöschte und abgekoppelte Cluster zählen nicht. Siehe Grenzen und Kontingente.

Nein. PaaSbox Clusters ist Software as a Service: Das Portal, pbx-agent auf dem Node, signierte Releases und die Add-ons legen deinen Cluster an und halten ihn aktuell. Server, Cluster und Verfügbarkeit gehören dir, und niemand beobachtet deine Workloads für dich. Siehe wer wofür einsteht.

Ja, wenn ein Node reicht und du drei Dinge akzeptierst: Es gibt kein SLA, ein Upgrade startet den Node neu (im Labor war die API 34 Sekunden lang nicht erreichbar), und auf einen kaputten Node antworten eine Wiederherstellung aus einem Snapshot oder ein Neuaufbau. Nicht-Produktion wie Dev, Staging, Test und CI passt ohne diese Einschränkungen. Siehe Produktion oder Nicht-Produktion.

Ja, kurz. Auf einem einzelnen Node startet jedes Upgrade den Server neu; die Kubernetes-API und deine Apps sind nicht erreichbar, solange er neu startet; im Laborlauf vom 2026-10-10 war die API 34 Sekunden lang nicht erreichbar. Jedes Upgrade macht zuerst einen Snapshot. Es läuft sofort, wenn du es so willst, oder in dem Wartungsfenster, das du wählst In Arbeit. Siehe einen Cluster upgraden.

Es sichert den Zustand des Clusters: jedes Kubernetes-Objekt, Secrets eingeschlossen, in Snapshots, die direkt in deinen S3-Bucket gehen, sobald du einen einrichtest; ohne Bucket bleiben sie auf der Platte des Servers und gehen mit ihr verloren. Die Daten in deinen Volumes sind nicht Teil eines Snapshots; sie sicherst du selbst. Siehe Backups einrichten und Snapshots machen und wiederherstellen.

Nein. Es gibt kein SLA. Der Cluster läuft auf einem Server in deinem eigenen Projekt: Fällt dieser Server aus, sind deine Apps weg, bis er wieder läuft oder wiederhergestellt ist. Ich stehe dafür ein, dass die Software sich wie dokumentiert verhält; der Cluster und seine Verfügbarkeit gehören dir. Siehe wer wofür einsteht.

Nicht von sich aus. Ohne weitere Add-ons ist es ein Cluster, keine Plattform darauf: Es deployt keine deiner Apps und beobachtet deine Workloads nicht. Zwei Add-ons ändern das, wenn du sie einschaltest: Flux, für Deployments aus deinem Git-Repository, und die PaaSbox Platform, die eine App mit ihrer Datenbank, ihrem Cache und ihrem Zertifikat aus einer SaaSApplication betreibt und Metriken, Logs, Traces, Alarme und Grafana in deinem Cluster dazunehmen kann. Beide sind am 2026-10-11 im Labor auf echten Hetzner-Servern gelaufen Gebaut; das Release, das sie mitbringt, ist noch nicht veröffentlicht In Arbeit. Siehe deine erste App deployen und Add-ons auswählen.

Ja, wenn es ein CPX- oder CCX-Server ist, oder ein CAX-Server (arm64, In Arbeit). Er behält seine ID, seine IP-Adressen und das, was Hetzner dir für ihn berechnet, und seine Platte wird gelöscht. CX-Server können das Node-Image nicht starten: Sie booten nur mit BIOS. Siehe welche Server passen.

In Arbeit Eine REST-API und MCP-Tools entstehen gerade. Ein Agent kann damit Cluster, ihren Zustand, Snapshots und Operationen lesen, einen Snapshot auslösen, ein Upgrade planen, Add-ons schalten und eine Kubeconfig holen, die für seinen eigenen Schlüssel versiegelt ist. Mit dem Scope dafür kann er auch Cluster anlegen, löschen, abkoppeln und wiederherstellen, jeweils nur mit dem Namen des Clusters als getippter Bestätigung. Siehe einem Agenten Zugriff geben.

Kann ein Agent meinen Produktionscluster löschen?

Abschnitt betitelt „Kann ein Agent meinen Produktionscluster löschen?“

Nur mit einem API-Schlüssel, der den Scope k3s:destructive trägt und von einem Team-Admin angelegt wurde, und nur, wenn der Aufruf den Cluster als Bestätigung genau beim Namen nennt. Ein Schlüssel gehört zu einem Team und gilt für jeden Cluster dieses Teams; auf einen einzelnen Cluster lässt er sich nicht einschränken. Einen Cluster anzulegen braucht denselben Scope, also hält ein Agent, der seine eigenen Wegwerf-Cluster anlegt, einen Schlüssel, der auch die anderen Cluster des Teams löschen könnte. Um so einen Schlüssel von der Produktion fernzuhalten, leg die Produktionscluster in ein Team, zu dem der Schlüssel nicht gehört. In Arbeit Siehe Leitplanken für Agenten.

Jeder Aufruf über die MCP-Tools wird festgehalten, und jeder Aufruf über die REST-API, der etwas ändert oder eine Kubeconfig herausgibt; bloße Lesezugriffe über REST nicht. Ein Eintrag hält die Person, den Schlüssel, die Aktion, den Cluster, die Argumente ohne Geheimnisse und wie es ausging, Ablehnungen eingeschlossen. Das Portal zeigt die Einträge auf API keys & agents, unter Recent activity und All activity. In Arbeit Siehe nachlesen, was er getan hat.

Nein. pbx-agent ist ein Programm, das systemd auf deinem Server ausführt. Es führt eine feste Liste von Operationen aus, etwa einen Snapshot, eine Wiederherstellung oder ein Upgrade, und hat keinen Kanal für beliebige Befehle. Siehe pbx-agent.

Es verwahrt dein Hetzner-Token, die k3s-Tokens, 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. Es verwahrt keine Admin-Kubeconfigs, nicht deine Snapshots und nicht die Daten deiner Workloads. Kubeconfigs aus dem Portal sind für deinen Browser verschlüsselt, und das Portal kann sie nicht lesen. Das Sicherheitsmodell sagt auch offen, was ein kompromittiertes Portal tun könnte.

Nicht direkt. pbx-agent meldet dem Portal den Zustand von Node und Cluster, die Snapshots und den Stand der Add-ons, nicht deine Objekte. Aber Server-Token und S3-Schlüssel zusammen könnten einen Snapshot öffnen, und der enthält jedes Secret. Hältst du die Schlüssel des Buckets selbst, kann das Portal deine Snapshots nicht lesen In Arbeit. Siehe wer die Schlüssel des Buckets hält.

Ja, es ist dein Server. Von außen ist SSH zunächst zu: Die Firewall hält Port 22 geschlossen, und das Portal hinterlegt keinen Schlüssel. Root über die Web-Konsole von Hetzner geht nicht, weil das Image kein Root-Passwort setzt. Deinen Schlüssel trägst du mit kubectl debug auf dem Node selbst ein und öffnest den Port. Siehe Root auf dem Server bekommen.

Dein Cluster läuft weiter. pbx-agent hat immer nur nach außen gerufen, du hast root auf dem Server, das Server-Token liegt auf seiner Platte, und die Snapshots liegen in deinem Bucket. Der DNS-Name der API in der Zone von PaaSbox wäre weg. Ohne PaaSbox weiterbetreiben hat die Schritte.

Jederzeit. Kopple ab, und der Cluster läuft ohne das Portal weiter; oder lösch ihn, dann verschwindet jede Ressource, die das Portal angelegt hat, und der Inhalt deines Buckets bleibt. Eine unbezahlte Rechnung löscht nie einen Cluster. Siehe einen Cluster abkoppeln oder löschen.

PaaSbox Clusters ist Software as a Service, und sein Portal ist geschlossen. Die Lizenz von pbx-agent ist noch nicht entschieden; seine Quelldateien tragen den Apache-2.0-Header. Die Bausteine darunter sind offene Komponenten, deren Veröffentlichung vorbereitet wird; die Node-Images sind schon veröffentlicht. Siehe die offenen Komponenten.

PaaSbox bietet keine Gardener-Cluster an. Die Gardener-Erweiterungen für Hetzner und das paasbox-CLI, das eine Landschaft aufbaut, sind offene Komponenten, deren Veröffentlichung vorbereitet wird, und ein Kurs zeigt, wie du eine Landschaft selbst betreibst: die nächste Stufe, wenn viele Cluster einen gemeinsamen Steuerpunkt brauchen. Siehe Gardener auf Hetzner.

Support sagt, wie du mich erreichst, und die Fehlerbehebung sagt, was ein Zustand eines Clusters bedeutet und was zu tun ist, wenn etwas fehlschlägt.