Datum hired me to answer a question: in the bare metal provisioning space, which open source project is the right one to collaborate with, use and support? As longtime bare metal experts (the Datum founders previously started Packet, the “OG” bare metal cloud), they didn’t need me to educate them on bare metal, but to provide an objective point of view.
That question sounds simple until you really try to answer it. Datum supports open source projects, and support is not free. It costs engineering time, it costs money, and it costs credibility. If you back a project that dies in eighteen months, or one that turns out to be a single vendor with a community-shaped logo on top, you paid the bill at least three times over.
So the real deliverable for the Datum team was not “pick a tool”. It was “give us enough objective understanding of this space that we don’t regret our choice in a year”.
The first thing I did was refuse the list
I put together a list of projects to compare: MAAS, Tinkerbell, Metal3, Foreman, beskar7, Sidero Omni, Unbounded, NetBox and a few others.
The first useful thing I could say was that this list is not a list. NetBox is not a provisioner at all, it is DCIM and IPAM, adjacent and complementary but not really the same job. Sidero Omni and Unbounded are Kubernetes fleet platforms that happen to include a bare metal onboarder. MAAS, Foreman and Tinkerbell are actual “pure play” provisioners..
Comparing them on one flat table would have produced a ranking that looked good but meant nothing. So my first task was to create a categorized way to understand the landscape, not a ranked list.
The second tasks was to suggest a shared vocabulary. In the real world, each machine goes through discovery, onboarding, inventory, provisioning, day-2 and decommissioning. Every tool in this space draws its boundaries somewhere along that line, and most of the arguments people have about these tools are actually arguments about where the boundary should be. Once you have that lifecycle written down, “tool A is better than tool B” turns into “tool A owns more of stage 3 and none of stage 5”, which is just a better way to look at things.
Then I looked at the boring parts
Two axes ended up separating these projects more than anything else.
- How does the tool talk to the BMC? Redfish, IPMI, vendor-specific iDRAC or iLO, AMT.
- And how does the ephemeral OS get onto the machine? Network boot, PXE into iPXE into HTTP, or Redfish virtual media with the ISO mounted through the BMC.
The second one turned out to be the interesting one. Only Metal3 and beskar7 treat Redfish virtual media as a first-class boot path. Everyone else defaults to iPXE or PXE, which means they need to own DHCP on the provisioning VLAN.
“This tool wants your DHCP” is not a line item in any README, but it is the thing that will make or break the deployment conversation with a network team.
The other boring question was: what do I need before I can provision the first host? MAAS wants its controllers and PostgreSQL. Foreman wants PostgreSQL and Smart Proxies. Metal3 and beskar7 want a Kubernetes cluster and Cluster API. Omni wants Omni and a commitment to Talos. Tinkerbell ships a single binary with kube-apiserver and etcd embedded, so it can run standalone, or on Kubernetes via Helm if you prefer.
Let’s look around
GitHub stars are a signal, not a truth, but some of the numbers surrounding the stars are quite useful. Fork counts, issue turnaround, how many distinct humans made a commit in the last six months. Basically whether the release cadence survives a key person going on holiday.
Looking at the options from this angle, the governance picture came into focus quickly. Only Metal3 and Foreman have community governance at a real scale. MAAS is Canonical and AGPL. Unbounded is Microsoft, MIT, and very new. Omni is BSL 1.1, which is not open source no matter how it is presented.
Numbers only get you so far, though, so I did the other thing: I asked people. I have been around this space for a while, I have contributed to open source since my first day at a computer so I know where to go. I reached out to technical leaders I know who deal with this, and asked what they use, why they chose it, and what they think happens next. That’s not something you can scrape, but it can really change the conclusion.
Then I contributed (again)
You can’t tell what it is like to be in a community by reading its README. You find out by opening a pull request and seeing what happens. How long until someone looks at it. Whether the CI is honest. Whether the maintainer explains the “no” or just closes the issue. Whether the contributing docs describe the project as it exists today or as it existed three years ago.
So I opened a few issues in Tinkerbell’s repo.
- A fix in Smee so the tink-server hostname is preserved and the syslog FQDN can be set for iPXE scripts.
- Work to get the playground running on NixOS.
- Documentation for the Tinkerbell UI URL in the quickstarts, because I could not find it and the UI is a nice way to learn about new projects.
My contributions got reviewed. They got merged. That tells you more about whether a project is safe to depend on than any dashboard.
If it’s not obvious by now, I should be transparent: this is not a neutral first meeting for me. I was a maintainer of Tinkerbell years ago, back in the Packet and Equinix Metal days, and I stepped away as emeritus in 2021. Coming back to it five years later was actually useful, because I had a very concrete memory of what it used to be, and I can tell you the project I came back to is not the project I left.
What I recommended to Datum
Tinkerbell, or build your own on top of it.
The reason is not that it wins on stars, because it does not. It is that Datum’s Cloud itself is a kubebuilder operator: CRDs and controller-runtime on a cluster you own. Tinkerbell is the only serious option in this space that speaks that same language and can still run standalone when there is no cluster yet. That matters, because provisioning bare metal is often how the Kubernetes cluster comes to exist in the first place, and a tool that requires a cluster in order to build a cluster has a chicken and egg problem you will pay for later.
The one-line versions of the “no”:
– MAAS: AGPL friction for embedding or hosting, and single-vendor.
– Foreman: powerful, but the RHEL and config-management worldview is a hard fit for a modern cloud pitch.
– Metal3: heavy prerequisites, Kubernetes and CAPI first, excludes non-Kubernetes customers.
– Sidero Omni: BSL, not open source, and Talos-only.
– Unbounded: different product categories and too new.
I delivered all of this as a presentation at Datum’s public monthly meetup on 19 August 2026, with all the tradeoffs on display
About Tinkerbell specifically
This project has changed drastically in the last five years.
Jacob Weinstock, former Packet engineer, is leading it with a team of maintainers and a good number of contributors. A lot of the redesign happened while Tinkerbell was being used underneath AWS EKS Anywhere. It is Apache-2.0, CNCF sandbox since 2020, and today it gives you an in-memory operating system, a workflow execution engine, a DHCP server and iPXE bootloader, and BMC integration. Auto discovery, serial over SSH, static layer 3 provisioning, Kubernetes-style CRDs, Cluster API support. The UI is read-only for now. The roadmap has first-class IPv6 and DHCPv6, OpenTelemetry tracing, and a new in-memory OS that works on low-resource boards.
Here is the part that is relevant to you and to me: Tinkerbell does not have a company behind it. For good reason, it is an open source, community driven project, just as it should be.
If you are putting a data center on top of it, “there is nobody to call” is a legitimate concern, and pretending otherwise would be dishonest. But that’s also an opportunity, and I am considering having ShippingBytes be that thing you can call. Just a company that knows this code, is contributing to it, and can be hired to help you run it or extend it.
So, two things I can do for you
Open source analysis and radar. You are about to bet on a project. You want to know if the community is real, if the governance is real, if the license will bite you, and what the people who already run it think. I will find out, contribute to the ones that matter, and hand you something you can defend in front of your board — and I will present it in public if that is useful to you.
Bare metal provisioning. If you are standing up a new data center, or running experiments around bare metal provisioning, I know this space and I know Tinkerbell from the inside. Let’s talk before you write the first line of your own provisioner.
If any of this is close to a problem you have, write to me:
[info@shippingbytes.com](mailto:info@shippingbytes.com).
Practical lessons on shipping software, straight to your inbox. No fluff.