A homelab is a computer lab you run at home, usually on retired enterprise hardware, usually for some mix of learning, self-hosting, and refusing to rent someone else’s computer. This one leans hard toward the third reason.
The short version: about a dozen physical machines and sixteen virtual ones, running the services most people get from Google, Dropbox, and Apple — email, files, photos, notes, media, password management, phone system — plus the monitoring, backup, and identity infrastructure needed to make that a responsible thing to do rather than a hobby project with your family’s photos on it.
It is not finished. That is rather the point of this blog.
What it is made of
Compute
Two servers form a Proxmox cluster — Proxmox being an open-source platform for running many virtual machines on one physical one, the same job the big commercial hypervisors do. One is a Dell R740 with two 10-core Xeons and 192 GB of memory; the other an HP with two older 10-core Xeons and 128 GB. Either one alone could run the whole lab. The second exists so that a failure of the first is an inconvenience rather than an outage.
Two machines have a specific problem: if the network between them breaks, each one sees the other vanish and both may try to take over. A cluster needs an odd number of votes to break that tie, so a third small machine acts purely as a witness — it holds no workloads and casts no shadow on the storage layer. It exists to vote.
Storage
Storage is deliberately split in two, because the two jobs are genuinely different:
- A high-integrity tier on ZFS — eight 2 TB enterprise drives in a layout that survives any two failing, plus SSDs for write acceleration. This holds the small, precious, frequently-written things: the identity database, the password vault, git repositories.
- A bulk tier on a Synology with twelve 12 TB drives. This holds media, photos, documents, and AI model files — large, mostly-read, and in many cases reproducible.
Putting the password vault on the same volume as a media library would work right up until it didn’t.
The edge
Nothing in the house is directly reachable from the internet. Two small rented virtual servers — one in the US, one in Europe — sit in front of everything. They terminate the public connections, and a tunnel runs outward from home to meet them.
The direction matters: the home network opens no inbound ports at all. If someone attacks the public address, they reach a rented VPS holding no data, not a machine in a spare room.
The European server is a standby. If the US one fails, DNS moves and service resumes in about ninety seconds. Video streaming is deliberately excluded from that failover — the transatlantic round trip makes it unwatchable, and showing “unavailable” is more honest than showing “unbearable”.
Everything on top
Identity comes first, and it is worth saying why. Single sign-on — one login for every service — was built before the services it protects, because retrofitting authentication onto a running system is dramatically more work than starting with it. Everything else assumes it exists.
Then: file sync and sharing, photo management, media streaming, document scanning and OCR, email, a phone system, personal finance, RSS, notes, a git server with continuous integration, locally-run language models, and the monitoring and log aggregation that make the rest observable.
The rules it is built to
These are the constraints every decision gets checked against. They are worth reading as a set, because most of them exist to prevent a specific failure:
- Nothing lives only on a VM’s local disk. If a virtual machine is destroyed, nothing of value should be destroyed with it.
- Nothing is exposed to the internet except through the relay. No public admin panels, no public CI endpoints, no public phone-system ports.
- One login everywhere. Single sign-on is the authentication layer, not a per-service afterthought.
- Every web server gets a real certificate — including internal-only ones that no outside user will ever visit. No self-signed certificates, no private certificate authority to distribute and maintain.
- Failover is automatic; failback is always manual. Recovering automatically into a half-fixed primary is a good way to turn one outage into two.
- Configuration lives in version control. Secrets do not.
- The lab network is isolated from production by default — no exceptions without deliberate, explicit configuration. Experiments should not be able to reach the things that matter.
- If it can be rebuilt from the runbooks and the offsite backup, it is protected. Anything else is merely present.
How it is being built
Before any of it was deployed, the whole thing was written down: forty-odd runbooks covering architecture, naming, addressing, and step-by-step build procedure for every component, in dependency order.
Whether that was wise is a genuinely open question, and the subject of the first post on this blog.
Alongside the runbooks are two documents that turned out to matter more:
- A deployment log — what was actually done, on which machine, with what result. Not what was planned. What happened.
- An errata file — every place where a runbook said one thing and reality said another. Sixteen entries so far, each one paid for.
Most of what appears on this blog comes from those two files. They are where the interesting material is, because they are the only two documents that cannot contain wishful thinking.
A note on the details
Host names, addresses, and domains on this site are pseudonymized, consistently and permanently. The architecture, the reasoning, the configuration patterns, and the mistakes are all real and unmodified — but this describes infrastructure that is online right now, and publishing its address is a different act from publishing its design.
See Naming conventions for the scheme, which is published intact, because the scheme is the part you might actually want to steal.