Network Booting Without the Router Trauma: A Look at Bootimus

Every developer who has managed a home lab, a bare-metal testing cluster, or edge hardware knows the unique dread of the "bootable USB." You find a flash drive, write an ISO, boot the target machine, realize you need a different kernel parameter or a newer package, re-flash the drive, and repeat. Eventually, you wear out the silicon on your flash drives and your patience.

The enterprise alternative is Preboot Execution Environment (PXE) booting, but setting it up has historically felt like a sysadmin hazing ritual. To get a standard PXE or HTTP Boot server running, you typically have to stitch together a fragile web of independent services: a DHCP server, a TFTP server, an HTTP server, and a bootloader like iPXE or GRUB.

Bootimus is a self-contained, open-source (Apache 2.0) PXE and HTTP boot server written in Go that collapses this entire infrastructure stack into a single, statically linked binary. By embedding the bootloaders, the database, the web UI, and—crucially—a proxyDHCP responder, Bootimus shifts network booting from an infrastructure-level chore to a lightweight developer utility.

The Traditional PXE Tax vs. The Single-Binary Cure

To appreciate what Bootimus does, it helps to look at what it replaces. A traditional HTTP Boot setup (such as the one detailed in SUSE Linux Enterprise documentation) requires installing and configuring dnsmasq for DNS, apache2 or nginx for hosting the installation media, and dhcp-server to hand out IP addresses and boot parameters.

You have to manually configure DHCP options, mapping specific vendor class identifiers like "HTTPClient" to absolute boot URLs, and manually extract kernels (vmlinuz) and initial ramdisks (initrd) from your ISOs to mount them in your web root. One typo in your router's DHCP configuration, and you risk knocking the entire local network offline.

Bootimus sidesteps this complexity using three architectural shortcuts:

1. Zero-Dependency Static Binary: The entire server is compiled into a single Go binary. Running ldd on it returns "not a dynamic executable", meaning there are no runtime dependencies or shared library conflicts to manage.
2. Built-in proxyDHCP: This is the killer feature. Instead of replacing or modifying your existing router's DHCP server, Bootimus listens on UDP port 67 for DHCPDISCOVER broadcasts. When a PXE-enabled client boots, Bootimus intercepts the request and sends a DHCPOFFER-PXE containing the next-server and bootloader filename (ipxe.efi), while your existing router handles standard IP address allocation. You get network booting with zero router reconfiguration.
3. Automatic Distro Detection: Instead of manually mounting ISOs and writing custom GRUB or iPXE menu entries, Bootimus automatically detects and extracts kernels and initrds for over 50 distributions, including Ubuntu, Debian, Arch, Fedora, NixOS, Alpine, FreeBSD, and Windows.

Under the Hood: The ProxyDHCP Handshake

Because Bootimus runs its own proxyDHCP and TFTP/HTTP servers out of the same process, the boot flow is highly coordinated. Here is how a client transitions from a cold boot to streaming a kernel over HTTP:

sequenceDiagram
    autonumber
    Client->>Router (DHCP): DHCPDISCOVER (broadcast)
    Bootimus (proxyDHCP)-->>Client: DHCPOFFER-PXE (next-server=Bootimus, file=ipxe.efi)
    Router (DHCP)-->>Client: DHCPOFFER (IP Address allocation)
    Client->>Bootimus (TFTP): RRQ ipxe.efi
    Bootimus (TFTP)-->>Client: Send ipxe.efi
    Client->>Bootimus (HTTP): GET /menu.ipxe
    Bootimus (HTTP)-->>Client: HTTP Menu & Kernel/Initrd Stream

Once the embedded iPXE bootloader loads, it chains to Bootimus's HTTP server to fetch the boot menu. From there, the client streams the kernel and initrd over HTTP rather than TFTP. This is a massive performance win: while TFTP is notoriously slow and prone to packet loss on busy networks, HTTP Boot can stream installation media at saturating line speeds (often exceeding 600 MB/s on gigabit or multi-gigabit links).

The Developer Workflow

To spin up Bootimus on a local development machine or home lab server, you can run it via Docker with a single command. Because it needs to bind to privileged UDP ports for DHCP and TFTP, you must grant it the NET_BIND_SERVICE capability:

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

Once running, you can grab the auto-generated admin password from the container logs and log into the web UI at http://localhost:8081.

Unattended Installs and API-Driven Provisioning

For developers automating bare-metal provisioning, Bootimus goes beyond simply serving a boot menu. It includes several features designed for automated pipelines:

• Unattended Templates: You can drop autounattend.xml (for Windows), kickstart, preseed, or cloud-init configuration files directly into the Bootimus data directory. You can attach these templates to specific images as defaults or override them on a per-client basis.
• Windows SMB Hosting: Bootimus can host Windows installation media over SMB (using Samba bundled inside the Docker image) and automatically launch setup.exe via wimboot for fully automated Windows installations.
• MAC-Based Access Control: When a new client PXE boots, Bootimus automatically discovers it (similar to a DHCP lease) and logs its hardware inventory (CPU, memory, NIC info, serial numbers). You can promote the client to static, assign a specific boot image or diagnostic tool to its MAC address, or set a "one-time next boot action" that reverts to booting from the local disk after the installation completes.
• REST API & SSE Logs: Every action available in the web UI is backed by a REST API, allowing you to script boot assignments, trigger Wake-on-LAN (WOL) packets, and stream live boot logs over Server-Sent Events (SSE).

The Trade-offs and "There Be Dragons" Realities

While Bootimus is incredibly elegant, developers should weigh a few caveats before deploying it into production:

• Early-Stage Project: The repository explicitly warns that this is an early-stage, work-in-progress project. The creator notes using Claude CLI to assist with the frontend UI and documentation. While the core Go code is robust, you may encounter edge cases with obscure hardware or specific ISO layouts.
• Network Security Risks: Running a proxyDHCP server on a corporate network without authorization will likely trigger security alerts (and potentially anger your network engineering team). Because proxyDHCP broadcasts on UDP/67, it is best suited for isolated development VLANs, home labs, or point-to-point network connections.
• Database Scaling: Out of the box, Bootimus uses an embedded SQLite database, which is perfect for zero-config single-node setups. If you are managing a larger fleet or require high availability, you will need to configure it to point to an external PostgreSQL instance.
• Secure Boot Complexity: While Bootimus supports Secure Boot by allowing you to drop Microsoft-signed shims (shimx64.efi and grubx64.efi) into its bootloader directory, managing custom certificates and Machine Owner Keys (MOK) on target hardware remains an operational hurdle.

The Verdict

For developers tired of managing a drawer full of USB sticks or wrestling with enterprise-grade PXE suites like Fog Project, Bootimus is a breath of fresh air. It successfully packages the entire network-booting lifecycle into a modern, API-first tool. If you need to frequently provision virtual machines, test operating systems on bare metal, or run diagnostic tools like GParted or Memtest86+ across a local fleet, Bootimus is well worth a spot in your utility belt.