The Pi Swarm Migration: A Progress Check, Not a Victory Lap
A measured look at the home-lab move: restored applications, repaired public routes, monitoring that follows the services, and the work still left to do.
A measured look at the home-lab move: restored applications, repaired public routes, monitoring that follows the services, and the work still left to do.
An honest field report from moving a self-hosted Docker estate onto a four-node Raspberry Pi Swarm: what moved, why Paperclip took two hours, what is currently degraded, and what remains.
A failed first attempt, two genuinely hands-off Sonarr recoveries, and the evidence separating a working recovery controller from another manually launched restore script.
A four-Pi lab recovered Linkding, PostgreSQL-only and Redis-only test workloads in 64.5, 28.9 and 24.4 seconds—with exact snapshots, fenced writers, verified data, and clear limits.
Same Pi, two storage devices, three repeatable read tests: our NVMe SSD delivered 4.9× the sequential throughput and 14.9× the concurrent random-read throughput of microSD.
A container-by-container inspection of both Docker hosts in the estate: which of the 74 containers can be scheduled on any node, and what actually pins the other 64 to one host.
Updated recommendation for two Raspberry Pi 5s and two Raspberry Pi 4s: three active Swarm managers may also carry carefully limited lightweight ARM workloads, while heavy and stateful work stays off the control plane.