Cluster API v1.12: Update the Node, Don't Replace It — What In-Place Updates and Chained Upgrades Buy a Hetzner Fleet on Talos

Rotating one SSH credential used to mean rebuilding every machine in your fleet. Cluster API v1.12, announced by Fabrizio Pandini on February 9, 2026, finally retires that deal for the easy half of fleet operations: change the Machine spec and the controllers now pick the least disruptive way to converge — an in-place update when the workload need never notice, a rollout when it would be disrupted anyway. And if you have fallen three Kubernetes minors behind, you can now declare the destination version once and let Cluster API walk the chain of intermediate upgrades itself.

That is a quality-of-life improvement on elastic cloud capacity, where a replacement VM costs pennies and sixty seconds. On a bare-metal Hetzner fleet running Talos, where every replacement machine is a monthly-billed dedicated server going through a rescue-system reinstall measured in minutes, not seconds, it is a structural cost change. Here is the payoff up front, before the mechanism:

One caveat before we go further, because the motto oversells itself: the bulldozer survives. In-place updates cover the changes that do not need a drain or a restart; everything else still goes through create-and-delete. The honest summary is that v1.12 ends bulldoze-and-rebuild for the easy half — which, on owned hardware, happens to be the half you pay for most often. The boundary gets its own section at the end.

The old rule, and what just changed​

Since the beginning, Cluster API treated a Machine the way Kubernetes treats a Pod: immutable. When the spec changed, the controllers performed a rollout — create a new Machine, drain the old node, delete the old Machine — using only the two primitives create and delete. Pandini's release post is explicit about why that design won: it is simple to explain, it needs no knowledge of the OS or bootstrap mechanism on the machine, and it collapses the entire lifecycle of a host server into two operations.

The project had already been sanding down the sharp edges of that model. Earlier releases added in-place propagation for changes that touch Kubernetes objects only, tainting of outdated nodes with PreferNoSchedule to cut pod churn during rollouts, and a delete-first rollout strategy aimed squarely at bare metal and other capacity-constrained environments where you cannot always afford a shiny spare machine sitting next to the old one. v1.12 is the next step on that road, and the biggest one: real in-place updates plus chained upgrades, both reached through the same gesture operators already know — edit the desired state and let the controllers reconcile.

The usability story matters as much as the mechanism. You change the Cluster or Machine spec exactly as in previous releases, and Cluster API decides whether an in-place update or a chained upgrade applies, and executes it. No new CLI ritual, no separate upgrade planner to learn.

In-place updates: update the node, don't replace it​

The new capability arrives as update extensions delivered through the Runtime SDK. Both KubeadmControlPlane and MachineDeployment understand them, which moves the boundary of what Cluster API can do without deleting a Machine in a significant way.

The mental model is a choice, not a replacement. Once you change the desired state of your Machines, Cluster API picks the best tool for that specific change: the classic immutable rollout, or an in-place update extension. Pandini frames it plainly — this is not rollouts versus in-place updates; both are valid options and the controller selects the appropriate one per change.

The maintainers also give clear guidance on where the sweet spot is. In-place updates are most useful for changes that would not otherwise require a node drain or a pod restart. The canonical example is changing user credentials on the Machine; a registry certificate rotation is the same shape of change. When the workload is going to be disrupted anyway — a kubelet bump that restarts everything, an OS change — the advice is to just do the rollout and keep the simplicity and predictability of create-and-delete.

And because Cluster API stays true to its extensible nature, the sweet spot is a default, not a cage. Anyone can write their own update extension and decide when and how to use in-place updates, trading away some of immutability's benefits deliberately. Pandini's own example is wiring the decision to an autoscaler such as Karpenter — the extension mechanism is open-ended by design. For the full deep dive, the maintainers point to their KubeCon EU session in Amsterdam, "In-place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure."

Note the parallel the release draws with Kubernetes itself: just as Kubernetes 1.35 graduated in-place Pod resizing so containers stop restarting for resource tweaks, Cluster API v1.12 brings the same logic one layer down, to the servers. Both projects are converging on the same lesson — minimize workload disruption wherever the change allows it, keep the immutable path where it does not.

Chained upgrades: declare the destination, skip the layovers​

The second feature targets a different pain: version drift caused by upgrade tedium. Teams fall behind on Kubernetes minors not because they do not care, but because each hop used to be its own carefully babysat operation. ClusterClass and managed topologies already gave platform teams a framework for Kubernetes-as-a-service; v1.12 extends it so a cluster can move more than one minor version in a single operation.

The flow is deliberately boring from the operator's side. You change the desired Kubernetes version on the Cluster — say from v1.33 straight to v1.35 — and Cluster API computes an upgrade plan and starts executing it. Executing the plan means upgrading control-plane and worker machines in a strictly controlled order, repeating as many times as needed to reach the desired state. Instead of stepping v1.33.0 → v1.34.0 → v1.35.0 yourself and checking progress at each landing, you declare v1.35.0 and supervise one operation.

Worker machines get an additional optimization: they skip upgrades to intermediate minors whenever the Kubernetes version-skew policy allows it, so the most numerous machines in the fleet take the shortest legal path. Extensibility is built in here too — upgrade-plan runtime extensions can influence how the plan is computed, and lifecycle hooks can automate the chores that must happen mid-upgrade, such as bumping an addon once the control plane has moved.

Pandini names the target user plainly: teams that want to upgrade once a year and jump three minors (n-3 → n) instead of running the treadmill quarterly. But the release post carries a warning worth quoting back at anyone tempted to treat this as permission to coast: the fact that you can now easily upgrade by more than one minor version is not an excuse to stop patching frequently. Chained upgrades compress the mechanical cost of catching up; they do nothing about the CVE window you sat in while drifting.

What this buys a Hetzner bare-metal fleet on Talos​

Now the fleet-level math, because this is where "nice feature" becomes "budget line." On AWS or GCP, a replacement Machine is an API call that resolves in about a minute and bills by the second — the old always-rollout rule was wasteful the way leaving a light on is wasteful.

On Hetzner dedicated hardware, a replacement Machine is a monthly-billed physical server provisioned through the Robot API: rescue system, OS image install, reboot into the new node, on the order of ten minutes per machine even when everything goes right, with no elastic pool of spare capacity to absorb the churn. The syself cluster-api-provider-hetzner (CAPH) flow for bare metal — HetznerBareMetalHost objects moving through image install and provisioning — works, but every avoidable pass through it costs real time on hardware you already pay for whether it serves traffic or sits in reinstall.

Count what v1.12 removes from a year of fleet operations against that background. Every credential rotation, every certificate update, every machine-detail tweak that previously forced a full replace-and-drain cycle across the fleet now converges without touching the Robot API at all. And the annual Kubernetes upgrade — the operation small teams dread most — collapses from three sequenced minor upgrades, each with its own drain-and-replace wave across physical servers, into one declared target version with workers skipping intermediate stops. For a team running a handful of Hetzner machines with no spare capacity and no dedicated platform engineer, that is the difference between "we stay current" and "we are two minors behind and afraid to start."

The Talos half of the story​

Talos deserves its own beat here, because an API-driven OS is the natural backend for in-place updates. Talos Linux has no SSH and no shell-based snowflake drift; every change arrives as an API call carrying machine configuration. Under Cluster API, the Talos fleet is managed through the familiar provider pair — the bootstrap provider (CABPT) generating machine configuration into TalosConfig resources, and the control-plane provider (CACPT) — so the fields an in-place extension would need to touch are already declarative data, not imperative runbooks.

Mapping Talos operations onto the v1.12 split looks like this: machine-config patches, Talos version upgrades delivered through its image-based upgrade path, and certificate or credential rotations issued over the Talos API are exactly the no-drain-shaped changes in-place updates were built for. What still replaces the Machine is everything below that line — the server type in the CAPH spec, the install image the dedicated server boots from, any provider-level change that alters what the physical machine is rather than what it runs. The OS layer and the CAPI layer finally agree on the same distinction: mutate the configuration, replace the hardware definition.

What still requires a full Machine replacement​

Time to collect the bulldozer's remaining territory in one place, so nobody adopts v1.12 expecting magic:

• Infrastructure-shape changes. A different Hetzner server type, different disks or networking, a different install image — anything that changes the physical machine rather than its configuration — still means a new Machine and the classic rollout.
• Changes that disrupt the workload anyway. If the node must drain and pods must restart regardless, the maintainers' guidance is explicit: take the rollout. In-place machinery buys nothing when disruption is unavoidable, and it costs you the rollout's simplicity.
• Unhealthy machines. Automatic remediation via MachineHealthCheck still works the immutable way — create a pristine replacement, delete the failed Machine. A node that has been NotReady for five minutes is not a candidate for a gentle in-place patch; it is a candidate for replacement.
• Changes with no covering extension. In-place updates only exist where somebody wrote an update extension that understands the change. Until your providers and your own extensions cover an operation, it rolls out the old way.

The operator's decision rule fits in one paragraph: if the change touches what the machine is (hardware, image, provider spec) or the node is unhealthy, replace it; if the change touches what the machine runs or holds (credentials, certificates, configuration, Kubernetes version) and an extension covers it, let v1.12 converge in place or chain the upgrades. When in doubt, the rollout remains the safe default — it is the same two primitives that have carried every Cluster API fleet since the beginning.

Declarative reconciliation grows up​

Step back and v1.12 reads as a maturation point, not just a feature release. Pandini's follow-up essay on immutability in March 2026 makes the philosophy explicit: adopters increasingly care less about immutability of any single node and more about immutable principles applied to operating a whole fleet — speed through trusted clones, scale without snowflakes, a bounded complexity budget. In-place updates and chained upgrades are what that philosophy looks like once a project is confident enough to relax a tenet without abandoning it: keep create-and-delete as the foundation, and let controllers choose the gentler tool exactly where the change allows.

For the self-hosted world this lands hardest. A platform running its fleet on owned Hetzner machines with Talos just got fewer Robot reinstalls, fewer drain waves, and a credible once-a-year upgrade story — all by editing the same specs it already edits. Declarative management was always the promise; v1.12 is the release where the reconciliation loop stops bulldozing the house to change the locks.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.