Skip to content

FAQ

Sign up at console.paasbox.com — the quickstart takes you from token to kubectl get nodes in about ten minutes.

nbg1 (Nuremberg) is live; fsn1 and hel1 show “Register interest” and open at sustained demand. See regions for the current map and how to choose.

Yes. paasbox issues a genuine admin kubeconfig for your cluster. You deploy and manage your workloads yourself with kubectl, Helm, or Flux — paasbox is a cluster-lifecycle, fleet, and billing console, not an in-cluster UI, and it stays out of your way.

No. Your worker nodes, load balancers, and volumes live in your own Hetzner Cloud project and Hetzner bills you for them directly. paasbox is software that provisions and operates your cluster on your own cloud — it never resells infrastructure or compute.

No — Hetzner Cloud only. The entire value proposition (your servers, your grandfathered prices) is Hetzner-specific.

Why does the Hetzner token need read/write?

Section titled “Why does the Hetzner token need read/write?”

On-demand (“managed”) node pools legitimately create and delete servers in your project, and Hetzner API tokens can’t exclude delete — so read/write is required for that path. The grandfathered (“pooled”) path never deletes: that guarantee is a code invariant plus Hetzner delete-protection, not a matter of token scope. We disclose this plainly when you connect your account — and security & trust covers how the token is stored and what it can reach.

What happens to a server when I “adopt” it?

Section titled “What happens to a server when I “adopt” it?”

Adoption brings the server under Kubernetes by rebuilding it — an OS reinstall, which wipes the disk. Migrate your workloads off first; the portal makes you confirm this explicitly. After adoption, the server is rebuilt in place and never deleted, which is exactly how it keeps its grandfathered price. Full flow and the price-safety matrix: adopt your servers.

Can I mix grandfathered and on-demand nodes?

Section titled “Can I mix grandfathered and on-demand nodes?”

Yes. A cluster can have a pooled pool over your adopted servers (your cheap baseline) and a managed pool of on-demand nodes for burst that scales to zero. The autoscaler prefers your pooled nodes and only spills to on-demand when the pool is full. How the two behave: node pools.

The cluster is torn down and the per-cluster charge stops, prorated. Your adopted servers are not deleted — they’re your property and keep their grandfathered rate, ready to use in another cluster.

We operate and back up the control plane — your cluster’s etcd state, continuously. Your application data — databases, volumes, object storage — is yours to back up, the same as on any cluster where you hold admin. The honest split is spelled out in backups & availability.

Not as such — there’s a €5 signup credit (one per team), with a card required up front. Nothing is charged until you start a cluster, and on the hourly plan the credit covers dozens of awake-hours; hibernate when you’re done and the meter reads €0. That’s the low-commitment way to try paasbox for real.

You’re warned as you approach it, and at the limit your awake clusters are hibernated — never deleted. State, volumes, and adopted servers all survive. Raise the cap (or wait for the month to roll over) and wake them. Details in billing & spend controls.

New clusters offer recent upstream minor versions — currently defaulting to 1.35.x (as of 2026-07-09). You pick the version when composing the cluster; version upgrades are rolled out by the platform, with adopted servers upgraded by rebuild-in-place so their price is never at risk.

Can I use paasbox without grandfathered servers?

Section titled “Can I use paasbox without grandfathered servers?”

Yes. A cluster with only managed (on-demand) pools is a perfectly normal setup: you still get the operated control plane, scale-to-zero pools, hibernation, and the flat per-cluster fee. Adopting grandfathered servers is the flagship saving, not a requirement.