The current list is always available from List Kubernetes Versions, and the upgrade targets for your cluster from Get cluster upgrades.
How versions are offered
Up to three Kubernetes minor versions are offered at a time. When a new upstream release ships, we validate it on our infrastructure before it appears in your dashboard. The oldest version is then retired on a schedule (see below). Creating a cluster on a version newer than the base image is supported: the cluster provisions and then upgrades itself to your chosen version before it is handed over — this is part of the normal 10–20 minute creation time. Within a minor version we offer one specific patch release (for example v1.34.10). When a newer patch is validated, it replaces the older one as the upgrade target for that line.In-place upgrades
Clusters upgrade in place from the dashboard (Settings → Kubernetes version), the API, or the CLI. Upgrades are rolling:- Control-plane nodes upgrade one at a time. On an HA cluster the Kubernetes API stays available throughout; on a single-master cluster the API is briefly interrupted while the master restarts.
- Workers are cordoned and drained before upgrading, one at a time. Workloads with more than one replica keep serving.
- Minor versions upgrade sequentially (1.33 → 1.34 → 1.35, no skipping). Patch upgrades within a minor are always allowed.
- Upgrades cannot be rolled back.
Automatic upgrades and maintenance windows
Each cluster has an upgrade mode:- Manual (default) — you start every upgrade yourself.
- Auto-patch — patch releases apply automatically inside your maintenance window, with a notice email about 72 hours before.
- Auto-minor — new minor versions also apply automatically, after a stability period following their release.