The Hardware That Started It All
Last week I wrote about why I built a homelab instead of paying for cloud services. The tl;dr: a broken Synology, astronomical NAS prices, and a refurbished HP G3 that cost a quarter of a 2-bay Synology enclosure — before drives.
What I didn’t cover: how that single node became two nodes, why the RAM split is lopsided, and why the architecture divides into "infra" (Proxmox + ZFS) and "smart" (bare-metal Debian + GPU) instead of just cloning the same setup twice.
The Two Nodes (Current State)
Infra Node: refurbished HP G3, i5-6500, 16 GB DDR4, 3×2 TB RAID-Z on Proxmox. Smart Node: custom Ryzen 5600, GTX 1060 6 GB, 32 GB DDR4, bare-metal Debian.
RAM split wasn’t symmetric — 16 GB runs Proxmox + ZFS + VMs fine; 32 GB needed for local LLMs + Docker. Pragmatism over symmetry.
Why Not Cluster Them?
Everyone asks: "Why not Proxmox cluster the two nodes?"
Short answer: Different OSes, different roles, no HA requirement.
- Infra Node = Proxmox host (ZFS, VMs)
- Smart Node = Bare-metal Debian (Docker, Ollama, media stack)
Clustering would mean installing Proxmox on the Smart Node — adding a hypervisor layer I don’t need for a single-purpose compute box. No shared storage (Smart Node has only NVMe for OS). No HA need (if Smart Node dies, media transcoding pauses; infra keeps running).
Lesson: Cluster when you need HA and shared state. Don’t cluster just because you have two boxes.
The Split Logic: Infra vs. Smart
Infra Node runs Proxmox host: ZFS /tank (single source of truth), Samba VM, Home Assistant VM (radio passthrough), Docker VM (Nextcloud, AdGuard, n8n, Twingate), Cloudflare Tunnel. Why Proxmox? ZFS on host = direct disk access; VM isolation for HA/Samba/Docker; built-in backup/snapshots.
Smart Node runs bare-metal Debian: Docker + Portainer (media stack, Ollama, local LLMs), GTX 1060 NVENC for Plex, mounts /tank/media via NFS. Why bare metal? No hypervisor tax; GPU passthrough to Docker simpler than Proxmox PCI → VM → Docker; Portainer lighter for this workload.
The Media Stack Migration (And Why It Mattered)
Originally: Everything on Infra Node (Docker VM).
Infra Node (Proxmox) → Docker VM → Plex + *Arr + qBittorrent
Problem: i5-6500 + no GPU = CPU transcoding = slow, poor quality, fans screaming. The i5 did handle it for about two weeks before I moved the stack.
Solution: Move media stack to Smart Node.
Infra Node: ZFS (/tank/media) → NFS export → Smart Node: Plex + *Arr + GPU transcoding
Result:
- Plex Direct Play on LAN → zero transcoding
- Remote stream → GTX 1060 NVENC → smooth 1080p/4K transcoding
- i5-6500 sits at 5% CPU, fans silent
Why Plex, not Jellyfin? Compared both. Plex won on: TV app availability (pre-installed on most TVs, some don’t allow sideloading), family sharing UX, Plex Pass GPU transcoding maturity. Jellyfin is excellent — just not the right fit for my household.
The Network Upgrade That Wasn’t Planned
Right after I created the ZFS pool and started migrating TB of documents, photos, and media to /tank, the network choked. Sustained 1 GbE transfers would freeze the router — internet died, had to unplug/replug the router to recover.
Root cause: Cheap consumer switches/routers have low forwarding rate (packets per second) and switching capacity. Large sequential transfers saturate the switch fabric, not the port speed.
Fix: Upgraded the home network to 2.5 GbE — 2.5 GbE switch, 2.5 GbE NICs on both nodes and my main PC, Cat6a cabling. The router already supported 2GbE, but the switch didn’t so it got replaced too.
Lesson: 1 GbE port speed ≠ 1 GbE sustained throughput. Forwarding rate matters more than marketing numbers.
The GPU Reality Check
GTX 1060 6 GB in 2026: runs Qwen 7B, Gemma 8B, Qwen 3B/4B comfortably (~20–45 tok/s). Hits wall at 14B+ (needs 8 GB VRAM). For large contexts: nemotron-3-ultra via NVIDIA’s API — not local, but saves the day when 32K isn’t enough. Smart Node = always-available local AI, not biggest models.
The TrueNAS SCALE Dilemma (Bridge to Next Article)
Still weighing: Why not TrueNAS SCALE on the i5-6500 + Proxmox on the Ryzen? Storage-first OS (TrueNAS) vs virtualization-first OS (Proxmox). I chose virtualization-first because my workload mix (HA + Samba + Docker + VMs) needs Proxmox’s VM flexibility more than TrueNAS’s storage UI. But the Samba/NFS/ACL pain on Debian is real — fixing in place for now. Full evaluation in the next article.
What I Would Change (If Starting Over)
| Decision | Current | Would Change To | Why |
|---|---|---|---|
| Infra Node OS | Proxmox + ZFS on host | TrueNAS SCALE (bare metal) | ZFS-first UI, native SMB/NFS, still runs Docker/VMs |
| Smart Node OS | Debian + Docker | Keep Debian bare metal | No hypervisor tax, simpler GPU passthrough |
| Media transport | NFS (LAN) | Keep NFS | Simple, fast, no VPN overhead |
| GPU | GTX 1060 6 GB | Same GTX 1060 | It’s what I had — would still have it |
| Network | 1 GbE → 2.5 GbE | Start at 2.5 GbE | Avoid the router reboot dance |
| Clustering | None | Keep none | Different roles, no HA need |
The Honest Summary
Two nodes. One location. Zero clustering. One NFS mount. One Twingate connector. It works.
| What Works | What’s Fragile |
|---|---|
| Media playback (Direct Play + GPU transcode) | NFS mount dependency — if Infra Node reboots, media pauses |
| Local AI inference (7B–9B models) | 6 GB VRAM ceiling — no 14B+ models locally |
| Remote access (Twingate → Plex) | Internet outage = no remote access |
| ZFS snapshots + send/receive for backups | Manual — no automated off-site yet |
| Home Assistant local control | Zigbee radio only on Infra Node |