Flatcar vs Talos vs bootc: Picking the Immutable Node OS for a CAPH-Provisioned Hetzner Fleet

Microsoft spent six months proving that a managed Kubernetes vendor can ship Flatcar node images — then retired the preview. In January 2026, Flatcar Container Linux arrived on AKS as a preview node-pool OS; by June 8, AKS blocked new Flatcar pools and stopped security patches, and on September 8 it deleted the node images outright, breaking scale and reimage operations for anyone still on them.

If you run your fleet on someone else's managed images, your node OS is a deprecation notice away from a forced migration. If you run your own Cluster API fleet on Hetzner machines you own, the node OS is your decision — and it's one of the stickiest decisions you'll make, because the machine-image pipeline, the update automation, and the runbooks all weld themselves to it.

So: Flatcar, Talos, or bootc for a CAPH-provisioned fleet? Here is the verdict up front, with the receipts below.

TL;DR: the verdict in one table​

The default pick for a cost-sized CAPH fleet is Flatcar. It slots into CAPH's kubeadm-based provisioning today with the least custom machinery, and Nebraska gives you controlled, server-driven reboots without building an update controller.

Choose Talos if your threat model justifies owning a non-upstream CAPH integration path. Choose bootc only if you're deliberately buying into image-based OS management ahead of the ecosystem. Decide at three nodes, not thirty — every machine after the first amortizes the pipeline you built and raises the cost of switching.

Why immutable at all on cost-sized nodes​

The alternative isn't terrible: stock Ubuntu, cloud-init, kubeadm, unattended-upgrades. CAPH even supports it directly — point a machine template at a stock image, install prerequisites through cloud-init, join the cluster. For one node, that's fine.

The tax arrives with the second and third node. Mutable nodes drift: one got a manual apt install during an incident, one rebooted for a kernel update last Tuesday and one didn't, and now the same pod spec schedules differently depending on which machine it lands on. On a fleet sized for cost — few nodes, tightly bin-packed tenants — there is no spare capacity to absorb a node that behaves differently from its siblings. Debugging "works on node A, fails on node B" on a three-node fleet costs the same engineer-hours as on a thirty-node fleet, but it's a much larger share of your total ops budget.

Immutable node OSes convert that whole class of problem into a build-time concern. The node boots from a versioned artifact, its root filesystem can't be mutated at runtime, and an update means moving to a new artifact version — never patching in place. Rollback is "boot the previous artifact," not "figure out what changed." All three contenders here agree on that model. They differ in what the artifact is, who builds it, and how it reaches your Hetzner machines through Cluster API.

Flatcar: the boring classic​

Flatcar is the direct CoreOS Container Linux successor: a minimal, container-optimized distro with a read-only /usr, no package manager at runtime, and containerd shipped in the image. It joined the CNCF as an Incubating project in August 2024, and its release train is active — Stable 4459.x, Beta 4593.x, Alpha 4628.x through the first quarter of 2026.

Provisioning input is an Ignition config: JSON injected before first boot that declares users, SSH keys, systemd units, and files. Updates are atomic A/B-partition swaps driven by the node's update agent, with reboot policy controlled server-side by Nebraska, Flatcar's open-source update server. You point the fleet at your Nebraska instance and decide there which version each group tracks and when reboots are allowed — maintenance windows without SSHing anywhere.

The CAPH fit is the strongest of the three, because Flatcar is a kubeadm-model OS. CAPH's documented contract is simple: the OS image must already contain a container runtime, kubelet, and kubeadm, with reference images available through kubernetes-sigs/image-builder — or you install prerequisites via custom scripts in the kubeadm config. Flatcar satisfies this through the standard image-builder path, and on Hetzner Robot bare metal, the installimage flow CAPH uses already speaks the language of scripted base-OS installs that Flatcar's Ignition provisioning complements. Nothing about the control-plane or bootstrap provider needs to change: CABPK and KCP work exactly as they do on Ubuntu.

The honest caveat is the AKS story. Flatcar's AKS preview lasted roughly five months before Microsoft retired it, directing users to Azure Linux. That stings as a lost validation datapoint — but read it correctly. Microsoft retired a managed preview it had to maintain node images for, in favor of its own distro.

It says nothing about Flatcar the CNCF project, which keeps shipping releases and keeps its Cluster API integration (called out explicitly in its incubation proposal). For a self-hosted fleet, the lesson cuts the other way: depending on a vendor's managed node images means depending on the vendor's distro strategy. Owning the image pipeline on your own hardware is precisely what insulates you from someone else's June 8 retirement notice.

Talos: the API-only purist​

Talos takes immutability further than anyone else: there is no SSH, no shell, no console login, no package manager. Every operation goes through a gRPC API (port 50000) driven by talosctl or a controller. The machine config is a single declarative document; the same secrets plus the same config always produce the same node. If Flatcar's pitch is "a minimal Linux that runs containers well," Talos's pitch is "there is no Linux to log into — there is only the Kubernetes API and the Talos API."

The image story is the Talos Image Factory at factory.talos.dev. You define a schematic — Talos version, system extensions (drivers, extra binaries), kernel args, overlay — and the Factory produces versioned installer images. The Cluster API integration is the community-owned CABPT bootstrap provider plus the CACPPT control-plane provider: you declare talosVersion and an imageFactory schematic on the TalosConfigTemplate, and CABPT registers the schematic, pins the resolved patch version in status, and renders the install image.

Recent work (mid-2026) added in-place upgrades through CAPI's UpdateMachine path, so a version bump rolls the node to the new image without replacing the Machine object. Upgrades reboot the node — there's no way around a kernel swap — but the flow is declarative and GitOps-friendly end to end.

Here is the friction, and it's CAPH-specific, not Talos-specific. Upstream CAPH (the syself provider) is built around the kubeadm model: on Robot bare metal it provisions via rescue SSH plus installimage plus cloud-init, and it assumes an SSH-capable, cloud-init-capable OS throughout. Talos speaks neither SSH nor cloud-init.

On Hetzner Cloud, the working path is Talos snapshots (the hcloud-talos tooling builds Talos images as Hetzner snapshots for x86 and ARM) combined with a CAPH fork carrying a hcloud-talos flavor, or a separate Talos-native provider for Robot bare metal that writes the raw image over rescue SSH and then switches to the Talos gRPC API. Sidero Metal exists as the canonical bare-metal Talos provider, but that's a different infrastructure provider, not CAPH.

None of this is disqualifying — production Talos fleets on Hetzner exist — but it changes the shape of the commitment. With Flatcar you adopt an OS; with Talos-on-CAPH you adopt an OS plus a non-upstream provisioning path you must track across CAPH releases. For a team whose threat model genuinely benefits from "no shell exists to break into," that's a fair trade. For a team that just wants immutable nodes, it's integration surface you pay for without using most of it.

bootc: the Containerfile future​

bootc (bootable containers) is the newest model: the OS is an OCI container image, built from a Containerfile, with transactional in-place updates via bootc upgrade and atomic rollback to the previous image. Base images ship for Fedora, CentOS Stream, and RHEL, and the pitch resonates immediately with anyone who already thinks in container workflows — your node OS gets the same build, sign, scan, and promote pipeline as your application images. No separate image-builder toolchain, no Ignition transpiler, no schematic service: podman build, push to a registry, bootc upgrade.

For Kubernetes nodes specifically, the ecosystem is young but real. The ucore-k8s project ships a bootable Fedora-based image with kubelet, kubeadm, kubectl, and CRI-O baked in. Fedora's Hummingbird effort produces bootc images with upstream kubeadm Kubernetes for KVM. The pattern works: bake the kubeadm prerequisites into the Containerfile, and CAPH's image contract (runtime + kubelet + kubeadm present) is satisfied by construction.

What's missing is everything around the image. There is no CAPI-native bootc story — no bootstrap provider that renders bootc configs, no control-plane provider, no standardized UpdateMachine path. Update orchestration across a fleet (drain, upgrade, reboot, verify, next) is yours to build, likely as MachineDeployment rolling replacements driven by image-tag swaps, with your own controller or pipeline deciding when a new tag is safe to roll.

Nebraska-equivalent fleet policy doesn't exist yet; you get the registry's tagging plus whatever automation you write. And while the "OS as OCI image" supply chain is genuinely attractive — Cosign signatures, registry mirroring, air-gapped pulls — you inherit the responsibility for base-image freshness that Flatcar's release train and Talos's Factory currently handle for you.

bootc is the right answer if you're deliberately investing ahead of the ecosystem: you want one artifact pipeline for OS and apps, you're comfortable writing the fleet-update automation, and you believe CAPI-native support will arrive while your fleet is still small enough to absorb the migration. It's the wrong answer if you want the OS choice to reduce your automation backlog this quarter.

Head-to-head: image pipeline and update semantics​

This is the table the title promised — what each OS concretely demands of a CAPH fleet, read for a three-node starter cluster where every hour of platform work competes with product work:

Two rows deserve emphasis. First, reboot coordination is where "immutable" meets "my tenants have uptime." Flatcar answers it with a shipped product (Nebraska). Talos answers it with the CAPI machinery you're already running. bootc answers it with a blank page and your own engineering time.

Second, CAPH integration maturity compounds: every upstream CAPH release is tested against the kubeadm path Flatcar and bootc ride, while the Talos path needs its fork or alternate provider re-validated each time. On a fleet sized for cost, that re-validation is a recurring tax with no tenant-visible return.

The pick, and when to revisit it​

Standardize on Flatcar for a CAPH-provisioned Hetzner fleet today. It is the only option of the three that is simultaneously immutable, upstream-compatible with CAPH's kubeadm model, and shipped with fleet reboot policy — which means it's the only one that reduces your automation backlog instead of adding to it. Run your own Nebraska instance, template your Ignition configs, and spend the engineering time you saved on tenant-facing surface: build times, preview environments, observability.

Revisit the decision on two triggers, not on a calendar. If your threat model hardens — untrusted tenant code sharing nodes, compliance pressure for minimal attack surface — Talos's no-shell posture justifies the integration cost, and by then the CABPT/CACPPT in-place update path will be more mature than it is today. If bootc gains a CAPI-native story — a bootstrap provider and a fleet-update convention — its Containerfile pipeline becomes the cheapest long-term answer for teams already living in OCI registries, and migrating three to ten nodes from Flatcar to bootc is a weekend, not a quarter.

The deeper point is about when you decide, not just what. At three nodes, the OS choice is a machine template and a wiki page. At thirty, it's a snapshot pipeline, a Nebraska deployment or Factory account, reboot runbooks, monitoring for update failures, and every operator's muscle memory. The switching cost grows roughly with the fleet, while the benefit of switching stays roughly constant — so the rational move is to pick the boring default now and let the triggers, not the hype cycle, move you off it.

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.