thim.dev/blog
AUG 2026 · 9 MIN READ

My homelab, end to end

People ask what a homelab is for, and the honest answer is that mine started as somewhere to break things and quietly became the thing the house runs on. The photos are on it. The heating runs off it. An outage is no longer a learning experience, it is a problem.

So it gets treated like production, with one difference: I am the entire on-call rotation, and change management is a conversation with myself that I usually win.

This is the whole thing, top to bottom. This post is the map; individual pieces get their own deep dives, and the first one is already written.

§ The shape of it

internet, out there a rented VPS vets visitors the only public address wireguard, dialled from inside THE HOUSE 01THE NETWORK gateway switches ×4 wifi ×2 02THE ENGINE ROOM node 1 node 2 node 3 three used desktops, working as one any one can fail; everything keeps running storage lane nfs + nvme-of only 03THE ARCHIVE the NAS zfs: every file, checked twice snapshots, so mistakes can be undone 04THE WORKLOADS fifteen guests do the actual work: nine shuffle media around, one runs the house, one checks identities, two host game nights, one is an experiment, and the red one serves the page you are reading underneath it all: eleven network segments, one per trust level mgmt trust iot media qrtn guest srv store work games spare iot keeps the wine fridge company; the robot vacuum sits in quarantine, on probation = this website = a guest the moving square is one visit nothing at home listens to the internet

That is the whole lab on one map: the network gear, the three nodes, the NAS and its disks, all fifteen guests, and the eleven segments underneath. The only thing outside the house is the rented VPS that vets visitors, joined to it by a tunnel dialled from the inside. The red square making its way across the map is one visit arriving: down the tunnel, through a node, and out to the red guest in the grid, which is the container serving the page you are reading.

Two things about that are worth stating plainly, because they are the load bearing decisions. The tunnel is dialled outward, so there is nothing to port forward and nothing at home listening to the internet. And the tunnel client runs on all three nodes, so ingress does not depend on any single machine being up. Reboot a node and traffic keeps arriving.

§ The hardware is boring on purpose

Three second-hand small form factor office desktops. The kind companies lease for three years and then sell by the pallet. Between them they cost less than a single purpose-built server would have, they draw very little power, and they are quiet enough to live in a cupboard.

Alongside them, a NAS with a stack of spinning disks, and a modest pile of networking gear: a gateway, a few switches, a couple of access points.

That is it. There is no rack, no rails, no redundant power. The interesting part of a homelab is almost never the hardware, and buying expensive equipment is the most common way to end up with a very costly appliance that runs the same containers everyone else runs.

§ Compute: a three node cluster

The three desktops run Proxmox as a cluster. Clustering three machines that individually cost less than a phone sounds absurd, and it slightly is, but it buys two real things: one interface to manage everything, and the ability to move a workload off a machine before I open it up.

Almost everything runs as an LXC container rather than a virtual machine. Containers share the host kernel, boot in about a second, and use a fraction of the memory a full VM needs, which matters when your nodes have consumer amounts of RAM. There is exactly one full VM, running the home automation platform, because it wants to be an appliance and it is not worth fighting.

Around fifteen guests, all running. Media, home automation, identity, game servers, a few odds and ends. None of it is exotic.

Guest disks live on local ZFS on each node, which keeps them fast and independent of the network. Bulk data, the things measured in terabytes rather than gigabytes, lives on the NAS and is mounted in. Three nodes is also the smallest number that gives you a real quorum, which is the difference between a cluster and three machines that happen to know about each other.

§ Storage: one job, done properly

A separate NAS running TrueNAS, with ZFS underneath.

ZFS is the one piece of this setup I would call genuinely important rather than merely useful. Checksums on every block mean bit rot gets detected instead of silently propagating into every copy you own. Snapshots are instant and nearly free. If something eats a directory, the previous hour is still there.

The NAS talks to the hypervisors over a dedicated network segment carrying storage traffic and nothing else, so a large transfer and everything else are not competing for the same wire. Two protocols run across it: NFS for the shared datasets that several guests read from, and NVMe-oF for block storage where latency matters more than convenience. Nothing routes into that segment. There is deliberately nothing there to reach.

Backups run on a schedule from the cluster onto the NAS. The full picture there deserves its own post, and it is the piece of this setup I am least smug about.

§ Network: eleven segments and a default of no

The network is the part I have put the most thought into, and it is where most of the interesting decisions live.

Everything is segmented by trust and by job. The workstation and phones are on one segment. Smart home devices are on another, because I have opinions about firmware written by companies that no longer exist. Media devices, guest wifi, and anything I do not trust yet each get their own. The hypervisors and the NAS sit on an infrastructure segment. The containers they host sit on a different one, because a compromised container should not be a step toward the machine running it. Game servers, which accept traffic straight off the internet, are treated as hostile and isolated accordingly.

Underneath all of it, the firewall defaults to no. Nothing reaches anything unless a rule explicitly permits it. That is more work up front and dramatically less thinking later, because the question "what can this device reach" has an answer you can actually read.

Eleven segments is more than most homelabs need and the reasoning behind each one, plus what segmentation genuinely costs to live with, is a post of its own. It is next on the list.

§ Getting in from outside

Nothing at home accepts an inbound connection from the internet. No port forwarding, no open ports on the router, and my home address appears in no DNS record anywhere. A small VPS handles everything public, and a client inside my network dials out to it over a WireGuard tunnel.

That is the short version, and it is the part of this setup I have written most about. Rather than repeat it here: leaving Cloudflare for a VPS I actually control covers why I moved off a managed tunnel, how the routing actually works, and the three things that went wrong doing it. If you read one post on this site, make it that one.

§ Identity: one door

Anything I expose is either public on purpose or behind single sign-on, and the sign-on is handled by Authentik rather than by each application's own login page.

This is the single best quality of life improvement in the whole setup. Self-hosted applications have wildly variable ideas about authentication. Some are excellent. Some store passwords in a way you would rather not know about. Putting one identity layer in front means the weakest application's login page is no longer the thing standing between the internet and my data, and it means turning off access for a person is one action rather than fifteen.

§ What actually runs on it

The honest inventory, roughly in order of how badly it would be missed:

  • Home automation. Lights, heating, sensors, the things that make a house annoying when they stop.
  • Media. A server and the usual constellation of tools that keep a library organised.
  • Books and reading. Tracking, and a place to put things.
  • Game servers. Small ones, for friends. This is the only thing accepting raw internet traffic.
  • Identity and ingress. The plumbing above, which counts as workload too.
  • This website. The thing you are reading is served from a container in that cupboard.

Nothing here is unusual. That is rather the point: the value is not in running rare software, it is in running ordinary software somewhere you fully control.

§ Two conventions that make it manageable

Addresses mean something. Every guest's address ends in its hypervisor guest ID. Guest 104 lives at .104. Pinned by reservation, so it is enforced rather than hoped for. It sounds like nothing. It means a log line, a firewall hit or a traffic graph identifies itself without a lookup, and it is the highest value per minute of effort of anything I have done.

Nothing lives only in my head. There is a git repository describing the whole lab: what each host is, how the network is laid out, what talks to what, and what state everything was last verified in. Not automation, just documentation that gets updated when reality changes. Homelabs rot in exactly one way, which is that the person who built them forgets why. Writing it down is cheaper than remembering.

§ What this cost

Under a thousand euros of hardware, most of it second-hand, plus a few euros a month for the VPS and a domain. The electricity is the ongoing cost and it is modest, because small form factor desktops idle at very little.

The real cost is time, and the honest accounting is that I spend more time on it than strictly justified by what it does. That is fine. It is also where I have learned most of what I know about the things I get paid to have opinions about, which makes it the most cost-effective training budget I have ever had.

§ What is next

This was the map. The territory has a few areas worth their own post, and I will get to them in roughly this order:

  • Network segmentation in detail. The eleven segments, the default-deny model, and what it actually costs to run.
  • Storage and backups. ZFS, snapshots, and an honest look at a backup strategy that is not as good as it should be.
  • Identity. Putting single sign-on in front of software that never expected it.
  • The boring operational stuff. Updates, monitoring, and what breaks when you are not looking.

If there is a piece of this you would rather I started with, tell me.