Managed Upgrades
Managed tier live, one-click upgrades rolling out
Managed Kubernetes upgrades ride the managed tier (access: managed), which is live and requires a Supporter subscription or higher. Enterprise accounts include it, and so does every hosted control plane. 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 hosted cluster today? Ask us and we run it for you: say so in #support on chat.kubehz.cloud, or e-mail contact@kubehz.io with the cluster and the version you want. The one-click flow replaces this when the switch is on for your deployment.
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. Where the upgrade switch is on, your cluster’s agent moves the workers toward it:
- The version is checked before it is recorded. No downgrades, no end-of-life targets, and no skipping a minor version.
- The control plane goes first, and on a self-hosted cluster that part is yours. You upgrade it with your own provisioner (
lo provision/kubeone apply). The agent then refuses to move workers while the observed control-plane version is still behind the target, or while it cannot read that version at all. It never touches the control plane itself. (On a hosted control plane the control plane is ours; see the note at the top of this page for how those upgrades run today.) - Then one worker pool at a time. The agent sets the target kubelet version on one pool’s MachineDeployment and waits for that roll to finish before it starts the next one. Workers never outrun the control plane.
- Your machine-controller does the node work. kubehz changes one field on one resource. Your cluster’s own machine-controller replaces the machines from there: it drains each node and creates the replacement server in your Hetzner account, with credentials kubehz never holds.
- Progress is observed, not assumed. Each pool reports back as
v1.34.3 → v1.35.1 (2/5), read from the Machine objects in your cluster.
What an upgrade does not do
Worth stating plainly, because managed offerings often imply otherwise:
- No automatic rollback. If a pool fails to roll, the upgrade stops: that pool is reported failed, the pools behind it stay queued, and the agent retries on its next poll. Nothing is reverted for you: a replaced node is a replaced node. You decide the next move (and we will help if you ask).
- No removed-API scan. kubehz does not read your workloads, so it cannot warn you that something still calls an API your target release drops. Run that check yourself before you upgrade.
- No etcd or node-readiness gate. The control-plane version comparison above is the only pre-flight check.
- No SSH and no node access. The agent patches Kubernetes objects in your cluster and does nothing else: it holds no cloud credential, no SSH key, and no kubeconfig of yours.
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
- LIVE Version reporting (which version each registered cluster runs), via the heartbeat agent; you can see it in the dashboard.
- LIVE The managed tier itself (Supporter+): healing policies, capacity watches, and desired-state management from the dashboard.
- ROLLING OUT The kubehz-driven one-click upgrade flow, 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
- Pricing: the Supporter tier that unlocks the managed features
Doc status
| Aspect | Detail |
|---|---|
| State | Version reporting and the managed tier live; kubehz-driven one-click upgrades rolling out |
| Last reviewed | 17 July 2026 |