Four Raspberry Pis, Run Amuck Into Production
A cluster of four Raspberry Pi 5s — 8GB each, booting off NVMe SSDs, wired together — running containers as a single pool instead of four separate little computers. The pitch is simple: a service runs on any node, and it moves when a node dies or gets rebooted. That movement is the whole point.
The easy part is getting four Pis to run containers. The hard part is making the data follow the container.
The bar
This began as a homelab, but it isn’t being treated like one anymore. “A homelab run amuck into production” is the phrase we keep coming back to, and it’s a real bar: the thing has to work, not just look good in a screenshot.
Three constraints fall out of that.
- Storage has to be shared and replicated. A workload’s data can’t live stranded on one SD card waiting for that card to fail.
- The cluster is never the only copy. There’s an x86 anchor holding the authoritative data, and offsite backups behind it.
- Recovery has to be boring. A node should be replaceable without heroics — pull it, put in another, move on.
The storage problem is the whole problem
Orchestration solved “run this on one of N machines” years ago. It still hasn’t made “and the data follows” easy, and that’s the actual design decision here.
Two paths are on the table. Docker Swarm is simple and dependable, but it has no native answer for shared storage — you mount a replicated filesystem (CephFS) on every node and accept that as the data story. Kubernetes, via K3s with Rook-Ceph, gives you proper replicated block volumes that follow a pod, but it’s a lot of machinery for four little computers.
A wrinkle the Pi 5 throws at us
The Raspberry Pi 5’s firmware force-disables the kernel’s memory cgroup on every boot. For Docker that’s an annoyance — you lose memory limits. For Kubernetes it’s a hard stop, because kubelet refuses to start without it. It’s a known firmware quirk, and it quietly tips the scale toward the simpler orchestrator.
Where it stands
Two Pi 5 hosts are already running Docker, waiting to be joined into a swarm. A third — a repurposed kitchen dashboard — is booting off its SSD in the wings. A fourth arrives this week. The SSDs land Friday, and then the real work starts: move each node onto its new disk, initialize the swarm, and prove a service actually survives a node going down.
