How SNCF Cut Kubernetes Cluster Provisioning From 30 Days to 30 Minutes With Cluster API

France's national railway runs 15,000 trains and moves 5 million passengers a day. Until recently, standing up a new Kubernetes cluster inside SNCF's own datacenters took a month — and in four years, the team had only ever shipped 14 of them. After rebuilding the platform around Cluster API, that same operation takes 30 minutes. In the six months following the rebuild, SNCF stood up 10 new clusters, and every cluster in the fleet — public cloud and on-prem alike — now gets reconciled back to its declared state monthly, automatically, with zero configuration drift.

That's not a vendor slide. It's SNCF's own case study, published by the CNCF after the company won the 2026 Top End User Award and presented the work at KubeCon EU in March. For a national railway operator — safety-critical, heavily regulated, running on infrastructure it has to answer for — the fact that "monthly, unattended, fleet-wide reconciliation" is now just how things work is the headline. Here's what SNCF actually built, and what it proves about owning the machines under a fleet instead of renting them.

The Fleet Before Cluster API​

SNCF's cloud program dates back to 2018. By the time the team decided to rebuild, they were running over 2,000 applications, roughly 70% of them on public cloud (Azure and AWS, spread across 200+ Kubernetes clusters) and the remaining 30% on-premises across SNCF's own datacenters. The public-cloud side was in reasonable shape. The on-prem side was not.

Provisioning a new cluster in an SNCF datacenter took about 30 days — enough friction that in four years, the team had only ever deployed 14 clusters total. Each one had been built and patched by hand: SSH sessions, manual config changes, no consistent baseline between clusters. The result was a fleet of what Yann Rotilio, SNCF's Senior Staff Engineer, called "snowflake" clusters — no two configured quite the same way, drifting further from each other with every ad hoc fix. And the on-prem side was missing a capability the public-cloud side took for granted: node autoscaling. Scaling a datacenter cluster up or down was a manual, ticket-driven process, something AKS and EKS had solved for years but that stayed out of reach on SNCF's own hardware.

Rotilio put the decision in blunt terms: "Applying incremental fixes on unsteady foundations would prove time-consuming without guarantee of resolution. We needed to start entirely fresh."

The Stack SNCF Rebuilt On​

"Fresh" meant standardizing the on-prem stack around a small set of declarative, API-driven primitives instead of scripts and SSH:

The load-bearing piece is Cluster API itself. Instead of a human (or a Terraform script run by a human) issuing one-off commands to build a cluster, CAPI represents a cluster's desired state as a Kubernetes object and runs a controller that continuously reconciles reality toward it. That's the same control-loop model Kubernetes uses for pods and deployments, pointed at the clusters themselves — clusters become just another resource the platform manages declaratively, on OpenStack in SNCF's own datacenters the same way CAPI's AWS or Azure providers would do it in the public cloud.

What "Monthly, Zero-Drift" Actually Means​

The number that stands out isn't the 30-minute provisioning time by itself — plenty of platforms can provision fast once. It's that every cluster in the fleet gets reconciled monthly, unattended, back to its declared desired state. Not "we can patch a cluster if someone remembers to." Every cluster, every month, automatically, with no drift accumulating in between.

That's a direct consequence of the architecture, not a separate process bolted on top. Because CAPI already treats a cluster's spec as the source of truth and continuously reconciles toward it, "update the fleet" isn't a distinct operational task with its own tooling and schedule — it's the same reconciliation loop that provisions a cluster in the first place, just running on a cadence. Thomas Comtet, SNCF's Head of Container and Cloud Native Platforms, summed up the ambition plainly: "We built a platform competing with AKS/EKS within our own infrastructure." Node autoscaling — previously a public-cloud-only feature — came along with the same CAPI OpenStack provider, for the same reason: it's a controller reconciling machine count to demand, and once the reconciliation primitive exists, autoscaling on-prem isn't a special case anymore.

For a safety-critical operator, "zero configuration drift" isn't a nice-to-have metric — it's the difference between every cluster in the fleet running audited, known-good configuration and a subset of them quietly diverging until an incident finds out the hard way.

What It Proves About Owning the Machines​

SNCF's case study is a useful data point for anyone weighing a self-hosted, Cluster-API-managed fleet against a hosted PaaS or managed Kubernetes: at genuinely large scale — over 200 clusters, a national safety-critical workload, a company that can't afford "it usually works" — reconciliation-first fleet management isn't a compromise you accept for the privilege of owning your hardware. It's the same operational posture managed platforms sell as their differentiator, minus the vendor.

Three things carry over directly to a smaller self-hosted fleet:

• Declarative reconciliation beats imperative scripts at any scale. The gap between "1 cluster a month, by hand" and "10 clusters in 6 months, unattended" isn't really about automation effort — it's the difference between a script that runs once and a controller that keeps running. A fleet managed by CAPI (or, for application deployments rather than cluster lifecycle, by Cluster API-adjacent tooling like Cluster API Provider Hetzner) inherits the same "always converging to desired state" property SNCF built for cluster provisioning.
• On-prem autoscaling isn't exclusive to hyperscalers anymore. SNCF's result confirms that node autoscaling is a property of the reconciliation controller, not of the cloud it runs against — a fleet on owned hardware doesn't have to give up elastic capacity to avoid a hyperscaler bill.
• Provider and dependency lifecycle should ride the same rails as application deployment. Managing CAPI's own providers as OCI artifacts through ORAS means a provider upgrade isn't a special manual event — it flows through the same registry-based pipeline as every other artifact. That's the same principle behind treating a deploy target itself — build image, running service, TLS cert — as one reconciled state instead of a pile of manual steps.

Bex.co builds on that same Cluster API foundation — push a git repo, get a running HTTPS service on machines you own, reconciled the same way SNCF reconciles its cluster fleet. Star the repo on GitHub or deploy your first app today.

Where This Goes Next​

SNCF's monthly cadence is itself a snapshot of where Cluster API was as of early 2026 — and the project is actively closing the gap between "reconcile monthly" and "reconcile continuously." Cluster API 1.12 shipped in-place updates and chained upgrades, letting a controller step a machine through a version upgrade without the tear-down-and-replace cycle earlier CAPI releases required. That matters for exactly the workload SNCF is running: a safety-critical fleet where "replace every node to apply a patch" carries real operational risk, versus a controller that can converge a running machine to a new spec directly.

The broader trend points the same direction. Multi-cluster fleets spanning public cloud, private datacenters, and edge sites are becoming the default shape of enterprise Kubernetes footprints in 2026, and CAPI maintainers have said explicitly that resiliency and scalability improvements are aimed at making fleet-scale reconciliation accessible to teams that aren't running a dedicated platform-engineering org. SNCF had to build its own answer to "how do we manage 200+ clusters without 200+ sets of manual runbooks." The direction of travel is that fewer teams will have to build that answer from scratch.

The Takeaway​

The platform-engineering pitch for "own the machines" has always had to answer one objection: managed platforms are the easy button, and self-hosting means trading convenience for control. SNCF's numbers are a direct rebuttal, at a scale most self-hosted platforms will never need to hit. Thirty days to thirty minutes. Fourteen clusters in four years to ten in six months. Zero drift, monthly, across a fleet that has to keep 15,000 trains a day running. That's not what "harder but more independent" looks like — it's what a reconciliation loop, applied consistently, buys anyone willing to build on it.