Network Boot a Raspberry Pi Fleet: Diskless PXE/NFS Boot for Clusters and Print Farms

Anyone running more than two or three Raspberry Pis — a K3s cluster, a bank of print-farm controllers, a stack of sensor nodes — eventually hits the same annoyance: every unit needs its own SD card, SD cards are the most failure-prone component in the whole setup, and re-imaging a fleet by hand means physically pulling cards one at a time. Raspberry Pi 3B+ and later support genuine network booting: no SD card at all, with the OS served live from a central server over the network every time the Pi powers on. It sounds like a lot of infrastructure for a hobby project, but it's a well-supported, officially documented feature, and once it's set up, adding, re-imaging, or recovering a Pi in the fleet becomes a matter of editing files on the server rather than touching hardware.

Why Netboot Instead of Just Better SD Cards

No SD card failures. SD cards are consumer flash rated for a modest number of write cycles; a Pi doing constant logging, database writes, or container churn (Docker/K3s especially) wears through cheap cards faster than most people expect. Netboot moves that wear to the server's storage, which you can build with proper enterprise-grade SSDs and redundancy.
Centralized fleet management. One root filesystem image (or one per Pi, if they diverge) served from the network means an OS update, a config change, or a full re-image happens once on the server instead of once per unit.
Faster recovery. A corrupted or misbehaving Pi in a netboot setup is fixed by resetting its server-side image, not by finding a spare SD card and re-flashing on a workbench.

This complements, rather than replaces, fleet configuration tools — see our Managing a Fleet of Raspberry Pis with Ansible guide for the config-management side once your Pis are up and running; netboot solves the boot-media problem, Ansible solves the ongoing-configuration problem.

How It Works

A Raspberry Pi's bootloader, when set to network boot mode, sends a DHCP request that includes PXE-style boot options. A DHCP server on your network (or the netboot server acting as one for a dedicated subnet) responds with the location of a TFTP server holding the boot files. The Pi pulls its bootloader stage and kernel over TFTP, then mounts its root filesystem over NFS from the same or a different server. From the Pi's perspective at runtime, it behaves like a normal Linux system — the difference is entirely in where the filesystem physically lives.

Server-Side Setup

The server (which can itself be another Raspberry Pi, though a small x86 box or an always-on Pi 4/5 with a proper SSD works better for serving multiple clients) needs three services:

ServiceRole DHCP (dnsmasq is the common choice)Assigns IP addresses and points netboot clients to the TFTP server — can run alongside your existing router's DHCP using vendor-class filtering so it only answers PXE requests, or on a dedicated isolated subnet TFTPServes the Pi's bootloader files and kernel/initramfs NFSServes the actual root filesystem the Pi boots into and runs from

dnsmasq conveniently bundles DHCP, TFTP, and PXE-filtering support in one daemon, which is why most netboot guides for the Pi standardize on it rather than running three separate services. A minimal dnsmasq.conf for a dedicated netboot subnet needs the interface bound, a DHCP range, enable-tftp, and a tftp-root pointing at the boot files directory.

Preparing the Pi's Bootloader

On Pi 4 and Pi 5, network boot support lives in the bootloader EEPROM rather than requiring a special SD card image just to enable it. Boot the target Pi once from a normal SD card, use raspi-config to set Boot Order to "Network Boot," and the EEPROM configuration persists — after that, the SD card can be removed entirely and the Pi will boot from network on every subsequent power-up, retrying until it finds a valid DHCP/TFTP response.

Preparing the Root Filesystem

The most common approach is to image a normal Raspberry Pi OS SD card once, then copy its contents to the NFS export directory on the server, adjusting /boot/cmdline.txt to point the root filesystem at the NFS export (root=/dev/nfs nfsroot=<server-ip>:/exported/path,vers=3 and the corresponding IP config) rather than a local SD partition. Each Pi needs its own export directory if they'll run independent, writable root filesystems — cloning one golden image directory per Pi is the simplest way to get started, even though it duplicates storage, before you invest in anything more elaborate like an overlay/read-only shared base image with per-node writable layers.

Practical Considerations

Network dependency is now a single point of failure. If the netboot server goes down, every diskless Pi goes down with it — this is the trade-off for centralization, and it means the server itself deserves the reliability investment (a proper SSD, maybe a UPS) that you'd otherwise have spread across individual SD cards.
Gigabit wired networking matters. NFS-served root filesystems over Wi-Fi are workable for light-duty nodes but noticeably slower for anything doing real disk I/O — a print farm controller or database-backed service benefits from wired Ethernet to each netbooted Pi and to the server.
Boot storms. If you power-cycle the whole fleet at once (after a shop-wide outage, for instance), every Pi hitting the DHCP/TFTP/NFS server simultaneously can bottleneck the boot process — staggering power-up, or accepting a slower simultaneous boot, is worth planning for on larger fleets.

A Lighter-Weight Alternative

If full diskless netboot feels like more infrastructure than your fleet size justifies, a middle ground is booting normally from a small SD card or eMMC that holds only the bootloader and kernel, with the bulk of the writable filesystem — logs, application data, container storage — mounted from a network share. This gets most of the "SD card doesn't wear out from heavy writes" benefit without the full server-dependency of true netboot, and it's a reasonable first step before committing a fleet fully to diskless operation.

Full network boot is overkill for one or two Pis, but the moment a project scales to a real fleet — a cluster, a bank of identical sensor nodes, or controllers spread around a shop — the SD-card-per-unit model starts costing real maintenance time. Netboot trades a bit of upfront server setup for a fleet that's far easier to manage, recover, and standardize going forward.

Related Guides

Loading_