Maintenance & upgrades
Every cluster has a maintenance window, and most of what the platform changes on its own happens inside it. This page says what that is, what you control, and what it does to your nodes.
The window
Section titled “The window”You pick a window of at least 30 minutes when you create the cluster; if you don’t, the platform assigns one at night and shows it as “assigned”. You can move it at any time. Inside the window:
- Kubernetes patch updates and worker image updates are applied, if the automatic switches are on (they are by default; you can turn either off).
- Control-plane components are restarted preventively and etcd is defragmented.
- Changes you made with “apply in the maintenance window” are rolled out.
Nothing else waits for the window. A change you make in the console applies immediately unless you ask it to wait.
What updates automatically
Section titled “What updates automatically”| What | When | Rolls nodes? |
|---|---|---|
| Kubernetes patch version (1.36.3 → 1.36.4) | next window, if auto-update is on | yes, one node at a time |
| Worker OS image | next window, if auto-update is on | yes |
| Control-plane components, security fixes to the platform | with every platform release, no action needed | no |
| Expired Kubernetes minor version | forced at the next window once a version reaches end of life; you are warned in the console beforehand | yes |
| A Kubernetes minor version you pick (1.35 → 1.36) | when you change it; upgrades only, never downgrades | yes |
What rolls a node, and how
Section titled “What rolls a node, and how”A node roll replaces or rebuilds every node of a pool, one at a time, respecting your PodDisruptionBudgets. The two kinds of pool behave differently:
- On-demand nodes are replaced: a new server is ordered at current Hetzner prices, the old one is drained and deleted. You set how many can be surging or unavailable at once.
- Adopted servers are rebuilt in place: the same server gets a fresh OS and rejoins. Nothing is deleted, so the grandfathered price survives every upgrade. Rolls go one server at a time.
Changing these settings rolls nodes: the Kubernetes version, the worker image, the machine type, kubelet settings, labels and taints, sysctls, and the private-or-public setting of a pool. Changing the pool size, the maintenance window, the hibernation schedule or your identity provider does not.
Maintenance you trigger
Section titled “Maintenance you trigger”From the cluster page or the API you can run maintenance now, reconcile (re-apply the cluster’s definition) and retry a failed operation. On private clusters you can also replace the NAT gateway ahead of its window.
Certificates and keys
Section titled “Certificates and keys”The cluster’s certificate authority, the service-account signing key, the etcd encryption key and the SSH key rotate on schedule or on request; you never handle them. The console shows the rotation state. A certificate that would expire within a year is flagged as a warning long before it matters.
Versions offered
Section titled “Versions offered”New clusters offer the two current upstream minor versions, 1.36 and 1.35 (as of 2026-09-06). A version that is about to expire is marked in the composer with its date. A test cluster and a production cluster get the same versions.