At home I run a k3s cluster — the lightweight Kubernetes distribution, built for modest hardware and ARM — on Raspberry Pi. It’s the same homelab I already mentioned on the About page: the guinea pig for anything I want to try before it gets anywhere near production.
Simplified, illustrative topology — the actual node count varies; what matters here is the relationship between the cluster and production, not an inventory.
What runs there
There’s no fixed list — that’s the nature of a testing ground: this site’s tools pass through before they reach someone else’s browser, configs I want to validate before taking them to work, and attack-infrastructure setups for lab and CTF practice (the ATT&CK heatmap maps that practice to MITRE ATT&CK’s Acquire Infrastructure technique, at the “occasional experience / lab” level). The common thread is always the same: nothing touches production without going through here first.
Why k3s
A Raspberry Pi doesn’t have the footprint for a “full” Kubernetes — k3s exists exactly for this: the same Kubernetes API, with etcd, legacy controllers, and unnecessary dependencies stripped out to fit low-power ARM hardware. I get practice with the patterns that matter in production — multi-node, scheduling, tolerating a lost node — in an environment cheap enough to break for free.
Technical decisions
- A cluster, not a standalone Pi. A single node only tests “does the container run”; several nodes test what actually fails in production — losing a node, scheduling under resource pressure, tolerating restarts.
- Deliberate isolation from production. The homelab has no access to anything that matters outside it; it’s disposable by construction, so it can be torn down and rebuilt without ceremony.
- No fixed public exposure. There’s no subdomain pointing at the homelab
yet (see
docs/dns-tls.mdin this repo) — whether and when that makes sense gets decided without compromising the main domain’s HSTS preload policy in the meantime.