Bare-metal server provisioning and network-based OS installation remain essential skills for any homelab or enterprise infrastructure. Instead of physically swapping USB drives between machines, Preboot eXecution Environment (PXE) lets you boot and install operating systems entirely over the network.
This guide compares three leading open-source PXE network boot solutions: iPXE, netboot.xyz, and FOG Project. Whether you’re deploying a [kubernetes cluster on bare metal](../k3s-vs-k0s-vs-talos-linux-self-hosted-kubernetes-guide-2026/) or imaging dozens of workstations, the right PXE tool saves hours of manual setup.
Why Self-Host PXE Network Boot?
Running your own PXE boot infrastructure gives you:
- Zero-touch provisioning — boot new machines with no physical media
- Centralized OS management — one server, dozens of install sources
- Automated deployments — unattended installs with preseed/Kickstart files
- Disk imaging and cloning — capture and restore full disk images over the network
- Disaster recovery — boot rescue environments on any network-connected machine
- Cost savings — no need for KVM switches, USB drives, or physical console access
PXE booting requires a DHCP server to hand out IP addresses and point clients to a TFTP/HTTP server hosting boot images. If you’re already running a self-hosted DHCP server like Kea or dnsmasq, you’re halfway there.
Quick Comparison
| Feature | iPXE | netboot.xyz | FOG Project |
|---|---|---|---|
| Type | Boot firmware | Boot menu aggregator | Imaging & management platform |
| Language | C | Jinja/Shell | PHP |
| GitHub Stars | 1,927 | 11,638 | 1,546 |
| Last Updated | 2026-04-17 | 2026-04-20 | 2026-04-15 |
| Web UI | No | No | Yes |
| Disk Imaging | No | No | Yes |
| OS Support | Any (custom scripts) | 100+ live ISOs | Linux, Windows, macOS |
| Unattended Install | Via iPXE scripts | Via autoinstall files | Via task scheduling |
| Self-Hosted | Yes | Yes (local mirror) | Yes |
| docker Support | No | Community images | No |
| Best For | Firmware-level control | Quick OS testing | Mass deployment & imaging |
iPXE: Open-Source PXE Boot Firmware
iPXE is a drop-in replacement for traditional PXE ROM firmware. It extends the basic PXE protocol with HTTP, iSCSI, FCoE, WoWLAN, and FCoE boot capabilities, plus a powerful scripting engine.
Key Features
- HTTP/HTTPS/iSCSI boot — boot directly from web servers or SAN storage
- Scripting engine — chainload, menus, variables, and conditional logic
- Wireless support — boot over WiFi with WoWLAN
- EFI and legacy BIOS — supports both firmware types
- Embedded scripts — bake your boot config directly into the ROM
How iPXE Works
iPXE replaces or chainloads from your network card’s built-in PXE ROM. When a machine boots, iPXE fetches a boot script (via HTTP or TFTP) that decides what to load next: a Linux kernel, a Windows PE image, or a live ISO.
Installation: Compile iPXE from Source
| |
iPXE Boot Script Example
Create a boot.ipxe script that presents a boot menu:
| |
DHCP Configuration for iPXE
Configure your DHCP server to point PXE clients to iPXE. Here’s a dnsmasq configuration:
| |
For a production setup with Kea DHCP, use this configuration:
| |
netboot.xyz: 100+ Operating Systems in One Boot Menu
netboot.xyz is a network bootable aggregator built on top of iPXE. It provides a single bootable ISO, USB, or PXE image that gives you access to over 100 operating system installers and live environments — all served from their CDN or your own self-hosted mirror.
Key Features
- 100+ OS options — Ubuntu, Debian, Fedora, Arch, Proxmox, TrueNAS, and more
- Live environments — boot directly into RAM without disk installation
- Self-hosted mirror — run your own local copy for air-gapped networks
- Built on iPXE — inherits all iPXE scripting and protocol support
- Multiple boot methods — ISO, USB, PXE, or cloud-init
How netboot.xyz Works
netboot.xyz provides a pre-built iPXE binary that boots to a menu. When you select an OS, it fetches the kernel and initrd directly from upstream mirrors (or your local mirror) and boots them. No local storage of ISOs is required unless you run a self-hosted mirror.
Self-Hosting netboot.xyz
To run netboot.xyz locally, you need an HTTP server to host the menu assets and a TFTP server for the iPXE binary.
##nginxep 1: Set up the HTTP server
| |
Step 2: Configure TFTP for PXE boot
| |
Step 3: Self-hosted iPXE menu configuration
For a fully self-hosted setup, create a custom iPXE script pointing to your local mirror:
| |
Using the netboot.xyz ISO
For quick testing, download the ISO and boot a VM or physical machine:
| |
FOG Project: Complete Imaging & Deployment Platform
FOG Project is a full-featured open-source computer imaging and deployment system. Unlike iPXE and netboot.xyz which focus on booting, FOG provides a complete lifecycle management platform with a web interface for capturing, deploying, and managing disk images across your network.
Key Features
- Web management interface — manage hosts, images, and tasks from a browser
- Disk imaging — capture and deploy full disk images (single-cast and multi-cast)
- Snapin deployment — push software packages, scripts, and files to clients
- Inventory management — auto-discover hardware specs from deployed hosts
- Wake-on-LAN — remotely power on machines for scheduled deployments
- Active Directory integration — auto-join domain after imaging
- Plugin system — extend functionality with custom plugins
Architecture
FOG uses a client-server model:
- FOG Server — Ubuntu/Debian/CentOS server with web UI, TFTP, DHCP, NFS, and MySQL
- FOG Client — Windows/Linux agent running on deployed machines for post-deployment tasks
- Storage Nodes — optional secondary servers for multi-site image distribution
Installation
FOG Project provides an automated installer script:
| |
Post-Installation Configuration
After installation, access the web interface at http://<fog-server>/fog/.
- Default login:
fog/password(change immediately) - Configure storage node: Settings → FOG Configuration → Storage Nodes
- Add host: Hosts → Create New Host → enter MAC address
- Create image: Images → Create New Image → select OS type
- Schedule task: Hosts → Select Host → Task → Deploy/Capture
Multi-Cast Image Deployment
For deploying a single image to multiple machines simultaneously:
| |
FOG PXE Boot Menu Customization
FOG automatically configures iPXE boot menus. You can customize the default boot behavior by editing /tftpboot/default.ipxe:
| |
Choosing the Right PXE Solution
| Scenario | Recommended Tool | Why |
|---|---|---|
| Boot firmware replacement | iPXE | Direct NIC firmware, HTTP/iSCSI boot |
| Testing multiple OSes quickly | netboot.xyz | 100+ installers in one menu |
| Deploying 10+ identical machines | FOG Project | Multi-cast imaging, web UI, AD join |
| Bare-metal Kubernetes cluster | iPXE + custom scripts | Unattended install with preseed files |
| Lab/education environment | netboot.xyz | No local storage needed, quick setup |
| Enterprise workstation imaging | FOG Project | Inventory, snapins, scheduling |
| Air-gapped network | netboot.xyz mirror | Self-hosted ISOs, no internet needed |
| Dual-boot firmware (UEFI + BIOS) | iPXE | Compiles for both architectures |
When to Combine Tools
These tools are complementary, not mutually exclusive. Common combinations:
- iPXE → netboot.xyz: Chainload iPXE into netboot.xyz for the best of both worlds
- iPXE → FOG Project: Use iPXE as the firmware, FOG as the imaging backend
- FOG + custom iPXE scripts: FOG handles imaging, iPXE handles custom boot menus
Deployment Best Practices
- Separate DHCP from PXE — if your router runs DHCP, configure it to point to your PXE server via the
next-serveroption - Use HTTP over TFTP — iPXE supports HTTP fetching, which is significantly faster than TFTP for large kernels
- VLAN isolation — keep PXE boot traffic on a dedicated VLAN to avoid interfering with production DHCP
- Backup your images — FOG Project images are large; store them on a separate disk or NAS
- Test with VMs first — always validate boot scripts in a VM (VirtualBox, KVM) before deploying to physical hardware
- Document your MAC addresses — FOG requires MAC addresses for host registration; maintain a spreadsheet or CMDB
For related reading, see our Proxmox vs XCP-ng virtualization comparison for bare-metal hypervisor options to provision via PXE, and our complete overlay networks guide for connecting remote sites to your PXE infrastructure.
FAQ
What is PXE boot and how does it work?
PXE (Preboot eXecution Environment) is a standard that allows a computer to boot from a network interface rather than a local disk. The process works in stages: the client’s network card broadcasts a DHCP request, the DHCP server responds with an IP address and the location of a boot file (usually via the next-server and filename options), the client fetches the boot file via TFTP, and the bootloader (like iPXE) loads the operating system kernel and initrd.
Can I use PXE boot over WiFi?
Traditional PXE requires an Ethernet connection. However, iPXE supports WoWLAN (Wake on Wireless LAN) and can boot over WiFi if your network card supports it. For most deployments, a wired Ethernet connection is more reliable and recommended.
Do I need a DHCP server for PXE boot?
Yes. PXE boot requires a DHCP server to assign IP addresses and provide the boot file location (next-server and filename DHCP options). You can use your existing router’s DHCP server (by configuring options 66 and 67), or run a dedicated DHCP server like dnsmasq, Kea, or ISC DHCP on your PXE server.
Is netboot.xyz safe to use in production?
netboot.xyz is widely used and open-source. For production or air-gapped environments, you should run a self-hosted mirror of the boot assets rather than relying on the public CDN. This ensures availability even without internet access and gives you full control over the boot images served to your clients.
Can FOG Project image Windows machines?
Yes. FOG Project supports Windows imaging using the ntfsclone or partclone imaging engines. After deploying a Windows image, the FOG Client can handle post-deployment tasks like Active Directory domain join, driver injection, and hostname configuration. Note that Windows licensing compliance is your responsibility.
How fast is multi-cast imaging with FOG?
Multi-cast imaging speed depends on your network bandwidth and the number of clients. On a 1 Gbps network, deploying a 50 GB image to 20 machines simultaneously takes approximately 8-10 minutes (similar to single-cast, since the data is sent once and received by all clients). On 10 Gbps networks, the same deployment completes in under 2 minutes.
What’s the difference between iPXE and standard PXE?
Standard PXE (defined in the Intel PXE specification) only supports TFTP for downloading boot files. iPXE is an open-source implementation that extends PXE with support for HTTP, HTTPS, iSCSI, FCoE, and WoWLAN, plus a built-in scripting language. Most modern systems use iPXE either as a replacement for the built-in PXE ROM or chainloaded from it.
Can I chainload iPXE from my existing PXE ROM?
Yes. Configure your DHCP server to serve undionly.kpxe (the iPXE binary that works with any PXE ROM) as the boot filename. The built-in PXE ROM loads iPXE, which then provides full HTTP, scripting, and menu support. This is the most common iPXE deployment method.