2026.09.18
netboot.xyz: A Central Network Boot Menu for OS Installation
netboot.xyz uses iPXE to place operating-system installers and utility disks behind a network boot menu. It suits labs, bare-metal operations, and repeatable installations, but deployment requires careful validation of firmware, architecture, network boot paths, and self-hosting maintenance.
What it does
netboot.xyz is a network-based operating-system installer built on iPXE. It organizes operating systems and utility disks behind a single boot menu, reducing the need to retrieve and prepare a separate ISO for every installation. The project describes a menu that can be reached from the BIOS environment and can expose version choices or boot flags for selected systems.
Who it suits
The project is a practical fit for administrators managing multiple bare-metal systems, virtualization hosts, homelab equipment, or test machines. Development and operations teams that reinstall different distributions regularly may also benefit from a centrally maintained menu. Environments that already understand PXE, DHCP, or iPXE are likely to have an easier starting point. Individual users can boot an ISO, USB image, or another supported medium, but still need to understand firmware modes, network booting, and target architecture.
Documented capabilities
The project publishes several iPXE boot artifacts. These include combined ISO and USB images for Legacy PCBIOS and UEFI, plus separate Legacy, UEFI, ARM64, and Raspberry Pi 4 options. The README also lists variants for GRUB/EXTLINUX, DHCP, and Simple Network Protocol scenarios. For certain USB keyboard or network-card problems, legacy builds exclude USB network drivers.
netboot.xyz can also be self-hosted. According to the project README, Ansible templates can generate and customize a hosted environment, while Docker can be used for the build process. The project supports local overrides through user_overrides.yml, including changes to boot mirror URLs used when menus are rendered, and it supports custom menu templates. The README also points to SHA256 checksum files for checking generated iPXE artifacts.
Release 3.0.3 added a Proxmox VE arm64 installer, NixOS 26.05, nixos-unstable, and Mageia 10. It also changed Proxmox menu entries and boot targets to account for architecture. Support changes over time, so the operating-system list in the README should not be treated as a permanent inventory.
Limits and deployment considerations
Network boot is not a single-file deployment. Firmware mode, CPU architecture, DHCP/TFTP or chain-loading paths, network drivers, and menu targets must align. Although netboot.xyz publishes multiple image variants, the sources do not confirm compatibility for every hardware combination. Test the complete boot path on the device classes that matter before wider adoption.
HTTPS also requires explicit review. The README states that default iPXE builds do not compile in HTTPS support, even though loading through HTTPS is described as possible. Teams should therefore review boot URLs, network segmentation, image origins, and transport protection rather than assuming that every distributed artifact has HTTPS support enabled.
Self-hosting transfers responsibility for updates, menu generation, image availability, architecture filtering, and artifact verification to the operator. Changes in user_overrides.yml are part of the deployment configuration. The README also notes that edits made directly to boot.cfg are not preserved when the menu is redeployed. Repository metadata identifies Apache License 2.0, but organizations should still review the repository license file and their own compliance requirements before adoption.
Sources
Sources checked: 2026-09-18