Ditch the USB Drives: A Netboot.xyz Guide for the Ultimate HomeLab PXE Setup

Table of Contents

The Graveyard of Mismatched USB Sticks

Take a look at your desk. If you’re anything like me, it’s probably littered with a half-dozen unlabelled SanDisk Cruzer sticks.

One likely holds a dusty Ubuntu 22.04 installer, another has a corrupted Proxmox ISO, and a third is a Windows recovery drive that failed me last Tuesday. If you run a HomeLab, you’ve lived this frustration. Every new physical node or test build starts with the same tedious ritual: find a drive, download an ISO, flash it with BalenaEtcher, and pray the hardware actually recognizes it.

While this works for a single machine, it’s a massive bottleneck when you’re provisioning a cluster. When I added four refurbished Dell OptiPlex 7050 nodes to my rack, I realized I was spending 45 minutes just preparing boot media. I spent more time digging through drawers for ‘the good USB drive’ than I did actually configuring my servers.

The Hidden Cost of Local Booting

Physical media is fundamentally decentralized and quickly becomes obsolete. The moment a new point release drops, your carefully flashed USB drive is essentially e-waste. Physical ports also fail, and USB 2.0 speeds crawl along at 480Mbps, making a 4GB image feel like an eternity.

We have high-speed 1Gbps or even 10Gbps local networks in our homes, yet we still carry bits around in our pockets like it’s 1998. The real problem is the lack of a centralized deployment hub. Your hardware should be able to tap into a single, updated library of operating systems the moment it powers on.

Comparing the Options: USB vs. Custom PXE vs. Netboot.xyz

Historically, network booting meant building a PXE (Preboot Execution Environment) server from scratch. This was a project in itself. You had to wrestle with TFTP configurations, host images on a web server, and manually manage complex kickstart or preseed files.

Manual USB: Low barrier to entry but high maintenance and prone to hardware failure.
Custom PXE Server: Maximum flexibility, but requires deep knowledge of DHCP options and constant manual updates.
Netboot.xyz: The sweet spot. It offers a community-maintained directory of dozens of OSs that boot directly from the cloud or a local cache.

Mastering this workflow is a game-changer. Once you switch to a network-based deployment, you’ll never reach for a flash drive again. Netboot.xyz acts as a thin bootloader, providing a Netflix-style menu for your hardware.

Deploying Netboot.xyz with Docker

The most efficient way to run Netboot.xyz is via Docker. This keeps your host OS clean and makes version updates a one-command affair. I use Docker Compose to keep the configuration documented and reproducible.

First, create a dedicated directory for the service:

mkdir ~/netbootxyz && cd ~/netbootxyz
nano docker-compose.yml

Paste this configuration into the file:

services:
  netbootxyz:
    image: ghcr.io/netbootxyz/netbootxyz
    container_name: netbootxyz
    environment:
      - MENU_VERSION=2.0.76
      - NGINX_PORT=80
    volumes:
      - ./config:/config
      - ./assets:/assets
    ports:
      - 3000:3000 # Web Dashboard
      - 69:69/udp # TFTP Service
      - 8080:80   # Local Asset Server
    restart: unless-stopped

Deploy the container:

docker compose up -d

Your server is now live. Head to http://<your-ip>:3000 to access the dashboard. This UI is where you’ll manage your boot menus and “localize” assets to speed up installations across your LAN.

The Essential Piece: DHCP Configuration

Getting the container running is the easy part. The real magic happens when you tell your computers to look for this server during the boot sequence. This requires two specific tweaks to your DHCP server (like your router or Pi-hole).

Next Server (Option 66): This is the IP address of your Docker host (e.g., 192.168.1.50).
Bootfile Name (Option 67): Use netboot.xyz.kpxe for legacy BIOS or netboot.xyz.efi for modern UEFI machines.

Configuring Pi-hole (dnsmasq)

If you use Pi-hole for DHCP, you can add PXE support by creating a custom configuration file:

sudo nano /etc/dnsmasq.d/07-pxe.conf

Add these lines, substituting your actual server IP:

dhcp-boot=netboot.xyz.kpxe,,192.168.1.50
dhcp-match=set:efi64,option:client-arch,7
dhcp-match=set:efi64,option:client-arch,9
dhcp-boot=tag:efi64,netboot.xyz.efi,,192.168.1.50

Apply the changes with a quick restart:

pihole restartdns

The Payoff: Rapid Network Deployment

Now for the fun part. Connect a machine to your network, hammer the F12 key (or whatever opens your boot menu), and select “Network Boot.”

The machine will grab an IP, fetch the bootloader via TFTP, and present a blue menu. I recently used this to wipe three old laptops and convert them into a k3s cluster. Instead of swapping drives, I booted all three simultaneously, selected ‘Ubuntu 24.04’, and let them pull the installer over the wire. It took less than 12 minutes to get all three to a login prompt.

Eliminating Internet Lag with Local Assets

Booting a 2GB Live ISO directly from the internet is fine if you have fiber, but it’s painful on slower connections. Netboot.xyz solves this with “Local Assets.” In the Web UI, navigate to the Local Assets tab. You can pre-download the distributions you use most frequently directly to your server’s /assets folder.

This transforms a 15-minute wait into a 30-second burst over your local network. It’s an absolute game-changer for anyone who frequently tests different distros or needs to run a quick MemTest86 on a new piece of hardware.

Treat Your HomeLab Like a Data Center

Switching to Netboot.xyz isn’t just about convenience; it’s about shifting your mindset. By centralizing your boot environment, you eliminate friction and ensure you’re always using the latest, most secure OS versions. It takes about 20 minutes to set up, but the time you’ll save over the next year is massive. Your USB drawer can finally be retired for good.