Releases und Kanäle

Ein Release ist die Einheit, in der PaaSbox Clusters einen Cluster verändert: das Node-Image mit seinem k3s, die Version von pbx-agent und die Add-ons, zusammen getestet und signiert. Diese Seite sagt, wie ein Release entsteht, signiert und freigegeben wird, wie ein Cluster von einem zum nächsten kommt und was jedes Release enthält.

Status

Das Format der Releases, seine Signatur und die Prüfungen von pbx-agent sind Gebaut im Labor: Am 2026-10-10 wurden die Releases 2026.10.0 und 2026.10.1 mit einem Laborschlüssel signiert und ins Portal importiert, und ein Cluster wurde auf einem echten Hetzner-Server vom ersten auf das zweite gebracht; eine manipulierte Kopie wurde abgelehnt. Am 2026-10-10 und 11 tat ein zweiter Laborlauf dasselbe mit 2026.10.2, dessen Plattform auf eine Kopie von Image und Quelle der Plattform zeigte. In Arbeit Kein Release ist bisher mit dem Release-Schlüssel signiert oder veröffentlicht, und keines hat die ganze Freigabe unten durchlaufen.

Was ein Release ist

Teil	Was es ist
Node-Image	Garden Linux mit einem festgelegten k3s darin, für amd64 und arm64. Sein Root-Dateisystem ist nur lesbar; ein Upgrade ersetzt das ganze Image.
pbx-agent	Der älteste pbx-agent, der das Release anwenden kann (minAgent), und sein Download für jede Architektur mit seiner Prüfsumme.
Add-ons	Jedes mit festgelegter Chart-Version, seiner Vorlage, dem Schema seiner Optionen, seinen Speicherwerten, was es braucht und womit es sich nicht verträgt.
Erreichbar von	Die Releases, von denen aus es getestet wurde (upgradesFrom).
Plattform	Ab 2026.10.2: das Controller-Image der PaaSbox Platform und die Quelle, aus der ihre Teile installiert werden, in einer Version.

Ein Cluster wechselt immer nur von einem Release zu einem anderen. Nichts auf einem Cluster folgt von selbst einem Kanal von upstream: Ein neues k3s erreicht deinen Cluster nur innerhalb eines Releases. Releases heißen nach Datum und Nummer: 2026.10.0, 2026.10.1 und so weiter.

Signatur

Was	Wie
Der Schlüssel	Ein Ed25519-Schlüssel, den ich offline verwahre: nie auf dem Portal, nie in der CI, nie auf der Maschine, die das Manifest baut. pbx-release keygen erzeugt ihn.
Die Signatur	pbx-release sign über die Bytes des Manifests, genau wie gespeichert; pbx-release verify prüft sie.
pbx-agent	Trägt zwei öffentliche Schlüssel fest eingebaut, den aktuellen und den nächsten. Er lehnt ein Manifest ab, das keiner von beiden signiert hat (manifest_rejected), und ändert nichts. Zur Laufzeit kann nichts ändern, welchem Schlüssel er vertraut.
Das Portal	Hält dieselben beiden öffentlichen Schlüssel und lehnt es ab, ein Manifest zu importieren, das sie nicht bestätigen.
Den Schlüssel ersetzen	Der nächste Schlüssel steckt schon in jedem pbx-agent, also lässt sich der Schlüssel ohne Lücke ersetzen.

Von einem Release zum nächsten

Regel	Wo sie durchgesetzt wird
Das Portal bietet einem Cluster ein Release nur an, wenn dieses Release das aktuelle des Clusters in upgradesFrom nennt.	Die Warteschlange des Portals
Patch-Releases, auf derselben k3s-Minor-Version, werden von selbst für dein Wartungsfenster eingeplant, außer du schaltest das für den Cluster ab. In Arbeit Upgrades, die auf das Fenster warten, sind auf keinem echten Cluster gelaufen.	Das Portal, jede Stunde
Eine neue k3s-Minor-Version wartet auf deinen Klick.	Das Portal
Über alle Cluster hinweg laufen höchstens fünf Upgrades gleichzeitig.	Die Warteschlange des Portals
Schlagen zwei der ersten fünf Upgrades auf ein Release fehl, hält das Portal dieses Release an und schreibt mir eine Mail. Ein angehaltenes Release wird niemandem angeboten.	Das Portal
Ein Release lässt sich in jeder Phase zurückziehen. Seine Kanäle fallen auf das neueste Release zurück, das noch auf ihrer Stufe ist. Cluster, die es schon fahren, bleiben, wo sie sind.	Das Portal

Wie ein Upgrade auf einem Node abläuft, steht unter Einen Cluster upgraden.

Freigabe und Kanäle

Stufe	Was passiert	Wie lange
Kandidat	Image, pbx-agent und Manifest werden gebaut, das Manifest offline signiert und importiert.
Ring 0, das Labor	Ein Lauf auf Hetzner legt einen Cluster mit einem Node auf dem vorigen Release an, upgradet ihn, macht einen Snapshot, stellt ihn wieder her und aktualisiert das Image.
Ring 1, meine eigenen Cluster	Das Release läuft auf meinen eigenen Clustern.	3 Tage
Kanal early	Cluster, deren Besitzer early gewählt haben, bekommen es.	7 Tage
Kanal stable	Alle anderen. Ein Release auf stable liegt auch auf early, außer early bietet schon ein neueres an.
Zurückgezogen	Von jedem Kanal genommen, in jeder Phase.

Den Kanal wählst du pro Cluster, stable oder early, beim Anlegen oder später auf seinem Reiter Upgrades.

Die Releases

Release	Node-Image	k3s	minAgent	Erreichbar von	Status
2026.10.0	Garden Linux 2150.6.0	v1.36.4+k3s1	0.1.0	(das erste)	Gebaut im Labor, mit einem Laborschlüssel signiert; nicht veröffentlicht
2026.10.1	Garden Linux 2150.11.0	v1.36.4+k3s1	0.1.0	2026.10.0	Gebaut im Labor, mit einem Laborschlüssel signiert; nicht veröffentlicht
2026.10.2	Garden Linux 2150.11.0	v1.36.4+k3s1	0.2.0	2026.10.1, 2026.10.0	Gebaut im Labor, mit einem Laborschlüssel signiert, mit einer Kopie von Image und Quelle der Plattform; nicht veröffentlicht: In Arbeit öffentliches Image und öffentliche Quelle der Plattform

• 2026.10.1 ändert nur das Image: dasselbe k3s und dieselben Add-ons. Es ist der Schritt, über den der Laborlauf vom 2026-10-10 einen Cluster gebracht hat: 83 Sekunden, und die API war 34 Sekunden lang nicht erreichbar, während der Node neu startete.
• 2026.10.2 behält Image und k3s von 2026.10.1 und bringt zwei optionale Add-ons dazu, Flux und die PaaSbox Platform. Von 2026.10.1 aus legt das Upgrade dasselbe Image unter einem neuen Boot-Eintrag an und startet einmal neu: 40 Sekunden im Labor, 24,7 davon ohne API. Es braucht pbx-agent 0.2.0, den ersten, der die Regeln für Add-ons kennt, die andere brauchen oder sich mit ihnen nicht vertragen. Veröffentlicht werden kann es erst, wenn alles öffentlich ist, was die PaaSbox Platform lädt: das Controller-Image mit festgelegtem Digest und seine Quelle mit festgelegtem Commit. Bis dahin verweigert der Build es.

Die Add-ons jedes Releases:

Add-on	Version	2026.10.0	2026.10.1	2026.10.2
Hetzner Cloud Controller	Chart 1.33.0	ja	ja	ja
Lokaler Speicher	OpenEBS LocalPV-LVM 1.10.1, Teil des Images	ja	ja	ja
Traefik	Chart von k3s 40.1.4+up40.1.0 (Traefik 3.7.8)	ja	ja	ja
Hetzner-Volumes	CSI-Treiber, Chart 2.21.2	ja	ja	ja
cert-manager	v1.20.2, mit dem Webhook von Hetzner 0.9.0 für DNS-01	ja	ja	ja
external-dns	Chart 1.23.0, mit dem Webhook-Provider von Hetzner v0.5.0	ja	ja	ja
Flux	Flux 2.9.5 (Chart flux2 2.19.1)	—	—	ja
PaaSbox Platform	1.0.2: der Controller von saas-platform in der festgelegten Version des Releases	—	—	ja

Der Add-on-Katalog beschreibt jedes einzelne, seinen Speicher und seine Optionen.

Nicht in diesen Releases: Monitoring und Logs, Load Balancer von Hetzner (Traefik antwortet auf den eigenen Ports 80 und 443 des Servers) und Hetzner-Volumes als Standard-Storage-Klasse.

Einen Cluster upgradenEinen Cluster auf ein neueres Release bringen, sofort oder im Fenster.

Add-on-KatalogJedes Add-on der Releases, sein Speicher und seine Optionen.