# netboot.xyz: a network boot menu for operating systems, without hunting for ISOs > netboot.xyz is an iPXE-based bootloader and menu that lets you pick an operating system or utility disk from the firmware menu instead of downloading an ISO first. It suits homelab and bare-metal provisioning work, but it is a boot path, not an installer platform. **netbootxyz/netboot.xyz** — Your favorite operating systems in one place. A network-based bootable operating system installer based on iPXE. - Repository: https://github.com/netbootxyz/netboot.xyz - Website: https://netboot.xyz - Stars: 12,327 · Forks: 858 - Language: Jinja - License: Apache-2.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/netbootxyz-netboot-xyz ## The problem netboot.xyz solves for bare-metal and homelab work Most operating system installs start with a download. You fetch an ISO, write it to a USB key or mount it in a virtual CD, boot from it, and repeat the whole cycle when you want a different distribution. netboot.xyz replaces that loop with a menu served over the network. The README describes it as "a convenient place to boot into any type of operating system or utility disk without the need of having to go spend time retrieving the ISO just to run it." The menu is rendered by iPXE inside the firmware, so the choice happens before any OS exists on the machine. The intended audience is people who touch firmware regularly: homelab operators with a Proxmox host or a NAS, sysadmins provisioning bare metal, and anyone using virtual CD or remote console paths on DRAC/iLO, VMware or VirtualBox. The README lists those platforms explicitly for the ISO and floppy image variants. If you install an operating system once a year on a laptop, the setup cost is not repaid. If you cycle through distributions on the same hardware, the menu removes the write-and-reboot step entirely. ## How the iPXE chainload and menu actually work netboot.xyz is a bootloader, not a server-side installer. iPXE provides the network stack and the menu, and the project ships prebuilt iPXE images with an embedded script that points at its own infrastructure. The README gives the chainload form for an existing iPXE setup: you type a chain command and the netboot.xyz kernel loads with the proper options enabled. That is the whole data flow. Firmware loads iPXE, iPXE loads the netboot.xyz kernel, the kernel fetches a menu definition, and selecting an entry downloads that distribution's kernel and initrd or boot image over HTTP. Two constraints follow from this. First, the client needs working network drivers at boot time. The README notes that the standard builds use built-in iPXE NIC drivers, and that a separate undionly variant exists "if you have NIC issues." Second, HTTPS is not available by default: the README states that "by default builds of iPXE do not have HTTPS support compiled in," so the chain commands use plain HTTP unless you build your own iPXE with TLS. The repository itself is a Jinja-templated Ansible project. The top level contains site.yml, roles/, etc/, endpoints.yml, user_overrides.yml and script/, which is the machinery that generates the boot menu and the served files. The Dockerfile confirms the shape: it builds from ghcr.io/netbootxyz/builder, runs ansible-playbook site.yml, and copies the resulting /var/www/html tree into an Alpine runtime image whose entrypoint is /dumper.sh. A Docker image here is a way to generate and serve the boot tree, not a boot server you point firmware at directly. ## Installing netboot.xyz: from a downloaded image to a first boot The fastest path is to download a bootloader and boot it. The README lists the combined legacy and UEFI images at boot.netboot.xyz/ipxe/. For a USB key, the .img file is the one named for that purpose; for a virtual CD or remote console, the .iso. Checksums are published at boot.netboot.xyz/ipxe/netboot.xyz-sha256-checksums.txt, which is worth fetching alongside the image. If you already run iPXE on the network, you do not need an image at all. In legacy (PCBIOS) mode the README gives this command: ```bash chain --autofree http://boot.netboot.xyz/ipxe/netboot.xyz.lkrn ``` In UEFI mode the equivalent is: ```bash chain --autofree http://boot.netboot.xyz/ipxe/netboot.xyz.efi ``` After either command, the netboot.xyz kernel loads and the menu appears. What you should see is a text menu of operating systems and utility disks; from there the selection triggers the download of that entry's boot files. For self-hosting, the README points at the self-hosting documentation and describes the source scripts as Ansible templates that "can be generated and customized to your preference." The repository's Dockerfile shows the containerized route. It takes a build argument to choose between the default and production variable sets, runs the playbook, and packages the generated web root: ```dockerfile ARG NBXYZ_OVERRIDES=default FROM ghcr.io/netbootxyz/builder:latest AS builder COPY . /ansible FROM netbootxyz-production AS netbootxyz-production ENV EXTRA_VARS="--extra-vars @script/netbootxyz-overrides.yml" ``` The README's Ansible section is truncated mid-sentence at "To generate, run", so the exact playbook invocation for a non-Docker self-hosted deployment is not documented in the README. The self-hosting page is the place to look for it, and user_overrides.yml is the file the repository exposes for local customization. ## Where netboot.xyz breaks: keyboards, offline sites and unattended installs The most concrete failure mode is documented in the README itself. Standard iPXE builds include USB NIC drivers, and those drivers disable the BIOS SMM-based USB legacy support that emulates a PS/2 keyboard. The result is a machine where the menu loads and the keyboard does nothing. The project ships a separate legacy bootloader set for exactly this case, and the README says to use it "if your USB keyboard does not work with the standard bootloaders." That is a real trade-off: the legacy set excludes USB NIC drivers, so you may fix the keyboard and lose a network adapter. Which variant works is hardware-specific and cannot be predicted from the documentation. The second limitation is dependency on reachable HTTP infrastructure. The default chain commands fetch from boot.netboot.xyz over plain HTTP. An air-gapped rack, a site with no outbound access, or a network where TLS is mandatory will need a self-hosted tree and a local iPXE build. The README is explicit that HTTPS is not compiled in by default, so a self-hosted deployment over HTTPS requires building iPXE yourself. The third is scope. netboot.xyz boots installers and live environments. It does not carry an inventory, does not push configuration to machines it boots, and does not report on what it installed. If your requirement is unattended provisioning of many identical hosts with post-install configuration, this is the wrong layer. It gets the machine to a menu; everything after that is the operating system's installer or your own automation. ## netboot.xyz compared with Ventoy and FOG Project The closest everyday alternative is Ventoy, and the difference is where the media lives. Ventoy puts a boot menu on a physical USB drive and boots ISO files copied onto that drive's filesystem. It works with no network at all, which makes it better for field work and for machines whose firmware networking is broken. netboot.xyz moves the media to a server: nothing to carry, nothing to re-image when a distribution releases a new version, but every boot depends on a reachable HTTP endpoint and a working NIC driver in firmware. If you are choosing between them, the question is whether the machine you are booting has reliable network boot and whether you want to keep a USB key in your bag. FOG Project sits at the other end of the spectrum. It is a cloning and imaging system: it captures a reference disk image and deploys it to many machines, with its own management interface and client. netboot.xyz does not image disks. It hands control to each distribution's own installer, so every machine gets a fresh install rather than a captured one. For fleet rollouts of an identical configured image, FOG is the tool. For a menu of upstream installers that stays current, netboot.xyz is. Comparing netboot.xyz with iPXE itself is a category error: netboot.xyz is a curated set of iPXE images, scripts and menu content, and the README treats upstream iPXE as the underlying project rather than a rival. ## Maintenance, release cadence and the Apache-2.0 licence The repository is not archived and the last push was on 2026-09-21. Releases are tagged rather than continuous: 3.0.3 on 2026-08-29, 3.0.2 on 2026-05-06, with a 3.0.3-RC published the same day as the final 3.0.3. That is roughly a quarterly cadence across the visible release history, and the default branch is development, which means anyone building from a clone is tracking unreleased changes unless they check out a tag. For self-hosted deployments the upgrade cost is a rebuild of the generated tree: rerun the Ansible playbook or rebuild the Docker image, then re-point clients at the new output. Because the bootloader images and the menu content are generated together, a partial upgrade can leave a client chainloading an image that expects a different menu layout. Pin the release you build from and rebuild the whole tree together. The licence is Apache-2.0. That permits commercial and private use, modification and redistribution, and it includes an explicit patent grant, which matters if you ship a modified bootloader inside a product. It also requires that you keep the licence and notice files and state what you changed. This is a description of the licence text, not legal advice; if you redistribute a modified build, have your own counsel review the NOTICE requirements. Note also that the boot menu links out to third-party distribution images, and those carry their own licences, which the Apache-2.0 grant on this repository does not cover. ## Conclusion Adopt netboot.xyz if you already have DHCP or PXE infrastructure and want a maintained menu of OS installers reachable from firmware, or if you want to self-host the same Ansible-generated tree the public service runs. Skip it if you need a fully offline boot source, a disk-imaging platform, or unattended provisioning with its own inventory. Before rolling it out, verify that the specific bootloader variant matches your firmware (netboot.xyz-snp.efi versus netboot.xyz-snponly.efi versus netboot.xyz-legacy.efi) and that your NIC and USB keyboard behave under it, then pin the release you build from rather than tracking the development branch. ## FAQ ### What is netboot.xyz and what is it used for? It is an iPXE-based bootloader and menu that lets you boot into an operating system or utility disk over the network instead of downloading an ISO first. The README describes it as a convenient place to boot any type of operating system without retrieving the ISO just to run it. ### How do I use netboot.xyz if I already have iPXE running? You chainload the netboot.xyz kernel from your existing iPXE prompt. In legacy mode the README gives chain --autofree http://boot.netboot.xyz/ipxe/netboot.xyz.lkrn, and in UEFI mode chain --autofree http://boot.netboot.xyz/ipxe/netboot.xyz.efi. ### Is netboot.xyz open source? Yes. The repository is licensed under Apache-2.0, and the source scripts for the hosted environment are published as Ansible templates that you can generate and customize for self-hosting. ### What does netboot.xyz do when I select an operating system? The netboot.xyz kernel fetches the menu, and selecting an entry downloads that distribution's kernel and initrd or boot image over HTTP. Control then passes to that distribution's own installer. ### Is netboot.xyz safe to use? The bootloader images are built from the repository's own iPXE build process, and the README points to published SHA256 checksums at boot.netboot.xyz/ipxe/netboot.xyz-sha256-checksums.txt so you can verify a download. The default chain commands use plain HTTP, so on an untrusted network the transport itself is not protected. ## Sources - [License: Apache-2.0](https://github.com/netbootxyz/netboot.xyz/blob/development/LICENSE) - [netbootxyz/netboot.xyz on GitHub](https://github.com/netbootxyz/netboot.xyz) - [Project website](https://netboot.xyz) - [README](https://github.com/netbootxyz/netboot.xyz/blob/development/README.md) - [Releases](https://github.com/netbootxyz/netboot.xyz/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netbootxyz-netboot-xyz