Releases and channels

A release is the unit in which PaaSbox Clusters changes a cluster: the node image with its k3s, the version of pbx-agent, and the add-ons, tested together and signed. This page says how a release is made, signed and promoted, how a cluster moves from one to the next, and what each release contains.

Status

The release format, its signing and pbx-agent’s checks are Built in a lab: on 2026-10-10 the releases 2026.10.0 and 2026.10.1 were signed with a lab key, imported into the portal, and a cluster upgraded from the first to the second on a real Hetzner server; a tampered copy was refused. On 2026-10-10 and 11 a second lab run did the same with 2026.10.2, its platform pointing at a copy of the platform’s image and source. In progress No release is signed with the release key or published yet, and none has gone through the whole promotion below.

What a release is

Part	What it is
Node image	Garden Linux with a pinned k3s inside it, for amd64 and arm64. Its root file system is read-only; an upgrade replaces the whole image.
pbx-agent	The oldest pbx-agent that can apply the release (minAgent), and its download for each architecture with its checksum.
Add-ons	Each with a pinned chart version, its template, the schema of its options, its memory figures, what it requires and what it conflicts with.
Reached from	The releases it was tested from (upgradesFrom).
Platform	From 2026.10.2: the PaaSbox Platform’s controller image and the source its parts are installed from, at one version.

A cluster only ever moves from one release to another. Nothing on a cluster follows an upstream channel on its own: a new k3s reaches your cluster only inside a release. Releases are named by date and number: 2026.10.0, 2026.10.1, and so on.

Signing

What	How
The key	An Ed25519 key that I keep offline: never on the portal, never in CI, never on the machine that builds the manifest. pbx-release keygen makes it.
The signature	pbx-release sign over the manifest’s bytes exactly as stored; pbx-release verify checks it.
pbx-agent	Carries two public keys, the current one and the next one, compiled in. It refuses a manifest that neither signed (manifest_rejected) and changes nothing. Nothing at run time can change which key it trusts.
The portal	Holds the same two public keys and refuses to import a manifest they do not verify.
Replacing the key	The next key is already in every pbx-agent, so the key can be replaced without a gap.

From one release to the next

Rule	Where it is enforced
The portal offers a cluster a release only if that release names the cluster’s current one in upgradesFrom.	The portal’s queue
Patch releases, on the same k3s minor version, are queued for your maintenance window on their own, unless you switch that off for the cluster. In progress Upgrades that wait for the window have not run on a real cluster.	The portal, every hour
A new k3s minor version waits for your click.	The portal
At most five upgrades run at the same time, across all clusters.	The portal’s queue
If two of the first five upgrades to a release fail, the portal pauses that release and mails me. A paused release is offered to no one.	The portal
A release can be withdrawn at any stage. Its channels fall back to the newest release still at their level. Clusters already on it stay where they are.	The portal

How an upgrade runs on a node is on Upgrade a cluster.

Promotion and channels

Stage	What happens	How long
Candidate	The image, pbx-agent and the manifest are built, and the manifest is signed offline and imported.
Ring 0, the lab	A run on Hetzner creates a single-node cluster on the previous release, upgrades it, takes a snapshot, restores it and updates the image.
Ring 1, my own clusters	The release runs on my own clusters.	3 days
Early channel	Clusters whose owners chose early get it.	7 days
Stable channel	Everyone else. A release on stable is also on early, unless early already offers a newer one.
Withdrawn	Taken off every channel, at any stage.

You choose the channel per cluster, stable or early, when you create it or later on its Upgrades tab.

The releases

Release	Node image	k3s	minAgent	Reached from	Status
2026.10.0	Garden Linux 2150.6.0	v1.36.4+k3s1	0.1.0	(the first)	Built in a lab, signed with a lab key; not published
2026.10.1	Garden Linux 2150.11.0	v1.36.4+k3s1	0.1.0	2026.10.0	Built in a lab, signed with a lab key; not published
2026.10.2	Garden Linux 2150.11.0	v1.36.4+k3s1	0.2.0	2026.10.1, 2026.10.0	Built in a lab, signed with a lab key, with a copy of the platform’s image and source; not published: In progress the platform’s public image and source

• 2026.10.1 changes only the image: the same k3s and the same add-ons. It is the step the lab run of 2026-10-10 upgraded a cluster through: 83 seconds, with the API down for 34 seconds while the node rebooted.
• 2026.10.2 keeps the image and k3s of 2026.10.1 and adds two optional add-ons, Flux and the PaaSbox Platform. From 2026.10.1 the upgrade stages the same image under a new boot entry and reboots once: 40 seconds in the lab, 24.7 of them without the API. It needs pbx-agent 0.2.0, the first that knows the rules for add-ons that require or conflict with others. It can be published only once everything the PaaSbox Platform pulls is public: the controller image at a pinned digest and its source at a pinned commit. The build refuses it until then.

The add-ons of each release:

Add-on	Version	2026.10.0	2026.10.1	2026.10.2
Hetzner cloud controller	chart 1.33.0	yes	yes	yes
Local storage	OpenEBS LocalPV-LVM 1.10.1, part of the image	yes	yes	yes
Traefik	k3s’s chart 40.1.4+up40.1.0 (Traefik 3.7.8)	yes	yes	yes
Hetzner volumes	CSI driver chart 2.21.2	yes	yes	yes
cert-manager	v1.20.2, with Hetzner’s webhook 0.9.0 for DNS-01	yes	yes	yes
external-dns	chart 1.23.0, with Hetzner’s webhook provider v0.5.0	yes	yes	yes
Flux	Flux 2.9.5 (chart flux2 2.19.1)	—	—	yes
PaaSbox Platform	1.0.2: the saas-platform controller at the release’s pinned version	—	—	yes

The add-on catalogue describes each one, its memory and its options.

Not in these releases: monitoring and logs, load balancers from Hetzner (Traefik answers on the server’s own ports 80 and 443), and Hetzner volumes as the default storage class.

Upgrade a clusterMove a cluster to a newer release, now or in its window.

Add-on catalogueEvery add-on of the releases, its memory and its options.