Choose your setup

Before you create a cluster you mean to keep, there are four decisions: how many clusters you need, which server each one runs on, whether a cluster may carry production, and which add-ons it gets. This page gives the facts for each. Create a cluster has the steps.

One cluster or several

The setup PaaSbox is built for is one small cluster per stage and per app, plus a throwaway cluster for each test:

You run	Clusters
One app, production only	1
One app, with staging and production	2
Two apps, each with staging and production	4
Tests for pull requests	one more for each test, deleted after it

Separate clusters keep a mistake small. An upgrade, a restore or a runaway test reaches one stage of one app. Staging can take each new release first, on the early channel, while production waits on stable in its own maintenance window. Each cluster has its own kubeconfigs and its own API ranges, so access to staging gives no access to production.

Each cluster costs the price once, €29 incl. VAT a month, plus its server at Hetzner. A throwaway cluster next to a cluster you keep counts only while it exists: Paddle charges it prorated when it is first ready and credits the rest when you delete it In progress. A team’s only cluster, though, costs a full month even if you delete it minutes later, so a team’s first cluster should be one you may keep. A team may have 10 clusters at once; clusters being deleted, deleted and detached do not count. The create form says when the team has reached them, and more are available on request.

Clusters can share a Hetzner project, and the node image is copied into each project only once. Give production a project of its own anyway. The cloud controller and the volume driver inside each cluster use a Hetzner token, and a Hetzner token opens its whole project: whoever can read that token in a test cluster could change production’s servers if both share a project.

Which server

The portal offers three of Hetzner’s server lines:

• CPX (shared vCPU) and CCX (dedicated vCPU), both amd64.
• CAX, arm64. In progress The node image boots on a cax11; a cluster on one has not run yet.

The CX line is not offered: it boots with BIOS only, and the node image needs UEFI. Within the three lines, the form lists what Hetzner sells in the chosen location, with Hetzner’s monthly list price. Hetzner bills it to you; the portal adds nothing.

Memory decides the size. Measured in the lab on a cpx22 with 4 GB: a fresh cluster used 1.2 GiB of the 3.8 GiB the server has; Hetzner volumes added 82 MiB and cert-manager 64 MiB. Measured in the platform lab on 2026-10-11: Flux 138 to 189 MiB while the platform is being set up, the PaaSbox Platform 96 MiB (minimal) to 164 MiB (saas-http01), with its observability (metrics, logs, traces, Grafana) 826 to 868 MiB, and upcheck, a small web app with Postgres, a cache and a worker, 559 to 606 MiB. A cpx22 with Flux and saas-http01 and no app had 1.4 GiB left; the k3s server process alone took 1.0 GiB. The portal plans with higher figures: 170 MiB for Flux, 150 to 330 MiB for the platform, up to 1.2 GiB with observability.

• 4 GB (a cpx22) carries the cluster, Flux, the PaaSbox Platform without observability, and one small app.
• 8 GB or more if you want the platform’s observability. The portal offers an add-on, or an option of one, only on a server with enough memory: in the lab the create page refused a cpx22 for saas-http01 with observability and offered a cpx32.

Changing the server type of an existing cluster is Planned. Choose a type with room, or create a new cluster and move the app. A server you already have keeps its ID, its addresses and its price; its disk is erased.

Production or non-production

PaaSbox Clusters is for both. Production on a single node means three things, and you accept them before you put production on it:

• There is no SLA. If the server fails, your apps are down until it is back or restored.
• Every upgrade reboots the node. In the lab the Kubernetes API was down for 34 seconds, and your apps are down while the node restarts. Upgrades run at once if you ask, or in your maintenance window In progress.
• A broken node is answered by a restore or a rebuild: a snapshot restored in place, or a new cluster with your apps deployed again. A restore onto a new server is Planned.

Two things are then on you. Send the snapshots to an S3 bucket: without one they stay on the server’s disk and are lost with it. And back up the data of your apps: a snapshot holds the cluster’s state, not the contents of your volumes; a database needs its own backups, which the PaaSbox Platform sets up for Postgres: in the lab its write-ahead log and a base backup reached S3; a restore from them has not run yet In progress.

If an app must survive the failure of a server, it needs more than one server, and PaaSbox Clusters is not the right fit for it today. Clusters with three servers are Planned, later and with their own price.

Staging, tests, previews and labs are non-production: everything above applies, with less at stake.

Which add-ons

A cluster starts with what it needs to run; the rest you switch on. You can change them later on the cluster’s Add-ons tab.

Add-on	Default	Switch it on for	Status
Hetzner cloud controller	always on	— (connects the cluster to your project)	Built
Local storage, class local-lvm-thin	always on	volumes on the server’s own disk; they go with the server	Built
Traefik ingress	on	HTTP and HTTPS on the server’s ports 80 and 443	Built
Hetzner volumes, class hcloud-volumes	off	volumes that do not count against the server’s disk; Hetzner bills them, and deleting the cluster deletes them	Built
cert-manager	off	certificates from Let’s Encrypt for your Ingresses	Built over HTTP-01; DNS-01 In progress
external-dns	off	DNS records in your Hetzner DNS zones	In progress
Flux	off	deploying your apps from a Git repository	Built in a lab; not published yet In progress
PaaSbox Platform	off	apps as a SaaSApplication, with Postgres, certificates and, optionally, observability; it needs Flux and brings its own cert-manager	Built in a lab; not published yet In progress
Monitoring, logs	—	—	Planned

Choose add-ons has the steps and what happens to their data; the add-on catalogue has every option and version.

For help with the setup, or with a platform of your own: Call me.

Create your first clusterLearn step 1: these decisions made for one cluster, which you keep for the rest of the path.

Why isolated clusters for agentsA cluster per test, per stage and per app: what it buys and what it costs.