Managed Upgrades
Part of the managed tier — live today
Managed Kubernetes upgrades ride the managed tier (access: managed), which is live and requires a Supporter subscription or higher (hosted and enterprise tenants have it included). The tier adds kubehz's management features on top of registered — healing policies, capacity watches, and desired-state management driven from the dashboard. Acting features roll out deliberately behind per-feature switches, so a feature can be visible in the dashboard before its acting half is switched on for a deployment — the one-click upgrade flow is still rolling out.
Upgrading a self-hosted cluster yourself? That works as always with the lok8s provisioner (KubeOne/CAPI): bump the version in your spec and re-run the provisioner. That is a lok8s operation on your own cluster, independent of kubehz — see the lok8s documentation.
The model
The managed tier is the access: managed axis of the two-axis model. On a cluster you have turned it on for, kubehz's management features are driven from the dashboard: healing policies, capacity watches, and desired-state management — upgrade and scaling flows ride that desired-state seam. For an upgrade, kubehz records the desired Kubernetes version and your cluster (or a hosted control plane) carries it out:
- control plane first, then workers cordoned/drained/upgraded one at a time,
- version-skew rules enforced (no skipping minor versions),
- pre-checks for removed APIs, node readiness, and etcd health,
- automatic rollback if an upgrade fails mid-way.
The mechanism — pull, not push
Acting is pull-based. The in-cluster agent fetches desired state from the platform (GET /clusters/{id}/desired) and applies it locally with the cluster's own credentials. The platform never holds an inbound credential and never pushes into your cluster.
For a self-hosted managed cluster this means kubehz needs no Hetzner token: kubehz records desired state and your cluster's own machine-controller does the work with credentials it already holds.
Per-feature execution switches gate the acting half of each managed feature, so acting features roll out deliberately — visibility first, acting when the switch is on for a deployment.
What's live today
- Version reporting (which version each registered cluster runs) — live via the heartbeat agent; you can see it in the dashboard.
- The managed tier itself — live (Supporter+): healing policies, capacity watches, and desired-state management from the dashboard.
- The kubehz-driven one-click upgrade flow — rolling out behind the per-feature execution switches above.
The gate is a subscription, not a change to registration: a managed cluster registers and is claimed exactly like a registered one. The tier gate applies when a tenant drives management features — the platform refuses a free tenant's switch to managed.
Next steps
- How it works — the managed tier and trust boundary
- Registration — get version + health visibility today
Doc status
| Aspect | Detail |
|---|---|
| State | active |
| Last reviewed | 2026-07-17 |