Booting Over the Network, No USB Required
Every technician who has managed more than a handful of machines eventually hits the same wall: hunting down a USB drive, flashing an ISO, walking it from desk to desk. Netboot.xyz solves that problem by serving bootable operating system installers directly over a local network, pulling live ISO menus from the internet and presenting them through a single PXE boot interface. You select an OS from the menu, it downloads what it needs, and the install begins – no physical media involved.
The tool supports an enormous range of distributions and utilities out of the box, including Ubuntu, Debian, Fedora, Arch Linux, Windows PE environments, and system rescue tools like Clonezilla and Memtest86. Because the menu is dynamically fetched, new releases appear without any manual updates to your local server configuration. For home lab operators or small IT environments, this is the kind of infrastructure that pays off after the second or third machine you need to provision.
Setup takes about thirty minutes if your network already has a DHCP server you can configure.
What You Need Before You Start
Netboot.xyz works by intercepting the PXE boot request that a network-connected machine sends when it finds no bootable local disk – or when you tell it to boot from the network first. Your DHCP server needs to respond to that request by pointing the client toward a TFTP server hosting the netboot.xyz bootloader file. From there, the client loads the menu, picks an option, and the rest happens over HTTP directly from netboot.xyz’s CDN or your own local mirror. The core components you need are: a machine or container running a TFTP server, the netboot.xyz bootloader files, and DHCP server access to set the next-server and filename options.
If you are running a home lab with a NAS or server already on the network, running netboot.xyz as a Docker container is the fastest path. The official linuxserver/netbootxyz image packages the TFTP server, the web assets, and an optional web UI into a single container. If you are running Unraid as your home NAS, you can pull that container directly from Community Applications. If you prefer a bare-metal install or a dedicated VM, the setup requires a TFTP daemon like tftpd-hpa and a manual download of the bootloader files from the netboot.xyz GitHub releases page.
On the DHCP side, you have two options depending on your router or server software. Consumer routers running stock firmware usually cannot set PXE boot options – you will need to either replace the router firmware with something like OpenWrt, disable the router’s DHCP and run dnsmasq or ISC DHCP on a Linux machine, or use a DHCP proxy that only responds to PXE requests without interfering with regular address assignment. The proxy approach is the least disruptive for existing networks and is built into dnsmasq with a single configuration line.
Installing and Configuring Netboot.xyz
If you are going the Docker route, the container launch command is straightforward. You need to expose UDP port 69 for TFTP, TCP port 80 for the web assets, and optionally TCP port 3000 for the web configuration UI. Map a local volume to /config so your custom menu entries and settings survive container restarts. The full command looks like this:
docker run -d –name=netbootxyz –net=host -v /path/to/config:/config -v /path/to/assets:/assets linuxserver/netbootxyz
Using –net=host is important here. TFTP has a quirk where it initiates data transfers from a random high port after the initial connection, and network address translation breaks this handshake unless the container shares the host network stack directly. Once the container is running, navigate to port 3000 in a browser to reach the web UI, where you can enable or disable specific boot menu entries, add local ISO hosting, and review your TFTP root path.
For the DHCP configuration, if you are running dnsmasq, add these two lines to your dnsmasq configuration file: dhcp-boot=netboot.xyz.kpxe,,YOUR_SERVER_IP for legacy BIOS clients and dhcp-boot=tag:efi64,netboot.xyz.efi,,YOUR_SERVER_IP for UEFI clients. The netboot.xyz releases page provides separate bootloader files for BIOS (.kpxe), 32-bit EFI, 64-bit EFI, and ARM. You need the right file in your TFTP root to match the hardware you are booting. UEFI systems are increasingly common, so having both files present and using dnsmasq’s dhcp-match tag to detect the architecture is worth the extra configuration step rather than assuming all clients are the same.
Testing, Local Asset Hosting, and Practical Use
To test, reboot any machine on the network and enter its boot menu – usually F12, F11, or Del depending on the manufacturer – then select Network Boot or PXE Boot. Within a few seconds you should see the netboot.xyz menu load. If the screen stays blank or shows a TFTP timeout error, the most common causes are: the bootloader filename in your DHCP config does not match the actual file in your TFTP root, the TFTP port is being blocked by a host firewall, or the container is not using host networking and the TFTP data transfer is being broken by NAT. Check each of those in order before assuming a deeper configuration problem.
By default, netboot.xyz pulls ISO content directly from the internet during boot, which means the target machine needs a working internet connection and the download speed depends on your WAN bandwidth. For environments where you want faster installs or need to operate air-gapped, the tool supports local asset hosting. You drop ISO files into the mapped assets volume and configure the web UI to point specific menu entries at your local HTTP server instead of the upstream CDN. A 23 GB Windows PE environment or a large Fedora ISO boots noticeably faster from a local gigabit NAS than from a remote server, particularly when provisioning multiple machines at once.
The web UI also lets you write custom iPXE scripts, which opens up more advanced workflows – like auto-answering installer prompts with kickstart or preseed files, or building a custom menu that only shows the three or four options your environment actually uses. iPXE scripting syntax is well-documented on the iPXE project site, and netboot.xyz’s own menu files are open on GitHub, so reading through them gives you a solid model for writing your own entries.
Once it is running, the utility of having netboot.xyz on your network becomes obvious the first time you need to recover a machine at 11pm and the only thing between you and a working system is a two-minute network boot – not a twenty-minute search for a flash drive that may or may not have the right ISO on it.
