Gary Bowers has released Bootimus, a self-contained network boot server that ships as a single binary and requires no configuration to run. It handles both PXE and HTTP boot, bundles proxyDHCP, and auto-detects more than 50 Linux distributions — collapsing what has traditionally been a multi-service provisioning stack into one executable.

The operational lift that usually comes with network booting is non-trivial. A conventional PXE environment demands a TFTP server, a DHCP server (or at minimum a DHCP option 66/67 configuration on existing infrastructure), and an HTTP server if you are serving UEFI-era payloads over HTTP Boot. Getting those services to coordinate correctly, especially in environments where touching the router DHCP configuration is politically or logistically difficult, is where most of the friction lives. Bootimus sidesteps that entirely by embedding a proxyDHCP server, which means it listens for DHCP discover broadcasts and injects PXE boot options without requiring any changes to the upstream DHCP server.

The single-binary delivery model is worth examining on its own terms. No dependency chain, no container runtime requirement stated, no package manager interaction — drop the binary, run it. For a homelab operator spinning up a bare-metal deployment workflow, that is a low barrier. For an enterprise environment where introducing new daemons requires change-control tickets, it is a more nuanced proposition, but the auditability of a single static binary is itself an argument some teams will find useful.

Distribution auto-detection covering over 50 Linux distributions, as listed on the official site, is the other significant operational detail. Manual netboot configuration typically means hand-authoring iPXE scripts or syslinux menu entries for each distro, keeping kernel and initrd paths current across version bumps, and handling the quirks of each distribution's netinstall layout. Automating that detection removes a meaningful category of maintenance work. The specifics of how Bootimus achieves this detection — whether via known ISO layout signatures, a bundled manifest, or network-fetched metadata — are not detailed in current public documentation, and that gap is worth watching as the project matures.

The project is hosted at garybowers/bootimus on GitHub, which is where version history, issue tracking, and any forthcoming documentation will live.

Network booting has had a quiet renaissance over the past several years. The rise of infrastructure-as-code, the return of on-premises bare-metal for AI/ML workloads where GPU-to-GPU latency and memory bandwidth make hypervisor overhead undesirable, and the general DevOps appetite for reproducible provisioning pipelines have all pushed teams back toward PXE-based workflows that felt like legacy infrastructure a decade ago. Tools like Tinkerbell, Foreman, and Matchbox have addressed the enterprise end of that space. Bootimus is clearly targeting a different point on the complexity curve — the operator who needs network boot working in an afternoon, not a platform team standing up a full provisioning control plane.

The zero-config claim deserves a degree of scrutiny that only real-world testing will resolve. ProxyDHCP interoperability across firmware implementations — particularly older BIOS-mode clients, mixed UEFI/legacy environments, and network hardware with strict DHCP relay behavior — has historically been an edge-case minefield. The auto-detection breadth of 50-plus distributions also raises questions about how the project handles rolling releases or distributions with non-standard netboot layouts. These are not criticisms of the current state so much as the natural stress points any network boot tool encounters at scale.

Still, the core value proposition is coherent. Reducing a multi-service dependency stack to a single binary with embedded proxyDHCP and broad distro support addresses a real pain point for a defined audience. Whether that audience is homelab engineers, small-team sysadmins, or developers who want to iterate quickly on bare-metal imaging pipelines, the friction reduction is genuine. The project is early, and the GitHub repository is where its trajectory will become readable.