Moving Beyond Static Scripts
Traditional PXE booting kicks off a static installation script — Red Hat uses Kickstart files, Ubuntu uses Preseed or Autoinstall YAML. These work, but they are monolithic: one giant configuration file that handles partitioning, package selection, user creation, and post-install scripts all in one place. When something fails halfway through, debugging is painful. When you want to reuse just the "partition the disk" step for a different OS, you cannot.
Tinkerbell is a CNCF (Cloud Native Computing Foundation) sandbox project that treats physical hardware provisioning like a programmable, containerized workflow — the same mental model as a CI/CD pipeline, but for bare metal.
Tinkerbell's Architecture
Tinkerbell has four main components:
| Component | Role |
|---|---|
| Smee | DHCP and TFTP server. Handles PXE boot requests and serves iPXE. |
| Hegel | Metadata server. Provides hardware-specific data to booting machines (like cloud-init does for VMs). |
| Rufio | BMC controller. Uses IPMI/Redfish to power cycle machines and set boot order. |
| Tink | The workflow engine. Stores hardware records and workflow definitions, executes steps. |
When a bare metal server PXE boots, Smee handles the DHCP/TFTP handshake and serves an iPXE script that boots a special in-memory Linux environment called Hook. Hook runs entirely in RAM and calls home to the Tink server.
The Workflow Model
A Tinkerbell Workflow is a document that defines an ordered list of actions targeted at a specific piece of hardware — each action is a standard OCI container image with its own timeout and environment configuration, run sequentially: wipe the target disk, stream the OS image onto it, configure the bootloader, then reboot. The Hook environment pulls and runs these containers directly on the bare metal machine, with real access to its hardware (disks, network interfaces). This means:
- You can test a disk-wiping action by running the container locally against a test disk.
- You can version your provisioning steps —
image2disk:v1.0.0vsimage2disk:v2.0.0. - You can reuse steps across different workflows — the same
wipe-diskaction works whether you are installing Ubuntu or Rocky Linux. - You can add custom steps — package the vendor's firmware update tool into a Docker image and insert it as Step 1.
Hardware Records
Tinkerbell also maintains a Hardware record for each physical machine, identified by MAC address — its disks, its network interface and static IP assignment, and whether it's permitted to PXE boot and run workflows at all. When a server PXE boots, Smee sees its MAC address, looks it up in the hardware registry, and serves the appropriate iPXE script. Tink then executes the workflow assigned to that hardware. The entire process is driven by data, not by manual intervention.
If asked "How is Tinkerbell different from just using Kickstart/Preseed?", the answer to emphasize is composability and testability. Kickstart is a monolithic script that runs inside the installer — you cannot test individual steps, you cannot version them independently, and you cannot reuse them. Tinkerbell workflows are composed of Docker containers, which means each step is independently testable, versioned via container tags, and reusable across workflows. It brings software engineering practices (version control, testing, reuse) to hardware provisioning.
Key Point: Tinkerbell's containerized workflow model solves the fundamental problem with traditional provisioning scripts: they are untestable black boxes that run once on real hardware. By decomposing provisioning into discrete Docker containers, each step becomes independently verifiable. A firmware update step can be tested in a lab before being added to the production workflow. A disk imaging step can be validated against a test disk. This is the same shift that containerization brought to application deployment — from "works on my machine" to reproducible, auditable artifacts.