How to Set Up netboot.xyz for PXE Boot: DHCP, Secure Boot and Windows Options

What netboot.xyz actually does​

Netboot.xyz is a network-bootable menu built on iPXE. A client PC fetches a small bootloader over TFTP, shows the netboot.xyz menu, and pulls the files for whatever you pick over the network. The project's own site says it pulls images over HTTP at boot time, with BIOS and UEFI builds for x86_64 and arm64.

The menu covers a lot of ground. According to the project repository, it includes installers or live environments for:

• Debian, Ubuntu, Fedora, Arch, openSUSE, Linux Mint, Zorin OS and many others
• Utilities such as Clonezilla, GParted, SystemRescue, Memtest and Rescuezilla

Windows isn't a straightforward menu item. The project lists Windows as needing user-supplied media.

You can run your own instance. A small Docker container provides the TFTP server, a web app for editing menus, and an NGINX server for hosting assets locally. The web app also lets you mirror boot assets to your own machine for faster loading.

Correction one: use the official container​

The walkthrough's Docker Compose file uses the LinuxServer.io image. LinuxServer's documentation now carries a deprecation notice for that image. It says the image is unsupported and won't be updated. It recommends the official netboot.xyz container, calling it a drop-in replacement.

The official image is available from the GitHub Container Registry and Docker Hub. The project's documentation says the image is updated regularly and is the recommended way to get the latest version:

• ghcr.io/netbootxyz/netbootxyz
• netbootxyz/netbootxyz

A fresh setup looks like this:

1. Install Docker on an always-on machine with a static IP address. The official README says the DHCP server must point at a stable address.
2. Create config and assets folders.
3. Use a Compose file with the official image. Keep the same mappings: 3000:3000 for the web UI, 69:69/udp for TFTP, and 8080:80 for the asset server. Mount /config and /assets to your folders. The official repository also ships a docker-compose.yml.example.
4. Start it with docker compose up -d netbootxyz.
5. Open the web UI at port 3000 on that machine.

The official docs also support a MENU_VERSION variable if you want to pin a specific menu release. If it's unset, the container pulls the latest.

One housekeeping note on the Windows firewall step in the original piece: those PowerShell rules only apply if your Docker host is a Windows machine. They aren't a security review. The web UI and asset server are meant for your local network, so don't expose them to the internet.

The real hurdle: DHCP​

The container does not include a DHCP server. The official documentation says an existing DHCP server must be set up to direct clients to it. Per the README, the two settings that matter are the next-server (TFTP server) and the boot file name.

Pick the right boot file​

Firmware type decides which file the client needs. The official table lists these:

So "kpxe for BIOS, efi for UEFI" is a fair rule of thumb for x86 PCs, but it isn't universal. ARM64 machines need their own file, and some hardware needs the SNP or legacy variants.

Mixed hardware needs architecture matching​

The official dnsmasq example uses dhcp-match rules on the PXE client architecture. It hands out netboot.xyz.kpxe to BIOS clients, netboot.xyz.efi to x86-64 UEFI clients, and netboot.xyz-arm64.efi to ARM64 clients. A single blanket filename will fail on a mixed fleet.

What if your router can't do it?​

Many consumer routers don't expose these options. Firewalls like pfSense and OPNsense do. LinuxServer's docs also give examples for Microsoft Server DHCP, which uses option 066 for the boot server and option 067 for the bootfile name.

If your router is locked down, the original article suggests a proxy-DHCP service such as dnsmasq or Tiny PXE Server. That works in principle, but the piece doesn't give a complete configuration. Installing a proxy tool isn't enough on its own. A second full DHCP server on a home network risks competing address assignment, so test carefully. One community image, dhcp-netboot.xyz, wraps dnsmasq around netboot.xyz. Its notes warn that EFI clients may prompt you to press a key to boot from a DHCP proxy. Treat it as a third-party option.

Correction two: Secure Boot isn't a dead end​

The original article says you must disable Secure Boot because the iPXE binaries aren't signed by Microsoft. That's too blunt for the current official container.

The container's README documents a Secure Boot path. It downloads signed iPXE binaries from the upstream iPXE project, plus an autoexec.ipxe script from netboot.xyz. The documented boot flow works like this:

1. UEFI firmware validates a Microsoft-signed shim.
2. The shim loads iPXE, which is signed by the iPXE Secure Boot CA.
3. iPXE loads autoexec.ipxe.
4. That script chains into the netboot.xyz menu.

To use it, point DHCP at the shim file instead of netboot.xyz.efi. For x86_64, the documented path is secureboot-x86_64/shimx64.efi. ARM64 uses secureboot-arm64/shimaa64.efi. Keep all files in that directory together in the TFTP path. Also note that autoexec.ipxe requires a netboot.xyz release that includes it. If MENU_VERSION pins an older release, the signed binaries still download but the boot script is missing and a warning is logged.

Secure Boot booting the menu is a separate matter from the OS you then launch. Whether a given distro's installer boots under Secure Boot depends on that distro's own signing. That's general UEFI behavior, not something the netboot.xyz documentation addresses.

Windows: where iVentoy comes in​

The article is right that netboot.xyz isn't the easy route for Windows. The project lists Windows as user-supplied media. The article describes needing a WinPE environment, extracted install files and SMB shares.

It recommends iVentoy instead, a PXE/HTTP Boot server from the creator of Ventoy. iVentoy's site says you can boot ISO files directly, with no extraction needed. That quote is from iVentoy's feature list, not the netboot.xyz repo. The same page says the server runs on Windows and Linux and can work alongside a third-party DHCP server. It lists support for 120+ OS types and for x86 BIOS and UEFI clients, including Secure Boot on x86_64.

iVentoy's Secure Boot support comes with limits. Its documentation describes three modes:

• Not supported: best compatibility, but you must disable Secure Boot.
• Standard: works with Secure Boot by default, but can't boot ISOs with unsigned boot loaders and loses some features.
• ByPass: full features, but you must enroll a key on the client at first boot.

iVentoy currently supports only x86_64 clients for Secure Boot, and some machines need the UEFI CA option enabled. Its documentation also covers a Windows "driver missing" problem during setup. That error can mean the network-mounted ISO couldn't be reached, for example because the Windows image lacks the needed NIC driver.

Practical limits to know before you start​

• Wired only, in this workflow. The article says PXE doesn't work over Wi-Fi. For this setup, that's the practical rule. A laptop without Ethernet needs a USB-to-Ethernet adapter that the firmware or iPXE can drive.
• Firmware must allow network boot. Enter the one-time boot menu (the article cites F12, F11 or Del) and pick PXE or network boot.
• Release lag. The author says brand-new distro releases may take time to appear in the menu. The sources checked here confirm a menu-release mechanism but don't verify a specific lag.
• Speed varies. The article claims gigabit LAN boots feel like USB 2.0. No independent measurements back that up. Speed depends on your network, server, chosen image and hardware. Mirroring assets locally should help, since the official README says it can make boots much faster.
• Not for everyone. The official README says that if you don't want to manage iPXE menus, you should use the boot media instead of a container. The project offers USB, ISO and floppy images of the same bootloader.

Who should bother?​

Homelabbers, repair techs and anyone who reinstalls machines often will likely find the one-time DHCP setup worthwhile. If you reinstall once a year and your router can't set boot options, a USB stick is simpler.

If you do go ahead, the order is: official container, static IP for the host, correct boot file for each firmware type, and the Secure Boot shim path if you don't want to disable Secure Boot. For Windows installs, iVentoy is the less painful route.