All use cases Read in docs
3–6 Pis · arm64-linux · plus one buildx host
Raspberry Pi Home Lab
The shape Portoser was built for. Cheap 24/7 compute, role-based.
First deploy: ~30–45 minutes
Why pick this shape
- Five Pi 4s draw less power than one desktop. Real services, low total wattage.
- The example registry that ships with the repo is built around a 4-Pi + 3-Mac home lab.
- Sequential workloads (knowledge graphs, batch ingestion) idle 85–98% — exactly what Pis handle well.
Registry skeleton
Copy, replace IPs and ssh_user, point CADDY_REGISTRY_PATH at it.
hosts:
pi1:
ip: 192.168.1.51
arch: arm64-linux
ssh_user: pi
roles: [infrastructure, vault]
pi2:
ip: 192.168.1.52
arch: arm64-linux
roles: [databases]
pi3:
ip: 192.168.1.53
arch: arm64-linux
roles: [workflows]
pi4:
ip: 192.168.1.54
arch: arm64-linux
roles: [app_services]
caddy:
host: pi1
ingress_host: pi1
config_path: /etc/caddy/Caddyfile
use_admin_api: trueBringing it up
./portoser cluster setup-buildx # on a beefier machine ./portoser cluster build --all ./portoser cluster deploy --all ./portoser cluster health --watch
Common gotchas
- SD card I/O kills health checks under load. Use a USB 3 SSD on stateful Pis.
- Build images on a buildx host, not on the Pis. They can build, but it is painful.
- One Pi as DNS + Caddy + control plane is a single point of failure. Mirror or move to a Mac mini.
Read the full Raspberry Pi Cluster walkthrough
Deeper version with more code, more gotchas, and links to operations docs.