That being said what may be more useful is a EFI binary you can push to a motherboard that does this with a tpm key
Not to discount what the fog guys had… love what they made :)
Look at ironic for something better.
What we eventually ended up with after a couple of iterations was decidedly better for our use case :)
But sadly doesn’t exist in the outside world yet :(.
I run a homelab PXE & NFSboot, so no hard drives in the homelab. Works great until I do something to bork it up.
I have been fine tuning setup scripts to automatically get things going for scratch, but I always find there was one more hack I didn't automate last time.
iPXE is on my to-learn list.
A PXE boot server has many uses. The project already mentions using it for tools like GParted, Memtest86+ and so on. Booting live OS or OS installers via netboot.xyz is also great. But you can automate things even further; at a previous job (~18 years ago) I used PXE to serve a debian installer image with a preseed file to add user accounts with SSH keys, apt install all the dependencies, and install local binaries to get machines up and running useful stuff without needing to do any manual configuration. Nowadays you'd probably just have it do a minimal install + add just an SSH key, and then let another tool like Ansible take over the rest of the provisioning.
I do not say this to detract from the value of the project or its very interesting nature, by the way. Just an orthogonal observation.
Pxehost is much less featureful than Bootimus, no dashboard, and only supports netboot.xyz.
I am curious how Bootimus got udp broadcast to work via Docker on arm macOS. I could not figure that out and it’s why I released pxehost as a cross platform binary.
We need a good ISO to set up new hosts to run firecracker VMs in k3s. That would be a killer homelab tool. Tooling to make custom ISOs. And some Kairos/Talos immutable image update style tooling would be great too.
The dream is to boot via PXE once per host to setup secure k8s nodes, using just Ethernet cord, ISP router, and a windows laptop or an iPhone.
Slop websites are getting very old very fast.
https://vorpus.github.io/performativeUI/#/components/status-...
In your own homelab or in a small company, sure.
But the nice thing about proxyDHCP is that in a larger company, if the network engineering team hands you a subnet to play in that has DHCP forwarding configured in the router already, and you want to do PXE in it, you can just deploy your own proxyDHCP server without any extra red tape.
Or in my case, I just don't like to have configuration for a single service scattered around my network devices if I can avoid it.
Going by the Github, I'd be that it was Claude who figured it out. Which yeah, checks out.
When using such a server, its of critical importance its secure. If someone can enter it, they can change your images, knock over a machine and get it to boot a rogue image etc.
Id be interested what thread models are taken into account. If there is any fuzzing.
Perhaps a clear list of all the third party packages it pulls in and assessment of those packages.
It sounds like a lot but actually AI can help set up a lot of tooling around this stuff to make it more managable to do a lot of thorough testing / vetting of things.
I do think its also interesting project, and ofc it might be somehting that matures over time in this regard. (i am super biassed about security also as its my domain and i've litterally seen colleagues root servers which hosted images for entire infras of companies. thats a scary vector. if you can tamper with 1 PXE boot you can overwrite firmware.
(this is not saying anything about secure boot ofc, my experiences with PXE predate that being actively deployed)
EDIT: Found the disclosure in the repo: >I've used Claude CLI to help with some parts of this project - mostly making the web UI pretty, as I'm NOT a frontend developer. I also used it to generate the docs, but I review them manually - no automatically-generated AI code goes into the project without review from myself.
I guess that's fair.
Disclosure is something the author volunteered, its his freedom to do with HIS creation as he wishes.
Get off your soapbox.
v1.x · apache 2.0 go · iPXE · sqlite/postgres
Self-contained PXE and HTTP boot server. One binary. Zero config. Built-in proxyDHCP so you never touch your router. 50+ distros detected automatically.
pts/0
bootimus — quickstart
$ docker run -d --name bootimus \ --cap-add NET_BIND_SERVICE \ -p 67:67/udp -p 69:69/udp \ -p 8080:8080/tcp -p 8081:8081/tcp \ -v $(pwd)/data:/data \ garybowers/bootimus:latest
$ docker logs bootimus | grep Password admin: Password: 7f3a-plum-swift-echo
$ open http://localhost:8081
50+
distros detected
1
binary, zero deps
0
DHCP reconfigs
2
arch: amd64 · arm64
// features
Not a fork of 15-year-old Perl scripts. Not a wrapper around dnsmasq. A proper server, written in Go, with batteries included.
[01]
Go binary with embedded iPXE, web UI, SQLite, and all assets. No runtime deps. Scp it and run.
[02]
Answers PXE on UDP/67 without touching your existing DHCP. Zero router reconfig. Drop in on any LAN.
[03]
Automatic kernel/initrd extraction for Ubuntu, Debian, Arch, Fedora, NixOS, Alpine, FreeBSD, Windows (wimboot), and more.
[04]
Assign specific images per MAC. Auto-discover new clients on first PXE. Promote leases to static when ready.
[05]
GParted, Clonezilla, Memtest86+, SystemRescue, ShredOS, netboot.xyz. Enable from the UI, they show up in the menu.
[06]
Token auth with bcrypt. Optional LDAP/AD backend with group-based admin. Local accounts stay as fallback.
[07]
Everything the UI does is an API call. Script boot assignments, scans, WOL triggers. Live log stream over SSE.
[08]
Multi-arch Docker (amd64/arm64), static binary, or a 2GB Alpine-based appliance image you can flash to USB.
[09]
Drop autounattend.xml, kickstart, preseed, or cloud-init in. Attach to an image as the default, override per client. Bootimus stages it at boot — no clicks, no setup wizard.
// how it works
Client sends DHCPDISCOVER. Bootimus answers PXE details via proxyDHCP while your normal DHCP still hands out the IP. iPXE loads over TFTP, chains to HTTP, fetches the menu. User picks an image. Kernel and initrd stream from the server. Done.
pts/0
pxe boot trace — ubuntu-24.04
[dhcp] → DHCPDISCOVER from b4:2e:99:01:5f:a3 (no PXE options from primary DHCP) [proxy] ← DHCPOFFER-PXE: next-server=bootimus, filename=ipxe.efi [tftp] → RRQ ipxe.efi (198 KiB, 14 ms)
[http] → GET /menu.ipxe 200 2.1 KiB [menu] ↳ 17 images · 3 groups · 6 tools [menu] ↳ user selected: ubuntu-24.04-live-server
[http] → GET /iso/ubuntu-24.04/vmlinuz 200 14 MiB · 612 MB/s [http] → GET /iso/ubuntu-24.04/initrd 200 76 MiB · 598 MB/s [boot] handoff ok · client booting
// transparency
No proprietary blobs. No telemetry. No sneaky binary firmware vendored in. The whole stack is on GitHub under Apache 2.0 — clone it, audit it, fork it, fly your own.
✓
Single Go binary · statically linked, ldd returns "not a dynamic executable". Reproducible builds from make release.
✓
No proprietary blobs · embedded iPXE is upstream FOSS (GPL-2.0). No closed-source firmware shipped.
✓
No telemetry, ever · zero call-home. Zero analytics. Zero "anonymous usage stats". Air-gapped LAN safe.
✓
Apache 2.0 · permissive licence. Use in commercial environments, ship internally, fork without strings.
✓
Vendored deps, all FOSS · every transitive Go dependency is open source. go mod why any package.
✓
Bring your own bootloader · don't trust the embedded iPXE? Drop your own signed binaries in. See below.
pts/0
bootimus version --verbose
$ bootimus version --verbose bootimus 1.0.0 commit 8e87824 (clean) go 1.23.4 linux/amd64 build static · reproducible licence Apache-2.0
embedded ipxe 1.21.1+upstream GPL-2.0 proprietary 0 blobs telemetry disabled (compile-time)
$ ldd ./bootimus not a dynamic executable
$ sha256sum ./bootimus 7f3a9b0c… bootimus
// bootloaders
Bootimus ships with embedded iPXE for every common arch. Need Microsoft-signed binaries for Secure Boot, a custom-themed iPXE, GRUB, syslinux, or your own internal-CA-signed loader? Drop a folder in data/bootloaders/, pick it from the UI, done. Missing files transparently fall back to the embedded set — never a broken boot.
ipxe.efi · the default. Built from upstream master, embedded in the binary.
embedded · fallback
ipxe-arm64.efi · for Raspberry Pi 4/5, Apple Silicon hosts, ARM servers.
embedded · fallback
undionly.kpxe · for old kit that won't UEFI. Still relevant in 2026.
embedded · fallback
Drop a signed shimx64.efi + grubx64.efi in for Secure-Boot-enforced fleets. No firmware MOK enrolment needed.
custom · BYO
Compile your own iPXE with branding, custom menu colours, embedded scripts. Drop the .efi in.
custom · BYO
Not iPXE? No problem. Anything that speaks TFTP and HTTP works. Bootimus just serves bytes.
custom · BYO
pts/0
bootloader sets — file fallthrough
$ tree /var/lib/bootimus/bootloaders
data/bootloaders
├── ipxe-builtin/
│ ├── ipxe.efi
│ ├── ipxe-arm64.efi
│ └── undionly.kpxe
├── ipxe-secureboot/
│ ├── shimx64.efi (signed by Microsoft)
│ ├── grubx64.efi (signed by Microsoft)
│ └── ipxe.efi (signed by your CA)
└── ipxe-themed/
└── ipxe.efi (custom branding)
$ bootimus bootloaders use ipxe-secureboot ✓ active set: ipxe-secureboot ✓ falls back to ipxe-builtin for: ipxe-arm64.efi, undionly.kpxe
[tftp] RRQ shimx64.efi → ipxe-secureboot/shimx64.efi [tftp] RRQ ipxe-arm64.efi → ipxe-builtin/ipxe-arm64.efi (fallback)
Docker, bare metal, or flashable USB. Pick your poison.