Das passende Setup

Bevor du einen Cluster anlegst, den du behalten willst, stehen vier Entscheidungen an: wie viele Cluster du brauchst, auf welchem Server jeder läuft, ob ein Cluster Produktion tragen darf, und welche Add-ons er bekommt. Diese Seite gibt die Fakten dazu. Einen Cluster anlegen hat die Schritte.

Ein Cluster oder mehrere

PaaSbox ist für dieses Setup gebaut: ein kleiner Cluster pro Stage und pro App, dazu ein Wegwerf-Cluster für jeden Test.

Du betreibst	Cluster
Eine App, nur Produktion	1
Eine App, mit Staging und Produktion	2
Zwei Apps, jede mit Staging und Produktion	4
Tests für Pull Requests	einer mehr für jeden Test, danach gelöscht

Getrennte Cluster halten einen Fehler klein. Ein Upgrade, eine Wiederherstellung oder ein entgleister Test trifft eine Stage einer App. Staging kann jedes neue Release zuerst bekommen, auf dem Kanal early, während die Produktion auf stable in ihrem eigenen Wartungsfenster wartet. Jeder Cluster hat seine eigenen Kubeconfigs und seine eigenen API-Bereiche, Zugriff auf Staging gibt also keinen Zugriff auf die Produktion.

Jeder Cluster kostet den Preis einmal, 29 € inkl. MwSt. im Monat, dazu seinen Server bei Hetzner. Ein Wegwerf-Cluster neben einem Cluster, den du behältst, zählt nur, solange es ihn gibt: Paddle berechnet ihn anteilig, sobald er zum ersten Mal bereit ist, und schreibt den Rest gut, wenn du ihn löschst In Arbeit. Der einzige Cluster eines Teams kostet dagegen einen vollen Monat, auch wenn du ihn nach Minuten löschst; der erste Cluster eines Teams sollte also einer sein, den du behalten kannst. Ein Team kann 10 Cluster gleichzeitig haben; Cluster, die gerade gelöscht werden, gelöschte und abgekoppelte zählen nicht. Das Formular zum Anlegen sagt, wenn das Team sie erreicht hat, und mehr gibt es auf Anfrage.

Cluster können sich ein Hetzner-Projekt teilen, und das Node-Image wird in jedes Projekt nur einmal kopiert. Gib der Produktion trotzdem ein eigenes Projekt. Der Cloud Controller und der Volume-Treiber in jedem Cluster benutzen ein Hetzner-Token, und ein Hetzner-Token öffnet sein ganzes Projekt: Wer dieses Token in einem Testcluster lesen kann, könnte die Server der Produktion ändern, wenn beide in einem Projekt liegen.

Welcher Server

Das Portal bietet drei von Hetzners Serverlinien an:

• CPX (geteilte vCPU) und CCX (dedizierte vCPU), beide amd64.
• CAX, arm64. In Arbeit Das Node-Image bootet auf einem cax11; ein Cluster darauf ist noch nicht gelaufen.

Die Linie CX wird nicht angeboten: Sie bootet nur mit BIOS, und das Node-Image braucht UEFI. Innerhalb der drei Linien listet das Formular, was Hetzner am gewählten Standort verkauft, mit Hetzners monatlichem Listenpreis. Hetzner berechnet ihn dir; das Portal schlägt nichts auf.

Der Speicher entscheidet über die Größe. Gemessen im Labor auf einem cpx22 mit 4 GB: Ein frischer Cluster belegte 1,2 GiB der 3,8 GiB, die der Server hat; Hetzner-Volumes kamen mit 82 MiB dazu und cert-manager mit 64 MiB. Gemessen im Plattform-Labor am 2026-10-11: Flux 138 bis 189 MiB, während die Plattform eingerichtet wird, die PaaSbox Platform 96 MiB (minimal) bis 164 MiB (saas-http01), mit ihrer Observability (Metriken, Logs, Traces, Grafana) 826 bis 868 MiB, und upcheck, eine kleine Web-App mit Postgres, einem Cache und einem Worker, 559 bis 606 MiB. Ein cpx22 mit Flux und saas-http01 ohne App hatte 1,4 GiB frei; der k3s-Server-Prozess allein belegte 1,0 GiB. Das Portal plant mit höheren Zahlen: 170 MiB für Flux, 150 bis 330 MiB für die Plattform, bis zu 1,2 GiB mit Observability.

• 4 GB (ein cpx22) tragen den Cluster, Flux, die PaaSbox Platform ohne Observability und eine kleine App.
• 8 GB oder mehr, wenn du die Observability der Plattform willst. Das Portal bietet ein Add-on, oder eine seiner Optionen, nur auf einem Server mit genug Speicher an: Im Labor lehnte die Seite zum Anlegen einen cpx22 für saas-http01 mit Observability ab und bot einen cpx32 an.

Den Servertyp eines bestehenden Clusters zu ändern ist Geplant. Wähle einen Typ mit Luft, oder leg einen neuen Cluster an und zieh die App um. Ein Server, den du schon hast, behält seine ID, seine Adressen und seinen Preis; seine Platte wird gelöscht.

Produktion oder Nicht-Produktion

PaaSbox Clusters ist für beides. Produktion auf einem einzelnen Node heißt drei Dinge, und die akzeptierst du, bevor du Produktion darauf legst:

• Es gibt kein SLA. Fällt der Server aus, sind deine Apps weg, bis er wieder läuft oder wiederhergestellt ist.
• Jedes Upgrade startet den Node neu. Im Labor war die Kubernetes-API 34 Sekunden lang nicht erreichbar, und deine Apps sind weg, solange der Node neu startet. Upgrades laufen sofort, wenn du es willst, oder in deinem Wartungsfenster In Arbeit.
• Die Antwort auf einen kaputten Node ist eine Wiederherstellung oder ein Neuaufbau: ein Snapshot, an Ort und Stelle wiederhergestellt, oder ein neuer Cluster mit deinen Apps neu deployt. Eine Wiederherstellung auf einen neuen Server ist Geplant.

Zwei Dinge liegen dann bei dir. Schick die Snapshots in einen S3-Bucket: Ohne Bucket bleiben sie auf der Platte des Servers und gehen mit ihm verloren. Und sichere die Daten deiner Apps: Ein Snapshot enthält den Zustand des Clusters, nicht den Inhalt deiner Volumes; eine Datenbank braucht eigene Backups, die die PaaSbox Platform für Postgres einrichtet: Im Labor kamen ihr Write-Ahead-Log und ein Basis-Backup in S3 an; eine Wiederherstellung daraus ist noch nicht gelaufen In Arbeit.

Muss eine App den Ausfall eines Servers überstehen, braucht sie mehr als einen Server, und PaaSbox Clusters passt heute nicht dafür. Cluster mit drei Servern sind Geplant, später und mit eigenem Preis.

Staging, Tests, Previews und Labore sind Nicht-Produktion: Alles oben gilt, nur steht weniger auf dem Spiel.

Welche Add-ons

Ein Cluster startet mit dem, was er zum Laufen braucht; den Rest schaltest du an. Ändern kannst du das später auf dem Reiter Add-ons des Clusters.

Add-on	Voreinstellung	Schalte es an für	Status
Hetzner Cloud Controller	immer an	— (verbindet den Cluster mit deinem Projekt)	Gebaut
Lokaler Speicher, Klasse local-lvm-thin	immer an	Volumes auf der eigenen Platte des Servers; sie gehen mit dem Server	Gebaut
Traefik-Ingress	an	HTTP und HTTPS auf den Ports 80 und 443 des Servers	Gebaut
Hetzner-Volumes, Klasse hcloud-volumes	aus	Volumes, die nicht von der Platte des Servers abgehen; Hetzner berechnet sie, und das Löschen des Clusters löscht sie	Gebaut
cert-manager	aus	Zertifikate von Let’s Encrypt für deine Ingresses	Gebaut über HTTP-01; DNS-01 In Arbeit
external-dns	aus	DNS-Einträge in deinen Hetzner-DNS-Zonen	In Arbeit
Flux	aus	deine Apps aus einem Git-Repository deployen	Gebaut im Labor; noch nicht veröffentlicht In Arbeit
PaaSbox Platform	aus	Apps als SaaSApplication, mit Postgres, Zertifikaten und, wenn du willst, Observability; sie braucht Flux und bringt ihren eigenen cert-manager mit	Gebaut im Labor; noch nicht veröffentlicht In Arbeit
Monitoring, Logs	—	—	Geplant

Add-ons auswählen hat die Schritte und was mit ihren Daten passiert; der Add-on-Katalog hat jede Option und Version.

Für Hilfe beim Setup, oder bei einer eigenen Plattform: Rückruf vereinbaren.

Deinen ersten Cluster anlegenLernschritt 1: diese Entscheidungen für einen Cluster getroffen, den du für den Rest des Pfads behältst.

Warum isolierte Cluster für AgentenEin Cluster pro Test, pro Stage und pro App: was er bringt und was er kostet.