All use cases

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: true

Bringing 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.

Read in docs