Leaving PaaSbox

A managed service you cannot leave is a risk, however good it is. PaaSbox is built so that leaving needs no permission from us, and the pieces are drilled, not promised.

What you hold, at all times

• Your nodes, load balancers, volumes and gateway are in your Hetzner project. Nothing of yours runs in ours.
• Adopted servers are never deleted. The component that manages them has no delete path.
• Your cluster as Gardener YAML, exportable from the console or the API at any time — the exact definition the platform applies, redacted of secrets. See the export.
• The escrow. Your cluster’s etcd snapshots — every five-minute delta and every daily full — and the cluster’s keys (its certificate authority, service-account signing key, etcd encryption key and SSH key) are copied into a bucket in your own Hetzner project, encrypted to a key only you hold. The copy runs continuously; the console shows the age of the newest escrowed snapshot, and a command in the exit kit verifies that the escrow decrypts.
• Your own API domain, if you want one. A cluster’s API endpoint can live under a domain you own, managed through your own Hetzner DNS token. Then the one lever a take-over needs, repointing the name, is in your hands.

The exit kit

The exit kit is an open-source project. It takes a cluster from the escrow to a control plane you run, while the workloads keep serving:

1. Bootstrap a garden and seed in your project. One server for a test cluster, three for a production cluster’s highly available control plane. It is the same script that built PaaSbox’s own platform.
2. Restore the control plane from the escrow. The kit decrypts the keys and the newest snapshot and brings up your cluster’s control plane on your seed, with the same certificate authority, so every existing credential keeps working.
3. Repoint the API name. With your own domain, you do it. With a PaaSbox domain, we do it on request, and at a wind-down we hand every name over.
4. Watch the nodes reconnect. The nodes never stopped. They find the control plane at its name, the tunnel comes up, and the cluster is yours: on-demand pools, adopted servers and the NAT gateway included, because the pool stack and the provider ship in the kit.

Measured in the drill: about 30 to 40 minutes from starting the kit to a reconciled cluster, with no pod restarted. The drill runs every quarter against a copy of a real cluster shape, and its record is published with the monthly numbers.

Leaving without Gardener

You do not have to run Gardener to leave. The recreation path:

• stand up k3s or kubeadm on new servers, or on your adopted servers after rebuilding them by hand;
• re-attach your Hetzner volumes as static PersistentVolumes — they were never touched;
• apply your applications from your own Git repository. Every cluster can run its own Flux for exactly this, which is also why we recommend it on day one.

What you lose on this path is the cluster’s live state between your last Git commit and the switch, and the operated control plane. What you keep is everything that costs money: the servers, their prices, the data.

The wind-down promise

If PaaSbox ever stops:

• Six months’ notice, in writing, to every customer, before any cluster is affected.
• Migration help at no charge during that time — the exit kit run with you, or the recreation path, whichever you choose.
• Prices frozen for the notice period.
• Everything stays public. The exit kit, the docs, the Hetzner stack under Apache-2.0, and every component adopted servers need to keep working as nodes.

This promise is part of the terms, not of a blog post.

Deleting a cluster

Deleting a cluster from the console tears down its control plane and, for on-demand pools, its nodes; the per-cluster charge stops, prorated. Adopted servers return to your fleet with their price. Volumes are yours and stay until you delete them. The escrow is yours too: the bucket and its contents remain in your project, so a deleted cluster can still be rebuilt with the kit from its last snapshot.