Set Up Netboot.xyz as a Self-Hosted PXE Boot Server

Boot Any OS Over the Network, Without a USB Drive in Sight

Netboot.xyz is an open-source PXE boot server that lets you load operating system installers directly over your local network. Instead of burning ISO files to USB drives and walking them from machine to machine, you serve the boot menu from a central host and let each client pull whatever installer it needs. This works for dozens of distributions – Ubuntu, Debian, Fedora, Arch, Windows PE, FreeBSD, and a growing list of utilities like Memtest86+ and GParted Live.

Setting it up as a self-hosted service gives you full control over what appears in the boot menu, lets you cache ISO files locally so installers load faster, and removes the dependency on external servers during a deployment. For home labs, small businesses, or anyone managing more than two or three machines, the one-time setup pays for itself the first time you need to reinstall an OS at 1am without hunting for a spare USB drive.

What You Need Before You Start

The setup requires a Linux host that will act as the PXE server – a Raspberry Pi, a spare desktop, or any always-on machine on your local network works fine. Docker is the cleanest way to run netboot.xyz because the official image bundles the TFTP server, the web assets, and the configuration interface in one container. You will also need access to your router or a separate DHCP server, because PXE booting relies on DHCP options to point clients toward the boot server. If you are running pfSense, OPNsense, or a similar router OS, this is straightforward. If you are on a consumer router with limited options, you may need to run a dedicated DHCP server like dnsmasq alongside the netboot.xyz container.

Client machines must support PXE boot, which is a BIOS or UEFI option usually labeled “Network Boot” or “PXE Boot.” Most hardware made in the last decade supports it, though some machines require you to disable Secure Boot or change the boot order in firmware settings. Once those prerequisites are confirmed, the actual server setup takes under thirty minutes.

Deploying the Container

Pull the official linuxserver/netbootxyz image. The container exposes three things: a web-based admin interface on port 3000, a TFTP server on port 69 (UDP), and an optional HTTP server on port 80 for serving local assets. A basic Docker Compose file looks like this:

Create a directory for your config files – something like /opt/netbootxyz – then write the compose file. Map ./config to /config inside the container, and if you want to host ISO files locally, map a second volume like ./assets to /assets. Set the network mode to host if you run into TFTP connectivity issues, since UDP-based TFTP can behave unexpectedly behind Docker’s default bridge network. Run docker compose up -d and the container starts immediately.

Once the container is running, open a browser and navigate to http://your-server-ip:3000. The admin panel shows you the boot menu configuration, lets you enable or disable specific OS entries, and provides a file manager for local assets. The default configuration already includes dozens of boot options pointing to upstream mirrors, so you get a working menu without any additional setup.

Configuring DHCP to Point Clients at the Boot Server

This is where most first-time setups stall. PXE booting requires two DHCP options: option 66 (the TFTP server address) and option 67 (the boot filename). The correct filename depends on whether the client is booting in legacy BIOS mode or UEFI mode. For BIOS clients, use netboot.xyz.kpxe. For UEFI clients, use netboot.xyz.efi. Some environments require you to handle both, which is possible in dnsmasq using conditional options based on the client’s architecture identifier sent during the DHCP request.

In dnsmasq, the relevant lines are straightforward. Add dhcp-boot=netboot.xyz.kpxe,,your-server-ip for BIOS clients. For UEFI detection, add a tag-based rule: dhcp-match=set:efi-x86_64,option:client-arch,7 followed by dhcp-boot=tag:efi-x86_64,netboot.xyz.efi,,your-server-ip. Restart dnsmasq after making these changes. If you are configuring this inside pfSense or OPNsense, the same options appear under Services > DHCP Server > Additional BOOTP/DHCP Options, and you enter the values through the GUI rather than a config file.

Network switches occasionally cause problems here. If clients are not receiving the TFTP pointer, check that your switch is not blocking UDP port 69 or that DHCP snooping settings are not filtering the boot options. Plugging the client directly into the same switch as the server is a fast way to rule out layer 2 issues while troubleshooting.

After the DHCP configuration is in place, boot a client machine with network boot selected as the first boot device. Within a few seconds, the machine should receive a DHCP lease with the boot options, download the bootloader from your TFTP server, and display the netboot.xyz menu. From there, every installer and utility listed in the menu is selectable without any additional configuration on the client side.

Hosting Local Assets to Speed Up Installations

By default, netboot.xyz fetches ISO files and kernels from upstream mirrors at boot time, which means installation speed depends on your internet connection. For a single machine, that is acceptable. For repeated deployments or network environments with limited bandwidth, caching assets locally cuts wait times significantly. The assets volume you mapped during container setup becomes the directory where you drop locally cached files.

Download an ISO, place it in your assets directory, then open the admin panel and edit the menu entries for that distribution. The menu files use iPXE scripting syntax, so pointing an entry at a local file means changing the kernel and initrd URLs from the upstream mirror to http://your-server-ip/assets/filename. The admin panel has a built-in editor for these menu files, and the iPXE scripting language is readable enough that modifying an existing entry rarely requires documentation. Ubuntu’s menu entry, for example, is a handful of lines – a kernel path, an initrd path, and a boot command with a few parameters. Swap the paths, save the file, and the next client to boot will pull from your local cache instead of Canonical’s servers.

Local assets also make it practical to host custom or internal tools – a corporate Linux build, a rescue environment with proprietary drivers, or a WinPE image for Windows deployments. As long as the boot image supports PXE loading, it can live in your assets directory and appear in the menu like any other entry. The combination of local caching and a self-hosted menu server is what separates netboot.xyz from just bookmarking the public version – you own the environment, and it works even if your internet connection goes down.

One area that catches people off guard is UEFI Secure Boot compatibility. Many modern machines will refuse to load a bootloader that is not signed by a trusted key, and netboot.xyz’s bootloader is not in the default Secure Boot trust list for most firmware. The practical fix is to disable Secure Boot in the client’s firmware settings before booting over the network. Alternatively, some distributions offer signed PXE bootloaders through their own repos, which can be substituted if turning off Secure Boot is not an option in your environment. The netboot.xyz project documents this limitation openly, and it is worth reading the relevant section before deploying to a fleet of machines where firmware access is limited.