Cluster lifecycle
This page describes two lifecycle behaviors on hosted clusters: how a free-tier control plane that sits completely unused is eventually reclaimed, and what happens if a paid plan’s payment fails.
Hosted
Idle reclamation applies to free-tier hosted clusters only; the non-payment behavior below applies to paid plans.
Free-tier idle reclamation
Free hosted control planes run on a shared pool. To keep that pool healthy for people who are actively using it, a free control plane that shows no activity at all is eventually reclaimed. This applies only to the Free / Community tier. Paid clusters are never idle-reclaimed.
Being billed €0 today is not the free tier. Nothing is charged before 1 November 2026, so every plan currently costs nothing, but eligibility follows your account’s tier (Free, Supporter, Enterprise), not the amount on the invoice and not the cluster’s plan. A cluster owned by a Supporter or Enterprise account is never idle-reclaimed, whatever plan it runs on, including during the free period.
Nothing here happens suddenly. Reclamation runs on a long, clearly-signposted schedule, and any activity resets it immediately.
What counts as activity
Any one of these keeps a cluster alive, or instantly resumes a paused one:
- Downloading the kubeconfig from the dashboard.
- Changing cluster settings.
- Adding or changing workers.
- The cluster heartbeating: a running, connected cluster reports in on its own.
There is nothing to click to “stay active,” no form and no support ticket: any of the above resets the clock automatically.
The schedule
| Stage | When | What happens |
|---|---|---|
| Idle warning (day ~14) | after ~14 days with no activity | We email you that the cluster looks unused. It keeps running normally. |
| Paused (day ~21) | ~7 days later, if still unused | The cluster is paused and a 30-day removal countdown starts. You get a second email. |
| Removed (day ~51) | at the end of the 30-day countdown, if still unused | The managed control plane is permanently removed. A final email confirms it. Total runway from first idle day: about 51 days. |
At any stage, a single piece of activity stops the process and, if the cluster was paused, resumes it.
Your data
Your Kubernetes workloads and their data live on your own workers, on your Hetzner account. Reclamation removes the managed control plane, after the long grace period above. If you no longer need the cluster, you can simply let it lapse. If you might want it, export or migrate anything you need during the countdown (see Migration), or take a single activity to keep the cluster.
Non-payment on paid plans
Nothing is charged before 1 November 2026
€0 until 1 November 2026
No payments run before that date (see Pricing). Everything in this section describes the behaviour once billing starts.
Once billing is live, hosted plans are billed per the Pricing page. When a payment fails on a paid plan, service does not stop immediately:
- Grace period: we email you about the failed payment, and your clusters keep running while you resolve it. You have 14 days from the failed payment before the next step.
- Suspended: if it stays unresolved, the account is suspended. Existing clusters keep running, but creating or changing resources is blocked.
- Restored: settling the payment restores full access automatically. There is nothing else to do.
- If it is never settled: a suspension does not delete anything. Clusters stay suspended, and the only route to removal is termination under §13 of the Terms: 90 days’ notice from us, or immediately if the Terms were breached. Data is then deleted within 30 days. Your worker nodes live in your own Hetzner account throughout and are billed by Hetzner, not by us.
Kubernetes version lifecycle
You pick your hosted cluster’s Kubernetes version from the offered list and upgrade whenever it suits you: always forward, one minor version per step, executed inside your maintenance window. The dashboard’s version picker shows what each choice means before you commit (see the matrix on the create page).
Two dates matter for every minor version:
| Event | What happens |
|---|---|
| A new patch of your minor appears | Shown in the dashboard; upgrading is yours to schedule. |
| Your minor’s upstream EOL date approaches | We mail you 30, 14, and 7 days ahead. |
| The EOL date passes | Once the forced-EOL clause is in the Terms (§14a), your cluster is upgraded to the next supported minor (one step, never more), inside your maintenance window. Until then the platform mails you and leaves the upgrade to you. |
The EOL notices and the confirmation of a performed upgrade are service-critical and cannot be muted. Everything else (announcements, capacity notes) respects the notification settings in your dashboard account.
Spaces (shared control plane) are versioned by us: the fleet runs one minor behind the newest supported release, and new patches roll two weeks after upstream publishes them. You get an announcement before your Space’s control plane is upgraded and a confirmation after. Your machines are never touched: if a node’s kubelet would fall outside the supported version skew, it keeps running, gets flagged in the dashboard, and you’re asked to upgrade it at your convenience. Joining is gated at the same line: a machine whose kubelet is more than two minor versions behind the Space’s control plane is refused at the door (with the reason). Upgrade the kubelet, then join.
Next steps
- Setup: plans, pricing, and what’s live today.
- Migration: export and move workloads off a cluster.
- Worker Pools: your workers and their data live here.
Doc status
| Aspect | Detail |
|---|---|
| State | Live: idle reclamation live (free tier); dunning live (paid plans) |
| Last reviewed | 14 July 2026 |