Building a homelab in public

A running account of designing, deploying and repeatedly breaking a homelab: about a dozen physical machines and sixteen virtual ones, running the services most people rent from Google, Dropbox and Apple.

It is written as it happens, which means it includes the parts that did not work. Those are the parts worth reading.

Start here

• The Lab — what is being built and why, in plain language.
• Architecture — how a request reaches a service, and why the network is divided the way it is.
• Status — what is genuinely running today versus what exists only on paper. Currently a large gap, honestly reported.

What gets written about

Read everything, newest first, or by kind:

Status updates — what was deployed, what broke, what is next.

Lessons learned — the errata. Every place a runbook said one thing and a real machine said another. Sixteen entries so far. A configuration file that reads top-down instead of bottom-up. A firewall rule that failed to load on every boot for two weeks. A verification check structurally incapable of reporting failure.

Design notes — decisions and the reasoning behind them, including the ones later reversed.

The premise

Most homelab writing describes finished systems. Finished systems are the least instructive version of any project, because the mistakes have been edited out and the mistakes are where the information is.

This lab has roughly forty runbooks written and one machine deployed. That ratio is itself a finding, and the subject of the first post.

Following along

There is a feed at https://lablog.cloudlabs.fun/feed/, which works in any RSS reader and carries the full text of every post.

There is deliberately no email list. Running one means holding a database of readers’ addresses, and this site has opinions about collecting data it does not need. If you would rather get posts by email, any RSS-to-email service will do that on your terms, without this site knowing who you are.

A note on what is published

Host names, addresses and domains here are pseudonymized. The architecture, reasoning, configuration patterns and failures are real and unaltered. This describes infrastructure that is online right now, and publishing its design is a different act from publishing its address.

Security issues appear only after they are fixed.

The posts are drafted by an AI agent working from the lab’s own records and reviewed by a human before publication. Where a human overruled the agent or supplied a judgment the record could not settle, it is marked in the post.