Provisioning Bare Metal: Metal3, Tinkerbell, and Sidero Omni Compared

You have made the harder decision already. The workloads are coming off the hyperscaler, the finance model closes, and the plan is real servers in a real cage — owned capacity, predictable cost, data that never leaves a jurisdiction you control. Then the first server arrives, and it is a cardboard box containing a machine that knows nothing. It has no operating system, no cluster membership, no idea it is supposed to be a Kubernetes node. Multiply that by forty, and the romance of repatriation collides with a deeply unglamorous question: how does a powered-off box in a rack become a node in your cluster, reliably, repeatably, and without a human holding a crash cart?

This is the provisioning-and-lifecycle layer, and it sits directly above the node operating system. We have argued elsewhere that an immutable OS like Talos Linux is the right node substrate — but that post is about what runs *on* the disk. This one is about everything that has to happen *before and after* that: powering the machine on out-of-band, network-booting it, streaming an image to its disk, joining it to a cluster, and — the part everyone underestimates — re-imaging, upgrading, and decommissioning it years later without a runbook full of manual steps. In 2026 three open tools own this space, and they are not interchangeable. Choosing wrong is expensive precisely because the provisioning layer is one of the hardest things to replace once a fleet depends on it.

This is a map, not a leaderboard. Tinkerbell, Metal3, and Sidero Omni solve overlapping problems with genuinely different philosophies — a workflow engine, a Cluster API provider, and a management plane that walked away from Cluster API on purpose. The goal here is to name precisely what each one is, what it assumes about your hardware, and which operation it actually fits, so the decision is made on architecture rather than on whichever demo you saw first.

The Layer Above the OS: What 'Provisioning' Actually Means

Strip away the branding and every bare-metal provisioner solves the same physics. A server in a rack exposes two control surfaces. The first is its baseboard management controller (BMC) — the little always-on computer beside the main board that speaks Redfish, IPMI, or a vendor dialect like iDRAC or iLO. Through the BMC you can power a machine on, set it to boot from the network, and mount virtual media, all without an operating system present. The second surface is the network itself: when the machine PXE-boots, it asks for DHCP, is handed an iPXE script, and loads an in-memory operating system that does the actual installation. Everything a provisioner does is orchestration of these two surfaces, plus the bookkeeping of which physical machine is which.

The lifecycle that follows is universal, and it is worth walking once because each tool implements exactly these stages — the difference is which parts it owns and how declaratively it expresses them. Out-of-band power-on, network boot, in-memory installer, image write, reboot-and-join, and then the long tail of Day-2: re-imaging a failed node, rolling a kernel or OS upgrade, draining and decommissioning hardware at end of life. The provisioners diverge most sharply at the two ends — how you *declare* a machine at the start, and how much of the Day-2 tail is automated versus scripted by you.

Click to zoom

Hold onto that back-edge — the loop from Day-2 back to power. A tool that only performs the left-to-right install once is an installer. A tool that continuously reconciles a machine's desired state, and can re-image or retire it on command years later, is a lifecycle manager. That distinction, more than any feature checklist, is what separates the three approaches, and it maps directly onto how much of your operations you are automating versus scripting by hand.

Tinkerbell: The Workflow Engine

Tinkerbell, a CNCF project born inside Equinix Metal, is the most primitive of the three in the precise engineering sense: it is a general-purpose bare-metal provisioning and workflow engine that makes no assumptions about what you install. Its architecture is a handful of composable services — Smee (the DHCP/TFTP/PXE server, formerly Boots), Tootles (the metadata service, formerly Hegel), HookOS (the in-memory install environment), Tink (the workflow engine, a gRPC server and per-machine worker), and Rufio for BMC power management. You describe hardware, templates, and workflows as Kubernetes custom resources, and Tink executes the template's actions — arbitrary container images — against the target machine when it network-boots.

The power of this model is that a provisioning workflow is just an ordered list of containers, each doing one job: partition a disk, stream an image, write a cloud-init file, flash firmware, reboot. Because actions are containers, you compose the exact install you need — and Tinkerbell's move to shared actions on the CNCF Artifact Hub means common steps are reusable rather than reinvented. Nothing about it is Kubernetes-specific: Tinkerbell provisions Ubuntu, Flatcar, Talos, or a bespoke image with equal indifference. That OS-agnosticism is its defining trait and its sovereignty argument — you are not adopting a vendor's opinion about your operating system, you are adopting a mechanism.

apiVersion: tinkerbell.org/v1alpha1
kind: Template
metadata:
  name: talos-install
spec:
  data: |
    version: "0.1"
    name: talos-install
    global_timeout: 1800
    tasks:
      - name: "install"
        worker: "{{.device_1}}"
        actions:
          - name: "stream-image"
            image: quay.io/tinkerbell/actions/image2disk:latest
            timeout: 600
            environment:
              DEST_DISK: /dev/sda
              IMG_URL: http://images.internal.example.com/talos-metal-amd64.raw.gz
              COMPRESSED: "true"
          - name: "reboot"
            image: quay.io/tinkerbell/actions/reboot:latest
            timeout: 90
---
apiVersion: tinkerbell.org/v1alpha1
kind: Workflow
metadata:
  name: install-worker-01
spec:
  templateRef: talos-install
  hardwareRef: worker-01
  hardwareMap:
    device_1: 00:1b:44:11:3a:b7

The cost of that generality is that Tinkerbell hands you a mechanism, not a finished product. It will boot and image machines all day, but the cluster-shaped experience — a control plane that reconciles "I want three control-plane nodes of this class" — is not in the box. That is what the Cluster API Provider Tinkerbell (CAPT) adds, and in 2026 it remains a technical preview. Tinkerbell fits the operation that wants a sovereign, OS-agnostic provisioning primitive it can wire into its own automation — and is comfortable owning the integration glue rather than buying it.

Metal3: The Cluster API-Native Path

Metal3 ("metal cubed") answers a different question: what if a physical server were just another Kubernetes object you reconcile? Its foundation is the baremetal-operator (BMO) and the BareMetalHost custom resource — one CR per physical machine, carrying the BMC address and credentials, the boot MAC, root-device hints, and the desired OS image. Behind BMO sits Ironic, the mature bare-metal provisioning service inherited from OpenStack, which does the real work of talking to BMCs over Redfish/IPMI/iDRAC, inspecting hardware, and writing images. You declare a machine; the operator drives Ironic to make reality match the declaration.

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: worker-01
  namespace: metal3
spec:
  online: true
  bootMACAddress: "00:1b:44:11:3a:b7"
  bmc:
    address: redfish-virtualmedia://10.0.0.11/redfish/v1/Systems/1
    credentialsName: worker-01-bmc-secret
  rootDeviceHints:
    deviceName: /dev/sda
  image:
    url: http://images.internal.example.com/talos-metal-amd64.raw.gz
    checksum: http://images.internal.example.com/talos-metal-amd64.raw.gz.sha256
    checksumType: sha256

The reason Metal3 matters is Cluster API. The Cluster API Provider Metal3 (CAPM3) is the reference infrastructure provider that lets Cluster API provision bare metal into workload clusters. When you create a Cluster API Machine, CAPM3 reconciles it to a Metal3Machine, which claims a BareMetalHost, which BMO provisions through Ironic. The result is that a rack of servers and a fleet of clusters are described in the *same* declarative language — the same kubectl apply, the same GitOps repository, the same reconciliation semantics you already use for workloads. For a platform team standardizing on Cluster API, that uniformity is the whole point: bare metal stops being a special case and becomes another provider.

That power carries operational weight. Ironic is a substantial service with a real footprint, and since CAPM3 v0.5.0 the baremetal-operator is deliberately decoupled from the provider — you install and run BMO and Ironic yourself, which is more moving parts than a single binary. Metal3's BMC and firmware handling is genuinely the deepest of the three, which is exactly what heterogeneous fleets from multiple vendors need. Metal3 fits the operation that is all-in on Cluster API, wants its host inventory declared in Git as BareMetalHost objects, and treats bare metal as a first-class citizen of a declarative multi-cluster fleet managed with GitOps.

Sidero Omni: The Post-Cluster-API Bet

Sidero Labs — the company behind Talos Linux — took the most opinionated position of the three, and it is instructive because they arrived at it by reversing an earlier one. Their original bare-metal provisioner, Sidero Metal, was itself a Cluster API-based system. In 2026 they stopped actively developing it and pointed users to Omni and its bare-metal infrastructure provider instead. The stated reasoning is a direct critique of Cluster API's core assumption: CAPI treats every machine as replaceable and expects immutable, in-place upgrades from spare capacity — but in the real world, people do not keep spare servers idling next to a rack of expensive GPUs or large local-storage nodes waiting for an upgrade cycle. The abstraction that fits cloud VMs does not fit metal you paid for.

So Omni is machine-centric rather than cluster-centric. A bare-metal machine PXE-boots into the infrastructure provider, joins an Omni fleet automatically over SideroLink (a WireGuard-based management link), and becomes an available Machine you allocate to clusters via machine classes and cluster templates. There are no PXE scripts to maintain, no ISO to mount by hand, no Terraform for the OS — the provider handles power-on, OS install, and decommissioning, and KubeSpan meshes the nodes across networks. Because everything is Talos, and Omni speaks Talos natively, the same management plane unifies bare metal, cloud VMs, and edge devices — a Raspberry Pi and a GPU server can land in one cluster.

kind: Cluster
name: prod-bm
kubernetes:
  version: v1.33.1
talos:
  version: v1.10.3
---
kind: ControlPlane
machineClass:
  name: bare-metal-cp
  size: 3
---
kind: Workers
machineClass:
  name: bare-metal-workers
  size: unlimited

Click to zoom

The trade is stark and worth stating plainly. Omni is the most finished, lowest-toil experience of the three — and the most opinionated. It provisions Talos and only Talos, and the Omni management plane is a commercial, source-available product from Sidero, not a permissively-licensed community project like Tinkerbell or Metal3. You are buying ergonomics and a coherent lifecycle in exchange for coupling to one OS and one vendor's control plane. For a Talos-committed shop that values operational simplicity over breadth, that is often a very good trade — but it is a different *kind* of decision than adopting a CNCF mechanism, and it deserves the exit-ramp scrutiny in the next section.

Which Fits Which Operation

The three tools are not ranked; they are matched to operations. Decide by the shape of your fleet, your OS commitment, and how much integration glue you are willing to own, not by which has the shiniest demo.

• You want a sovereign, OS-agnostic provisioning primitive and are comfortable owning the glue: Tinkerbell. It provisions any operating system as an ordered list of container actions, hides nothing, and locks you into no OS opinion. Best when your automation is bespoke and you want a mechanism, not a product — accept that the cluster-shaped experience (CAPT) is still a technical preview.
• You are standardizing the whole platform on Cluster API and want host inventory in Git: Metal3. BareMetalHost CRs make physical machines first-class Kubernetes objects reconciled through the deepest BMC/firmware stack of the three. Best for heterogeneous multi-vendor fleets and GitOps-managed cluster fleets — accept that you operate Ironic and baremetal-operator as real services.
• You are committed to Talos and value a finished, low-toil lifecycle over breadth: Sidero Omni. Machines self-join a fleet and are allocated by class; power-on, install, and decommission are handled for you across bare metal, cloud, and edge. Best when operational simplicity beats optionality — accept Talos-only coupling and a commercial, source-available management plane.
• You are a large, heterogeneous shop running multiple operating systems and multiple vendors under one GitOps discipline: lean Metal3, and treat Tinkerbell as the lower-level engine for anything Metal3's image model does not cover. The two compose; Omni does not compose into a non-Talos world.
• You are provisioning a handful of identical Talos nodes and want to be running this week: Omni is the fastest path from cardboard box to cluster. The finished ergonomics earn their keep most clearly at small-to-medium Talos fleets where you have no appetite to operate Ironic.

The Exit Ramp: Sidero Metal Is the Cautionary Tale

The provisioning layer sits underneath every workload you will ever run, which makes the anti-lock-in question non-negotiable: if this layer disappears or disappoints, what does leaving cost? The most honest evidence available is Sidero Metal itself. Teams adopted it as a Cluster API-based bare-metal provisioner, wired their fleets into it, and then watched the vendor deprecate it in favour of a differently-architected successor. That is not a knock on Sidero — sunsetting a design you have outgrown is responsible engineering — but it is a live demonstration that the provisioning layer *can* be pulled out from under you, and that betting a fleet on it is a decision with a decade-long tail. It is the same lesson we drew from the archival of the Hierarchical Namespace Controller: the layers beneath your workloads are the expensive places to be wrong.

Rank the exit ramps honestly. Metal3 has the graded one: BareMetalHost and Cluster API are open specifications with a broad multi-vendor maintenance base, so migrating between CAPI providers or lifting host definitions elsewhere is a schema translation, not a rewrite. Tinkerbell's exit is also clean because its output is just installed machines and its workflows are portable container actions — nothing proprietary is expressed. Omni's exit is the steepest: the *nodes* remain portable because Talos is open and a Talos machine can be re-adopted by any Talos control plane, but the *management plane* — the fleet model, machine classes, and lifecycle automation — is Omni-specific, and reproducing it is real work. The mitigation is disciplined: keep your cluster templates and machine definitions in your own Git repository so the intent, not the vendor's console, is your source of truth.

The Long Game: Provisioning Is a Decade Decision

Most infrastructure choices are reversible in a weekend; the provisioning layer is not. It is the substrate that every node, cluster, and workload is instantiated from, and it accretes assumptions — image-build pipelines, BMC credential handling, network-boot topology, Day-2 runbooks — that quietly wire themselves into how the whole organization operates hardware. Replacing it means re-touching every machine you own. That is why the durable move is to choose on architecture and maintenance base, not on time-to-first-cluster, and to insist that whatever you pick expresses its intent in portable artifacts you hold in your own repository.

Notice that Day-2 is where the long game is actually won or lost. A demo shows you the install; production shows you the re-image at 2am, the firmware update across a hundred BMCs, the clean decommission of a node whose disk must be wiped for compliance. Weight your evaluation toward that back-edge of the lifecycle — the reconcile loop, not the first boot — because that is where you will spend the next ten years. Metal3 automates it declaratively, Omni automates it as a product, and Tinkerbell automates exactly as much of it as you build. Provisioning also underpins recovery: your disaster-recovery plan is only as fast as your ability to re-provision nodes from bare metal, so the tool you choose here sets a floor under your RTO.

The sovereignty thread ties all of this together. Owning your provisioning layer means owning your hardware from power-on to disposal — no cloud metal API deciding what you may install, no external control plane you cannot audit, no dependency you did not choose. That is the same instinct behind moving workloads off hyperscalers onto engineering you control: fewer, better-understood systems that you can reason about completely. If you are standing in front of a rack trying to decide which of these three fits your operation, that architecture assessment is exactly the kind of engagement we do — matching the provisioner to your fleet, your OS commitment, and the exit ramp you can live with, before you commit a decade to it.