Backups & availability

Two questions decide whether you can trust a managed platform with production: what happens to my cluster’s state if something breaks, and what happens to my apps while it’s broken. Here are both answers, stated plainly.

What we back up

Your cluster’s etcd state — every Kubernetes object you’ve created: Deployments, Services, ConfigMaps, Secrets, PVC bindings — is backed up continuously: incremental deltas roughly every five minutes, with periodic full snapshots, to S3-compatible object storage independent of the machines running your control plane. If the platform ever has to rebuild your control plane, it restores from this chain; your cluster’s definition doesn’t depend on any single disk.

While a cluster is hibernated, no new snapshots are taken (there’s nothing changing), and the most recent chain is retained for the wake.

What we do not back up

The etcd backup covers your cluster’s definitions — not your application data:

• Persistent volumes and databases are yours. The etcd backup knows a PVC exists; it does not contain the bytes on the volume.
• Anything your apps store elsewhere — object storage, external databases — is likewise outside the platform’s view.

You hold cluster-admin, so you can run any backup tooling you like; a step-by-step guide for workload backups with Velero to S3-compatible storage is coming to the guides section. Until then, the honest one-liner stands: we keep your cluster restorable; you keep your data restorable.

What the HA tier changes

The two tiers differ in exactly one thing — the control plane’s failure tolerance:

• Basic runs a single etcd and API-server replica. If the platform node underneath restarts, your control plane restarts with it: a few minutes where management pauses.
• HA runs three synchronously replicating etcd replicas and multiple API servers, spread so the control plane survives the failure of a platform node without interruption.

Both tiers get the same continuous backups — HA reduces interruptions, backups protect against loss. They’re different defenses, and you get the second one regardless of tier.

Control plane down ≠ apps down

The most misunderstood fact about managed Kubernetes, and the one worth internalizing:

Your workloads do not run on the control plane. They run on your worker nodes, in your Hetzner project. If the control plane is unavailable — a Basic-tier restart, maintenance, an incident — pods that are already running keep running and keep serving traffic. Your load balancers keep forwarding. What pauses is management: deploys, scaling changes, rescheduling, new nodes. When the control plane returns, reconciliation catches up.

So the practical impact of a short control-plane pause on a serving application is usually: nothing your users notice. That’s the honest reason Basic is safe for tolerant production — and the honest reason HA matters when you deploy continuously or rely on autoscaling reacting within minutes.

Two boundaries to keep the story complete: overall availability is also bounded by the infrastructure underneath (Hetzner does not offer strong availability commitments for cloud servers) and by your own workers’ redundancy — a one-node cluster has a one-node failure domain, whatever the control plane does. Spreading replicas across nodes is the scaling guide’s territory.

What we commit to — and what we don’t publish yet

The terms commit to a control-plane availability of

95.8 % per calendar month per cluster, measured as reachability of the cluster’s Kubernetes API server, with planned maintenance capped at four hours a week and announced 24 hours ahead. Falling short earns a service credit on a published ladder.

That figure is deliberately modest, and we’d rather explain it than dress it up: PAASBOX is a one-person operation without round-the-clock on-call, so we commit to what we can actually hold overnight and on weekends. Note what the number does and does not cover — if the control plane is unavailable, your workloads keep running; what stops is deployments, scaling and cluster changes.

What we still don’t publish is measured uptime (as of 2026-07-09). Young platforms quoting big numbers is marketing, not engineering — we’d rather publish real figures once there’s a meaningful operating history behind them. Until then, this page tells you exactly how the system behaves when things fail; hold us to that.

Questions this page doesn’t answer? Ask — and for how credentials and tokens are protected, see security & trust.