My Homelab, Mapped: The Infrastructure, the Network, and the Applications

How I run my house’s “IT department” — and the why, what, and how behind every layer.

Every smart home needs a brain. Mine lives in a 4-node Proxmox cluster sitting in a basement rack beside a 4-drive TrueNAS storage box and a patch panel’s worth of UniFi gear. Over the years this grew from a single NUC running a router into a small but real data center — recognizable to anyone who runs infrastructure, just scaled down and a lot more fun to own.

This is a tour of how it’s laid out, told in three layers: infrastructure, network, and applications. And it’s not a dry inventory — the layout isn’t an accident. Every piece exists because I hit a problem and learned from it, so I’ll cover the what, the why, and the how of each.

Infrastructure — the physical compute and storage

What: four quiet little fanless PCs running Proxmox VE 9.2, plus a fifth standalone server for AI workloads and a TrueNAS SCALE box for storage. Together they carry everything the house runs.

Why: the short answer is cheap hardware. A handful of used mini PCs costs about as much as one mid-range tower — and they’re not very powerful either, each one a low-end chip with a dozen-odd gigabytes of RAM. That’s fine, because a homelab’s workloads are light: a router, a media box, a home-automation brain, a couple of containers. None of it needs serious compute. What the fleet buys you instead is resilience and room to tinker. A single machine is a single point of failure — one box, one drive, one power supply, and the whole home network is down with it. A cluster means one node can fail and the rest keep running. And it’s where you actually learn about distributed infrastructure — shared storage, guest migration, quorum — at a price that makes it a hobby instead of a capital project.

How: the four mini-PCs make up the compute layer. They’re quorate — all four online and agreeing — but I deliberately run no automatic failover; if a node dies, its services are down until I move them. That’s a conscious choice: HA adds real complexity, and I’d rather keep downtime controlled and manual than let the system make surprising decisions on its own. It’s a sandbox, not a hospital.

Here’s the actual hardware behind each machine:

The storage box deserves its own note: it’s a QNAP TS-453D — off-the-shelf 4-bay NAS hardware — but I replaced its native QNAP OS with TrueNAS SCALE. That’s the kind of thing that makes this a teaching lab: you don’t need exotic gear to learn, you take hardware people actually own and run open-source software on it. Four 4 TB drives in a RAIDZ1 pool (one drive of parity), a 512 GB NVMe boot/cache drive, and it backs everything — VMs, media, file shares, Nextcloud, Time Machine backups, the Frigate camera footage, and this vault.

The four cluster nodes are all small, quiet, low-power mini PCs — deliberately. The whole compute fleet sips power and runs fanless, which is the right trade for a home where the rack lives in a living space. The router node is notably modest (8.2 GB, a low-end Celeron) because routing and firewalling need almost nothing; the workhorse carries the bulk of the guests.

The fifth box is the outlier: a hand-built desktop I assembled myself — the only machine in the fleet that isn’t an off-the-shelf mini PC. It deliberately sits outside the cluster. It runs my AI workloads (Ollama for local LLM inference plus the Open WebUI chat front end, driven by an NVIDIA RTX 3060 passed straight through to the containers) and hosts this very knowledge vault and the agent-memory pipeline built on top of it. Keeping it standalone means a cluster experiment can’t take my AI box or notes down with it.

Networking hardware is UniFi throughout — and it’s the one stack I want to call out by name, because it used to be messier. Wi-Fi is two U6-Pro access points (one on the 2nd floor, one in the basement) running Wi-Fi 6 — a deliberate replacement of the old BeaconHD mesh, which gave way when I outgrew consumer hardware. Wired is three managed UniFi switches (main closet, basement, office) that carry the VLAN tagging, power-over-Ethernet, and per-port segmentation that tie the whole network together. There’s also one unmanaged PoE switch that fans out power to the wired security cameras off a single port on the basement switch — the low-cost option for a handful of endpoints that all share one VLAN and don’t need managed features. Rounding out the fleet are two standalone appliances: an HP LaserJet printer and an out-of-band console for remote server access.

Network — five neighborhoods, one street

What: OPNsense, a FreeBSD-based open-source router/firewall, routing between five isolated VLANs.

Why: the network is where a homelab either stays a hobby or starts to teach real discipline. Segmentation is the difference between a fun box of gadgets and something you’d actually trust with your family’s data.

How: OPNsense replaced the stock UniFi Dream Machine router, and it was one of the best upgrades I made — full control over routing and firewall rules. It splits the house into five VLANs, each an isolated neighborhood that can only reach the others through the firewall:

• ITDevices — the homelab infrastructure itself (Proxmox guests, TrueNAS). The largest and most sensitive neighborhood.
• TrustedDevices — family phones, laptops, tablets
• StreamingDevices — TVs, media streamers, speakers
• IOTDevices — the 100+ smart-home gadgets. The biggest by device count.
• GuestNet — a clean, internet-only lane for visitors

Why segment so aggressively? A smart bulb is a computer with a network connection and, often, terrible security. By quarantining all the IoT gadgets into their own VLAN with strict firewall rules, a hacked light bulb becomes a nuisance in its own neighborhood — not a beachhead into your family’s devices or your files. It’s the same zero-trust instinct, enforced on a bulb instead of a server.

The UniFi gear is what makes the segmentation reach the edge. The managed switches tag each port with the right VLAN (the basement switch, for instance, sends the security cameras to the IOT neighborhood and the NVR to the IT neighborhood on different ports), and the two access points hand out separate SSIDs per VLAN so wireless devices land in the right neighborhood too. The whole thing is orchestrated by a UniFi OS Server VM on the cluster — my own controller, rather than a cloud box — so all five managed UniFi devices are controlled from one place (the unmanaged PoE switch just passes traffic through, so it needs no controller at all).

Here’s the whole network at a glance:

The five VLANs never meet except inside the firewall — traffic between neighborhoods has to cross OPNsense, which is exactly where the isolation happens.

Applications — the virtualization fleet and the services on top

What: the 4 physical boxes host 11 guests — 5 full VMs and 6 LXC containers — running everything from home automation to media streaming to identity.

Why: I use two virtualization flavors because they suit different jobs. Containers are lightweight, share the host kernel, and are perfect for single-purpose services. Full VMs are isolated emulated computers, right for things like the router and automation brain that need separation or direct hardware access.

How: here’s the roster:

You’ll notice I try to give each service its own container instead of stacking everything into one big server. That’s the same reason you microservice a real platform — a crash or an update in one doesn’t take down the others, and each service is simple to reason about in isolation.

Here’s how the 11 guests are spread across the four nodes:

Home Assistant sits alone on its own node with its four USB radios — the one workload that must never go down with a neighbour. OPNsense is likewise dedicated, single-purpose. Everything else clusters on node 1, the workhorse.

Not every workload lives in the cluster. The standalone box runs its own Docker workloads — Ollama (local LLM inference with GPU passthrough) and Open WebUI (the chat front end) — as one Compose stack. The rule is simple: the cluster holds the home’s “production” services; the standalone box holds the AI experiments I don’t want tangled up with them.

At the top of the application stack sits Home Assistant, running 3,281 entities across 474 devices — the lights, climate, security cameras, voice, and presence tracking that make up the “smart” in the smart home. It speaks Zigbee, Z-Wave, and MQTT, and feeds 7 cameras into Frigate for on-device AI detection (person at the door, package left, and so on).

Externally, I reach my own services from anywhere through a zero-trust setup: a Cloudflare Tunnel gives encrypted remote access without opening a single port, and Authentik provides single sign-on in front of it. No port-forwarding, no exposed attack surface — just authenticate through SSO and ride the tunnel.

Why this layout, in one line

None of it came from a blueprint. It grew one problem at a time: the router too locked-down, so I built my own; the cameras filling a disk, so I added Frigate with a TPU; a house full of insecure smart bulbs, so I quarantined them; family devices that need safe remote access, so I stood up a tunnel and SSO.

For me the homelab is a sandbox — a place to learn, at small scale and with real stakes but low blast radius, the same concepts that power big-name services. Networking, virtualization, zero-trust identity, backups. The layout you see here isn’t the destination; it’s the current version of a running experiment.

And honestly, that’s the best kind of homelab: one that’s never really finished.