Tinkerbell: Bare-Metal Provisioning

By Khimananda Oli | Last reviewed: August 2026

Managing physical servers often feels like a step backward into manual configuration hell, especially when your team is accustomed to the elasticity of cloud VMs. Tinkerbell: Bare-Metal Provisioning solves this friction by treating physical hardware exactly like cloud infrastructure, using containerized actions and declarative workflows to automate installation from power-on to production-ready. Instead of maintaining fragile PXE configurations and kickstart files, you define provisioning logic in Docker containers that execute sequentially on the target machine.

If you are managing hybrid environments or on-prem data centers in Nepal where cloud latency or data residency is a concern, mastering this tool is essential. For teams already practicing Infrastructure as Code, integrating Tinkerbell aligns physical provisioning with the same rigorous standards applied to Terraform-managed cloud resources. The mental model shifts from "installing an OS" to "executing a pipeline," making bare metal a first-class citizen in your DevOps ecosystem.

How does Tinkerbell bare-metal provisioning actually work?

At its core, Tinkerbell decouples the operating system installation from the boot mechanism. Traditional PXE setups rely on static kickstart or preseed files hosted on an HTTP server, which become unmanageable at scale. Tinkerbell introduces the concept of "Hooks" — lightweight, container-based actions that run in memory on the target hardware before any OS is installed.

The Hook OS and Action Containers

When a machine boots via PXE, it loads the Hook OS, a minimal Linux environment designed solely to execute containers. This environment pulls action images from a local OCI registry. Each action (e.g., write-rootfs, install-grub, configure-network) runs as an isolated container with access to the host's block devices and network interfaces. This means your provisioning logic is portable, versioned, and testable locally before touching production hardware.

The workflow engine orchestrates these actions based on a template mapped to the specific hardware MAC address. Unlike cloud-init which runs post-boot, Tinkerbell actions have raw access to the disk during the installation phase, allowing for complex partitioning, RAID setup, and encrypted volume creation that would be impossible with standard user-space tools. For teams familiar with Docker fundamentals, this pattern feels natural: you are essentially building a CI/CD pipeline that targets bare metal instead of a Kubernetes cluster.

How do you configure Tinkerbell workflows for custom OS installs?

A Tinkerbell workflow is defined as a YAML template containing a sequence of actions. In 2026, the ecosystem has matured significantly, providing reliable base images for Ubuntu 24.04, Rocky Linux 9, Debian 12, and Windows Server 2025. However, real-world deployments rarely use stock templates; you will need to customize them for security hardening, compliance, or application-specific requirements.

Defining a Custom Template

Below is a practical example of a workflow template for deploying a hardened Ubuntu server. Note how each action specifies an image, environment variables, and device mappings. This declarative approach allows you to store provisioning logic in Git alongside your application code.

version: "0.1"
name: ubuntu-2404-hardened
global_timeout: 1800
tasks:
  - name: "os-installation"
    worker_addr: "{{.device.mac}}"
    volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro
    actions:
      - name: "stream-image"
        image: quay.io/tinkerbell-actions/write-rootfs:v0.8.0
        timeout: 600
        environment:
          IMG_URL: http://provisioner.local/images/ubuntu-2404-hardened.raw.gz
          DEST_DISK: /dev/sda
          COMPRESSED: true
      - name: "configure-network"
        image: quay.io/tinkerbell-actions/configure-netplan:v0.2.0
        timeout: 90
        environment:
          NETPLAN_CONFIG: |
            network:
              version: 2
              ethernets:
                eno1:
                  dhcp4: false
                  addresses: [{{.device.ip}}/24]
                  gateway4: {{.device.gateway}}
                  nameservers:
                    addresses: [1.1.1.1, 8.8.8.8]
      - name: "install-grub"
        image: quay.io/tinkerbell-actions/grub-install:v0.3.0
        timeout: 90
        environment:
          DEST_DISK: /dev/sda
          EFI_PARTITION: /dev/sda1
      - name: "post-install-security"
        image: registry.internal/hardening-action:v1.2.0
        timeout: 300
        environment:
          ENABLE_FIPS: "true"
          SSH_KEYS: "{{.device.ssh_keys}}"
          AUDIT_PROFILE: "soc2-type2"

This template demonstrates three critical patterns: variable substitution using device metadata, inline configuration for network setup, and custom internal actions for compliance. The post-install-security action references a private registry image, highlighting how you can encapsulate organizational standards into reusable components. If you are implementing DevSecOps practices, this is where policy-as-code meets bare metal.

What are the prerequisites for deploying Tinkerbell in production?

Deploying Tinkerbell requires careful network planning, as it takes authoritative control over DHCP and TFTP services on the provisioning VLAN. Running this on a shared corporate network without isolation will cause IP conflicts and disrupt existing services. In my experience helping Nepali enterprises modernize their on-prem infrastructure, the most common failure point is inadequate network segmentation.

• Dedicated Provisioning VLAN: Isolate bare-metal traffic from production networks. Tinkerbell must be the sole DHCP authority on this segment.
• Provisioner Hardware: Minimum 4 vCPU, 8GB RAM, and 200GB SSD for the OS image cache. Network throughput matters more than CPU; use 10GbE if provisioning multiple nodes simultaneously.
• Container Runtime: Docker CE or containerd on the provisioner. The Tink stack runs as containers managed by Docker Compose or Helm.
• UEFI/BIOS Consistency: Standardize on UEFI boot mode across all target hardware. Mixed BIOS/UEFI fleets require separate workflows and complicate maintenance.
• Image Repository: Local OCI registry (Harbor, Zot, or Docker Registry) pre-loaded with Hook OS and action images. Do not pull from public registries during provisioning; air-gapped reliability is non-negotiable.

For teams managing database servers on bare metal, combining Tinkerbell with proper storage configuration ensures your PostgreSQL instances start on correctly partitioned and tuned disks from day one. Automating filesystem tuning (noatime, swappiness, hugepages) within the provisioning workflow eliminates an entire category of post-deployment performance issues.

How does Tinkerbell compare to MAAS, Foreman, and Ironic?

Choosing a bare-metal provisioning tool depends heavily on your existing ecosystem and operational maturity. Tinkerbell occupies a specific niche: container-native, workflow-driven, and lightweight. It lacks the full lifecycle management of heavier platforms but excels at flexible, programmable installation.

If your team lives in containers and GitOps, Tinkerbell’s learning curve is gentler because it reuses familiar primitives. MAAS offers superior hardware discovery and ongoing management but demands significant operational overhead. Foreman remains the gold standard for RHEL shops needing content view management and errata tracking. Ironic is only justified if you are already running OpenStack. For most DevOps teams in 2026 seeking to automate bare metal without adopting a platform monolith, Tinkerbell provides the best balance of power and simplicity.

Start Automating Your Bare Metal Today

Tinkerbell bare-metal provisioning bridges the gap between physical infrastructure and modern DevOps practices, giving you the reproducibility and auditability required for compliant, scalable operations. Start with a single provisioning VLAN and a simple Ubuntu workflow to validate the architecture before expanding to heterogeneous fleets. Document every custom action and treat your templates as production code with reviews and versioning. If you need help designing a bare-metal automation strategy that integrates with your existing CI/CD pipelines and compliance requirements, reach out to discuss your infrastructure challenges.