About Beaconbox

What this site is

Beaconbox is a build log for a single home rack: one Raspberry Pi 4B with 8 GB of RAM, a 2 TB USB SSD, and a stack of containers that handles DNS, media, files, monitoring and remote access for a household of four. Every page here describes something that actually runs on that machine, with the same image tag, the same ports and the same volume path that are in service.

It is written for people who have already flashed an SD card and want the next forty decisions made for them: which port to give a service so it does not collide, how much RAM to reserve so the Pi does not swap, and what breaks when the board reboots with an unclean shutdown.

How an entry is written

Every entry starts by running the service for at least three weeks on the reference Pi before anything is published. That settling period is what turns a container that starts into a container that survives: the memory figure quoted is the settled peak from docker stats plus roughly thirty percent headroom, not the number printed in a project README.

Ports are chosen so two services never fight. Where a project has a well-known default it keeps it, because a documented port beats a tidy one — Grafana stays on 3000, Immich on 2283, Home Assistant on 8123, Navidrome on 4533. Everything else comes from three bands that are visible in the number itself: 53xx for DNS, 80xx for web front ends sitting behind Caddy, and 22xxx for file sync. Caddy holds 80 and 443 and is the one thing on this rack that ever faces the internet.

Anything that failed is written down. The "what bit us" box on a detail page is the part people actually need: the SD card that died after eighteen months of write-heavy logging, the arm64 image that silently fell back to emulation and ran four times slower, the DNS container that took the whole house offline when it started before the network was up.

The reference rack

Board: Raspberry Pi 4B, 8 GB, passive cooling in a metal case, booting from USB SSD rather than an SD card because the card is the single most common failure point in a Pi that runs continuously.

Software: 64-bit Raspberry Pi OS (Bookworm), kernel 6.6, Docker Engine with the compose plugin, and no orchestration layer beyond that. Kubernetes on one node is a second job, not a hobby project.

Power: one 5 V 3 A supply per board and a 60 W USB-C charger for the SSD enclosure, on a small UPS so a brownout does not corrupt the filesystem mid-write.

Publication schedule

Entries are published on a schedule rather than in one dump, and entries whose date has not arrived are not listed, not searchable and not in the sitemap — their URLs return a 404 until their day. What you can read today is what has been verified today.

Corrections

If a step does not work on your board, write to [email protected] with the entry name, your board revision and the kernel you are on. Reports that include the exact error line get fixed first, and the entry date is updated whenever the substance changes.