Status of each part
The status of every part of PaaSbox Clusters, as of 2026-10-11, with the evidence for it. The offer itself is In progress: it ran end to end on real Hetzner servers in a lab, a disposable Hetzner project with the portal running as it would in production, and it cannot be booked until the portal is live.
The cluster and the node
Section titled “The cluster and the node”| Part | Status |
|---|---|
| The node image: Garden Linux with k3s inside | Built It boots on Hetzner under UEFI and passed 20 of 20 node checks on two server types, cpx22 and cax11 (2026-09-27). It carried the lab clusters of 2026-10-10, and an upgrade replaced it in place, from Garden Linux 2150.6.0 to 2150.11.0. |
pbx-agent: enrollment, signed requests, the sync, the operations, its own updates | Built in a lab: every operation in this table ran on real servers. Killed in the middle of an operation, it resumed at the step it was in; a tampered release was refused; an operation delivered twice ran once; and it rotated its own keys and updated itself three times. In progress A self-update that rolls itself back has not fired yet, nor an update forced by the portal. |
| Creating a cluster | Built in a lab: 2 minutes 46 seconds on a cpx22, 69 seconds of it copying the node image into the project; the firewall let in exactly 6443, 80, 443 and ICMP. The run started the create with a management command; a second lab run created a cluster through the create form’s requests in 54 seconds, the node image already in the project. In progress The create form used in a real browser. |
| A cluster on a server you already have | Built in a lab: an Ubuntu cpx22 became a cluster in 178 seconds, and was handed back, still running, when the cluster was deleted. |
| Servers on arm64 (CAX) | In progress The image boots on cax11; a cluster on one has not run yet. |
| Three servers per cluster | Planned later, with its own price |
Operating a cluster
Section titled “Operating a cluster”| Part | Status |
|---|---|
| Temporary kubeconfigs | Built in a lab: a view kubeconfig in 10.7 seconds and an admin one in 21 seconds, from request to file; refused within 11 seconds of a revoke. A view kubeconfig cannot list nodes. |
| Snapshots to your own S3 bucket | Built in a lab: a snapshot reached the bucket in 25 seconds. A self-hosted S3 server stood in for the bucket. In progress Hetzner Object Storage itself, and keys you hold yourself. |
| A snapshot target added after create | Built in a lab: pbx-agent wrote the bucket’s Secret within 6 seconds, and the next snapshot went to S3 without a restart of k3s. |
| A restore in place | Built in a lab: 160 seconds, with the data in the volumes intact. |
| A restore onto a new server | Planned No page of the portal creates it. |
| Upgrades, with a snapshot first | Built in a lab: an upgrade from release 2026.10.0 to 2026.10.1 took 83 seconds, a snapshot first; the API was down for 34 seconds while the node rebooted. An upgrade to 2026.10.2, on a cpx32 in a second lab run, took 40 seconds, with 24.7 seconds of API downtime. In progress The automatic return to the previous image after an unhealthy boot, and upgrades and restarts that wait for the maintenance window. |
Rotating pbx-agent’s keys and the bucket’s keys | Built in a lab: new agent keys in 17 seconds; new bucket keys, checked against the bucket first, in 8 seconds. Wrong keys were refused and the old ones stayed in force. |
| Replacing the project’s Hetzner token, and the token inside the cluster | In progress Code; not run on a real cluster. |
| Changing who may reach the Kubernetes API on Settings | In progress Code: saving changes the cluster’s firewall at once; not run on a real cluster. The firewall made at create ran. |
| Curated add-ons: storage, ingress, certificates, DNS records | Built in a lab: local storage and Traefik on every lab cluster; Hetzner volumes switched on, with a volume bound and mounted; cert-manager with a Let’s Encrypt staging certificate over HTTP-01, switched on and off again with its certificates kept. In progress external-dns, and cert-manager over DNS-01. |
| The Flux and PaaSbox Platform add-ons | Built in a lab, on 2026-10-10 and 11, with a copy of the platform’s image and source: Flux running 71 seconds after the save; the platform with every profile; upcheck as a SaaSApplication ready 82 seconds after kubectl apply, served over HTTPS with a Let’s Encrypt staging certificate, its database backed up to S3 and its data intact after its pods were deleted; a wildcard certificate over DNS-01 in 4 minutes; observability in 104 seconds; conflicting and missing add-ons refused by the portal and by pbx-agent; switching off refused while an application runs; both switched off in one save in 70 seconds. In progress Release 2026.10.2 is not published: the platform’s controller image and source are not public yet. Let’s Encrypt production certificates, a restore of a database from its backup, and an update of the platform to a newer version have not run. |
| Monitoring and logs add-ons | Planned after the launch |
| Delete | Built in a lab: 14 seconds, and no resource with the cluster’s label left, its Hetzner volumes included. In the second lab run the portal’s pages deleted two clusters in 19 and 20 seconds. |
Detach and pbx-agent uninstall | In progress |
| The guide to running without the portal | In progress Written; its steps have not been run by hand on a cluster yet. |
The portal, agents and billing
Section titled “The portal, agents and billing”| Part | Status |
|---|---|
| The portal: your Hetzner projects, the hub, the provisioner, the queue of operations | Built in a lab: the hub and the provisioner created, maintained and deleted clusters. The portal is not live. |
| The REST API and MCP tools for agents: API keys with scopes, typed confirmations, rate limits, the audit log, kubeconfigs sealed to an agent’s key | In progress Code with tests; not run against a real cluster. Names can still change. |
| Billing through Paddle, the merchant of record | In progress Code; not run against Paddle. The lab ran with billing off. |
| Alert mails to the team’s admins | In progress Code; the lab sent no mail. |
| The pairing with Cloud Viewer | In progress Code on both sides; not run end to end. |
“Built” means it ran end to end on real servers in a lab, here in a disposable Hetzner project on 2026-10-10 and 11; it is not released. “In progress” means the code exists and passes its tests, but has not run end to end on real servers. “Planned” means designed, not built. Operated in the open has the run’s figures.
Operated in the openThe lab runs behind these statuses, row by row.
What PaaSbox doesThe approach, the product and where to start.