/var/www/xnett.org/homelab/my-homelab-top-to-bottom.md
[HOMELAB]My homelab, top to bottom
Two Proxmox nodes, two Docker hosts, a NAS, UniFi from gateway to access points and one GPU laptop: how my homelab is built and what runs where.
- author:
- Rolf
- date:
- 2026-09-29 22:48
- read:
- ~4 min
Most of what ends up on this site was first broken, fixed and broken again in my homelab. This is the map of that lab: what the hardware is, how the network is split, what runs where, and a few decisions I would make the same way again (and a few I wouldn't).
It is not a showroom rack. It is two small Proxmox nodes, a NAS, a stack of UniFi gear and one GPU laptop that does more work than it should.
The short version
internet
│
[ UniFi gateway ]──── UniFi switches ──── 4 × UniFi access points
│
├── Proxmox node A (i7-4790K, 32 GB) ── Docker host #1, DNS, lab VMs
├── Proxmox node B (i7-7567U, 32 GB) ── Docker host #2, DNS, controller, jumphost
├── NAS (~18 TB) ── media, ISOs, VM backups
└── GPU laptop (RTX 3080 16 GB) ── Ollama, ComfyUIEverything that matters is a VM or a container. The physical boxes are deliberately boring.
Hardware
| Box | CPU | RAM | Role |
|---|---|---|---|
| Proxmox node A | Intel i7-4790K (4c/8t) | 32 GB | The workhorse. Bonded NICs, most of the local disk. |
| Proxmox node B | Intel i7-7567U (2c/4t) | 32 GB | Small-form-factor node. Low power, low core count. |
| NAS | — | — | ~18 TB for media and ISOs, plus an NFS share for backups |
| GPU laptop | RTX 3080 Laptop, 16 GB VRAM | — | Local LLMs and image generation |
A third Proxmox node exists in the cluster config and is currently offline. More on what that means for quorum in the Proxmox write-up.
Network
UniFi end to end: a UniFi gateway, a 24-port core switch, a small 8-port PoE switch, two Flex Minis where I needed a few ports somewhere awkward, and four access points. The controller runs as its own VM, not on the gateway or in a container.
The LAN is split into a default/management network and a separate server VLAN. Hypervisor bridges are VLAN-aware, so a VM's network is one tag in its config rather than a new bridge.
Details in the network article.
Virtualization
Two Proxmox VE nodes in one cluster. VMs are built from AlmaLinux GenericCloud images with Proxmox's own cloud-init, not ISO installs. That makes a new VM a five-minute job and keeps them all looking the same.
Running VMs, roughly:
- Two Docker hosts, one per node, carrying almost all services
- Two Pi-hole DNS servers, one per node, synced hourly
- The UniFi controller
- A jumphost for administration, Ansible and the private Git server
- A small witness VM that only exists to cast the third vote for the HA stack
- A handful of lab VMs (k3s, a portal prototype, a macOS VM) that get started when I need them
Services
The two Docker hosts split the work roughly like this:
- Home: Home Assistant, Mosquitto, a Ring doorbell bridge, Frigate + go2rtc recording the Wi-Fi cameras
- Media: Jellyfin, Sonarr, Jackett and Transmission, with media on the NAS over NFS
- Cloud: Nextcloud with MariaDB, a self-hosted password manager
- AI: Open WebUI in front of Ollama on the GPU laptop
- Platform: a reverse proxy with Let's Encrypt, a WireGuard VPN, Portainer, Uptime Kuma
- Ops Center: my own operations platform, running active/active across both hosts
Full breakdown in what runs in the containers.
Monitoring and backups
Monitoring is Prometheus, Grafana, Loki, Alertmanager and blackbox/cAdvisor exporters, bundled into Ops Center. Uptime Kuma watches the endpoints from a user's point of view, and Proxmox alerts are routed into the same place.
Backups are Proxmox vzdump jobs to an NFS share on the NAS. Application data that matters (Nextcloud, Home Assistant, the password manager) lives on dedicated data volumes, so a VM restore and a data restore are two separate, testable things.
Lessons so far
Pin what you care about. A container updater is great for Jellyfin and terrible for anything with a database schema. Important services get pinned tags; convenience services float.
- Count physical cores, not vCPUs. A 4-thread node happily accepts 16 vCPUs of VMs, and then your DNS server starts timing out under load. Put latency-sensitive things (DNS!) on the node with headroom, and cap noisy neighbours.
- Two of everything that answers queries. Two DNS servers on two nodes means one node can be patched without the whole house losing the internet.
- Keep the controller out of the blast radius. UniFi in its own VM means a Docker host rebuild never takes the Wi-Fi config with it.
- Build VMs from cloud images. Reproducible beats hand-tuned.
The lab keeps changing. The next items on the list are more backup capacity and bringing the third node back so the cluster has real quorum again.
# EOF