SNCF Rebuilt Its Cloud-Native Platform on Cluster API — Here's What Changed

Every self-hosted Kubernetes horror story starts the same way: a "snowflake" cluster nobody fully understands, provisioned by hand months ago, that takes a full engineering month to replicate when you need a second one. That was SNCF's reality until recently — France's national railway operator, responsible for real-time positioning and status data on 4,000 to 5,000 trains a day, was adding on-premises clusters at a rate of roughly three a year. On March 25, 2026, at KubeCon + CloudNativeCon Europe, CNCF gave SNCF its Top End User Award and published a case study naming Cluster API as the architectural core of the rebuild that changed that math. CNCF is also moving that award to an annual cadence going forward instead of the previous every-other-year schedule — a small signal that the committee wants "here's what a rigorous production adopter actually did" case studies surfacing more often, not less. This one is worth taking seriously as evidence, not just as a nice logo for the project's homepage: it's one of the highest-stakes production deployments Cluster API has publicly claimed outside a cloud vendor's own reference architecture.

The Before/After Numbers​

Here's what actually changed, according to CNCF's case study and a companion write-up from Sidero Labs (maker of Talos Linux, the OS SNCF standardized on):

Those numbers come from Yann Rotilio (Senior Staff Engineer, Kubernetes Specialist) and Thomas Comtet (Head of Container and Cloud Native Platforms), the two engineers CNCF quotes directly. Rotilio's framing of the autoscaling change is the line worth sitting with: Cluster API "gave us node autoscaling in our datacenters — something we thought was only possible with AKS or EKS." That's the whole thesis of the rebuild in one sentence — capabilities that used to be a managed-cloud exclusive, running on hardware SNCF owns.

The fleet SNCF is managing isn't small, either: around 200 Kubernetes clusters total, spanning AWS, Azure, and on-premises, supporting roughly 400 internal IT projects. The on-prem slice — the part built on Cluster API — is where all of the numbers above apply.

The Stack Underneath the Numbers​

CNCF's case study lays out a specific, opinionated stack, and each piece is doing a job the others can't:

• OpenStack (Canonical) — the IaaS layer, providing compute, networking, and storage primitives on SNCF-owned hardware.
• Talos Linux (Sidero Labs) — an API-driven, SSH-less, immutable OS. There's no shell to drift into misconfiguration; the entire machine is managed through a declarative API, and OS upgrades are atomic image swaps rather than in-place package updates.
• Cluster API (CAPI) — the lifecycle layer, and per CNCF, "the heart of the architecture." CAPI treats a Kubernetes cluster itself as a Kubernetes resource — a Cluster, a MachineDeployment — reconciled continuously against a declared desired state, the same control loop pattern that manages Pods and Deployments inside a cluster, one level up.
• Cilium (eBPF) — networking and observability, replacing whatever bespoke iptables/kube-proxy setup a hand-rolled VM cluster would have accumulated, with the same eBPF-based dataplane and flow visibility used across most large CNCF-member fleets.
• Kyverno — policy-as-code enforcement, relevant for an operator SNCF describes as working against a roughly 200-page internal security manifesto. Encoding that manifesto as ClusterPolicy objects means compliance is checked and enforced by the same reconciliation loop as everything else, instead of a separate audit process bolted on afterward.
• ArgoCD — GitOps delivery, so cluster and workload state stays reconciled from a git source of truth.
• ORAS — artifact management for the images and bundles the rest of the stack pulls.

Nothing in that list is exotic on its own — every piece is a well-known CNCF-ecosystem project. What's notable is CAPI's specific role: it's the piece binding OS-level immutability (Talos) to infrastructure provisioning (OpenStack) through one declarative object graph, instead of a pile of shell scripts and Ansible playbooks stitching the layers together by hand — treating five separately-maintained projects as one coherent, reconciled system rather than five tools glued together by tribal knowledge. That's exactly the pattern Bex.co's own CAPD vs. CAPH post describes at a much smaller scale: one Cluster API contract, pluggable infrastructure underneath.

Why the Second Attempt Worked​

The part CNCF's framing undersells is that this wasn't SNCF's first swing. Sidero Labs' companion case study notes SNCF had already spent roughly a year on a prior attempt built on Ubuntu and RKE2 — and it didn't work out. The team was back to hand-managed VM-based clusters, the same manual-config, configuration-drift, "snowflake" pattern the CNCF numbers describe as the starting point.

The difference the second time wasn't more headcount or a bigger budget — it was removing the two specific failure modes that sank attempt one. Manual OS configuration went away with Talos: there's no SSH session to leave a box in a state nobody documented. And ad hoc cluster lifecycle management went away with CAPI: a cluster's desired state — how many control-plane nodes, how many workers, which Kubernetes version — lives in a Cluster object that a controller continuously reconciles against, the same way a Deployment controller keeps replica count honest. Neither piece is a bigger hammer; they're both narrower, more mechanical tools that leave less room for a human to introduce drift.

Comtet's own summary of the outcome: "We don't need to ask legacy teams for modern Kubernetes. We've got our own out-of-the-box solution with Talos Linux and Kubernetes." The team also open-sourced talos-cockpit, a tool built to replicate cloud-style auto-upgrade behavior on-prem — evidence the fix generalizes past SNCF's specific environment rather than being a one-off workaround.

What This Actually Proves About Production Readiness​

CAPI hit its 1.0, "production-ready" milestone back in October 2021. Plenty has been written since then about Cluster API in production, but most of the reference points are cloud-vendor-adjacent or mid-sized platform teams. A national railway operator running real-time train positioning and public status data — the kind of system that answers for uptime in a way a hobby project or even a typical SaaS never has to — choosing CAPI over a managed offering, and getting a CNCF Top End User Award for it, is a meaningfully stronger data point.

It also cuts against a real 2026 industry narrative — the argument, repeated in plenty of Kubernetes-in-2026 retrospectives, that self-managed control planes on bare metal are a phase teams grow out of on the way to EKS/GKE/AKS. SNCF is a counter-example running at production stakes, not a toy.

That said, the honest caveat: SNCF is not a solo developer's Hetzner box. It's a national operator with an OpenStack support contract, a dedicated container-platform team, and a 200-page security manifesto driving requirements most side projects never encounter. A single-operator CAPI fleet — the kind running on CAPH against real Hetzner dedicated servers instead of an OpenStack private cloud — isn't going to reproduce SNCF's 200-cluster fleet or its Canonical support line.

But the specific properties that made the difference at SNCF aren't scale-dependent. A declarative Cluster/MachineDeployment object graph reconciles the same way whether it's managing 200 clusters or three nodes; an immutable, API-driven OS removes config drift at any fleet size. The lessons that transfer are architectural, not budgetary: zero-drift by construction, autoscaling as a property of the declarative layer rather than a cloud-vendor favor, and — the part that matters most for infrastructure meant to be operated by something other than a human — a reconciliation loop that's just as legible to an AI agent asking "is my fleet healthy" as it is to Rotilio's team asking the same question at 200x the scale.

That legibility is the throughline. The reason a self-hosted PaaS built on Cluster API can hand fleet operations to an agent at all is the same reason SNCF's incident count dropped 90%: the desired state is declared, not remembered, and a controller — human-written or agent-invoked — reconciles against it instead of running one-off commands against machines whose actual state nobody's fully sure of anymore.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, backed by the same Cluster API reconciliation model SNCF used to cut its own incident rate by 90%. Star the repo on GitHub or deploy your first app today.

Sources​

• SNCF | CNCF Case Studies
• France's national railway goes cloud native in four months — Sidero Labs
• CNCF Celebrates Innovators Advancing Cloud Native at KubeCon + CloudNativeCon Europe
• Keeping Sovereignty on Track: How France's National Railway Runs on Open Source — Superuser
• Kubernetes Cluster API reaches production readiness with version 1.0 — CNCF