Metal3 Enters CNCF Incubation: What the Bare-Metal Provisioning Layer Actually Changes for a Cluster API Fleet Not Already Running It

Metal3 crossed from CNCF Sandbox to Incubating on August 27, 2025 — and eight months later, at KubeCon + CloudNativeCon Europe 2026, the CNCF blog was still introducing it as its "freshly incubated bare metal project." The badge is real. The interesting question is narrower than the badge: if you're already running a Cluster API fleet on a single cloud-shaped bare-metal provider — Hetzner, in bex's case — does Metal3's graduation actually change anything for you?

The honest answer up front: not if your fleet is 100% Hetzner-owned or Hetzner-leased hardware. Something does change the day it isn't — the day a colo box, a secondhand Dell or Supermicro server, or a second bare-metal vendor with its own BMC enters the picture. That's the specific line this piece draws, and it comes down to one architectural fact: Metal3 provisions through a machine's BMC over Redfish or IPMI, vendor-agnostic by design, while a Hetzner-specific Cluster API provider provisions through Hetzner's own API — fast and simple, but only for Hetzner iron.

What Actually Happened, With the Numbers​

Metal3 joined the CNCF as a Sandbox project in September 2020. The CNCF's Technical Oversight Committee voted to move it to Incubating status on August 27, 2025, the maturity tier that requires evidence of multi-organization contribution, a documented governance process, and real adoption — not just a working prototype.

The project's own numbers at incubation, per its CNCF announcement:

Fujitsu, Ikea, SUSE, Ericsson, and Red Hat are named as production adopters. That's a meaningfully different signal than a project with a handful of maintainers and no committers outside the founding vendor — the exact thing CNCF's incubation bar is designed to filter for.

By KubeCon EU 2026 in Amsterdam (March 23–26), Metal3 had a full conference presence: a lightning talk, a dedicated session on "Metal3.io's Path to CNCF Incubation: Governance, Processes, Community," a kiosk, and — the part actually worth reading — a real-world adoption case study from Project Sylva, titled "Beyond the Cloud: Managing Bare Metal the Kubernetes Way Using Metal3.io." Sylva is the open-source telco cloud stack originally launched by Orange, Deutsche Telekom, Vodafone, Telefónica, and TIM alongside network-function vendors Ericsson and Nokia, and it has since picked up contributors including Telus, Free, NTT, BT, AWS, and NVIDIA. Sylva runs Metal3 as its bare-metal layer specifically because telco operators don't get to standardize on one hardware vendor's API the way a single-cloud team can — a CNF platform has to roll out consistently across whatever mix of Dell, HPE, and white-box servers a given operator's data centers already contain. That's exactly the constraint that makes Metal3's architecture worth understanding on its own terms before asking whether it fits a Hetzner-only fleet.

How Metal3 Actually Provisions a Node​

Metal3's core object is the BareMetalHost (BMH) custom resource, reconciled by the BareMetal Operator (BMO), which exposes a subset of Ironic's bare-metal lifecycle management through the Kubernetes API. Ironic itself is the OpenStack-born bare-metal provisioner that Metal3 adopted as its backend rather than reinventing.

The only thing Ironic needs to take over a physical machine is the address of its BMC (baseboard management controller), its credentials, and the protocol it speaks — almost always Redfish or IPMI, the two standard hardware-management interfaces that Dell, HPE, Supermicro, Fujitsu, and effectively every server vendor that ships a BMC already implements. Ironic uses that connection to power the machine on and off, set its next boot device, and drive an OS image onto disk — all before Kubernetes itself is running on the node. Cluster API Provider Metal3 (CAPM3) then wires a BareMetalHost into a standard Cluster API Machine, so a Metal3-backed node looks like any other Cluster API–managed machine to the rest of the fleet.

The practical consequence: Metal3 doesn't care whose logo is on the chassis. If it has BMC access and Redfish or IPMI, it can provision it — a Dell PowerEdge in a colo cage, a stack of used Supermicro boards, an OVHcloud or Netcup dedicated box that exposes IPMI. That vendor-agnostic reach is the entire point of the architecture, and it's also the entire cost of it: someone has to run Ironic, and someone has to get BMC network access right, since a compromised BMC is a compromised machine below the OS.

Why CAPH Doesn't Need Any of That​

bex's fleet runs on the Cluster API Provider Hetzner (CAPH), which takes a structurally different path. CAPH provisions Hetzner Cloud VMs as HCloudMachine objects and Hetzner dedicated servers as HetznerBareMetalHost objects — but in both cases, it drives the machine through Hetzner's own Cloud/Robot API plus SSH and cloud-init, not through a BMC speaking Redfish or IPMI.

That's not a missing feature; it's the correct simplification for the problem CAPH actually has. Hetzner controls both the rack and the API, so CAPH gets to skip the entire BMC layer — no Ironic to run, no out-of-band management network to secure, no vendor-hardware compatibility matrix to maintain. It's a smaller, easier-to-operate provider precisely because it only has to speak to one vendor's API instead of every BMC dialect Ironic supports.

The trade is exactly as narrow as it sounds: CAPH's approach only extends as far as Hetzner's own API does. A machine that isn't Hetzner Cloud or Hetzner Robot — a colo box, a secondhand Dell, a second bare-metal vendor — has no Hetzner API to call, and CAPH has no answer for it. That's not a bug in CAPH; it's the boundary of what "provision through the provider's own API" can ever cover.

The Decision Rule​

Put the two architectures side by side and the choice for any given fleet reduces to one question: does every machine in it live behind Hetzner's own API?

If yes — stay on CAPH alone. Running Ironic and a BMC network to provision hardware that Hetzner's API already provisions in one authenticated call is pure added operational surface with no capability gained. This is where bex sits today, and where most single-provider Cluster API fleets sit.

If no — Metal3 plus CAPM3 is the only Cluster-API-native path in. The day a deployment needs owned colo hardware, a rack of hand-me-down servers, or a second bare-metal vendor from the growing list of Hetzner-price-hike alternatives (OVHcloud, Netcup, and others), that hardware speaks Redfish or IPMI, not a Hetzner API endpoint. Metal3 is built precisely to bring machines like that into the same fleet, under the same Cluster API abstraction, without hand-rolling vendor-specific glue for every BMC brand a team happens to acquire hardware from. Concretely: a team that buys three secondhand Supermicro boxes for a colo rack doesn't need to write a bespoke controller that powers them on, PXE-boots an image, and hands them to kubeadm — it enrolls each one as a BareMetalHost with its Redfish endpoint and credentials, and CAPM3 makes it a Cluster API Machine like any other.

The honest cost of that second path isn't zero. Metal3's own 2025–2026 roadmap — per the same CNCF incubation announcement — still lists multi-tenancy hardening, ARM architecture expansion, DHCP-less provisioning, and UX simplification as open work, not finished features. Adopting Metal3 today means running Ironic as a new stateful component, securing a BMC-reachable network segment that didn't need to exist before, and accepting that some of the smoother experience CAPH gives you for free on Hetzner is still being built for the general case. None of that is a reason to avoid Metal3 once it's needed — it's a reason not to pre-adopt it while CAPH alone still covers every machine in the fleet.

Why the CNCF Badge Is the Reason "Wait" Is Safe, Not Reckless​

This is where incubation status stops being a vanity milestone and starts being useful information. CNCF's incubation bar specifically requires committers from multiple organizations, a documented governance process, and verified adoption at dev/test level or better — the exact properties that predict whether a project is still around and maintained in two years, versus stalling once its founding vendor loses interest. Fifty-seven contributing organizations and production use at Fujitsu, Ikea, SUSE, Ericsson, and Red Hat is a materially different bet than a Sandbox project maintained by one company.

That's what makes "defer Metal3 until you actually need it" a defensible engineering call rather than technical debt being kicked down the road. A team that only needs Metal3 the day it takes on its first non-Hetzner bare-metal box isn't betting on a project that might not exist by then — the CNCF incubation criteria are, in effect, someone else's due diligence already run.

None of this changes what bex ships today: CAPH provisioning Hetzner Cloud and Hetzner dedicated servers, no BMC layer, no Ironic to operate. But the graduation is worth tracking for exactly the reason the Sylva Project case study demonstrates in production — the moment a fleet's hardware stops being one vendor's API away, Metal3 is the Cluster-API-native answer already waiting, not one that has to be built from scratch under deadline pressure.

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