First homelab — full phased plan, hardware locked, is this good, upgradeable, and future-proof?
Posted by Pablo_Gates@reddit | LocalLLaMA | View on Reddit | 3 comments
Done several targeted posts here and across r/selfhosted, r/MiniPCs, and r/LocalLLaMA over the past week. Most individual questions have been answered. Thanks all!
This is the full-picture post — I want a sanity check on the complete plan before I order.
Specifically interested in: is this a good foundation? Is it upgradeable? Anything obviously wrong with the phase sequence or hardware choices?
Goal
Replace paid cloud services and consolidate a scattered smart home:
- Replace iCloud Photos 2TB (€11/mo) with Immich — \~340 GB library, \~20k photos
- Consolidate three smart home apps (SmartLife + SmartThings + Alexa) into Home Assistant
- Local AI — offline supplement to Claude, handles the 60% of prompts that don't need cloud quality
- Home security NVR — starting with one TP-Link Tapo C310 (RTSP, already owned)
- Network-wide DNS ad blocking (AdGuard Home) and VPN remote access (Tailscale)
Hardware — Phase 1
- Mini PC: GMKtec NucBox K12 — Ryzen 7 H255, Radeon 780M 12CU, 64GB DDR5, 3× M.2 (1× PCIe 4.0 x4 + 2× x2), dual 2.5GbE Realtek R8125 (confirmed working in Proxmox), OCuLink PCIe Gen4 x4
- Data NVMe: WD Black SN770 2TB — second M.2 slot, photos + camera recordings
- Camera: Tapo C310 already owned
Chose K12 over Beelink SER8 (€559) specifically for the third M.2 slot, OCuLink (Phase 4 eGPU), and dual NIC (future pfSense/VLANs). The €270 delta felt right for always-on hardware.
Proxmox layout
Docker host runs as an unprivileged LXC with /dev/dri passthrough, not a VM. The AMD reset bug on Ryzen 8000 / 780M is not fixed in Proxmox 9.1 — it is a hardware issue. VM passthrough craps out on Proxmox-side reboots. LXC is the stable path, confirmed by multiple K12 owners.
| Type | Purpose | RAM |
|---|---|---|
| VM | Home Assistant OS | 4 GB |
| LXC | AdGuard Home | 512 MB |
| LXC | Tailscale | 256 MB |
| Unprivileged LXC | Docker host (everything else) | 10 GB |
All Docker services via docker compose up -d.
Phase sequence
- Phase 0 (done): AdGuard Home + Tailscale validated on a Pi 3B. Both reboot-stable. Confirmed working network-wide.
- Phase 1: Proxmox on K12. AdGuard + Tailscale migrate to LXCs. Docker host up: NPM, Portainer, Vaultwarden, Homepage, Beszel.
- Phase 2: Immich. Migrate 340 GB from iCloud. Immich ML on CPU only (
MACHINE_LEARNING_DEVICE=cpu). Initial index overnight (\~10h for 20k photos). Drop iCloud 2TB to 200GB after 60 stable days — saves €96/year. - Phase 3: HAOS VM + Frigate (Tapo C310 via RTSP). GPU split: Frigate on iGPU, Immich ML stays on CPU. Running both services on the 780M simultaneously causes random lockups every few days — confirmed by a K12 owner over 6 months. CPU-only Immich ML is rock solid and fast enough for normal upload volumes.
- Phase 4: llamacpp + Vulkan + Open WebUI. OCuLink dGPU: RX 7900 XTX 24GB (\~€550) + GTBox G-Dock enclosure (\~€249). Move llamacpp to dGPU, Frigate stays on iGPU. Tensor split across both AMD devices via
-dev Vulkan0,Vulkan1 -ts 1,1. With \~32GB effective VRAM (iGPU \~8GB + dGPU 24GB): Qwen 32B at Q4 fits comfortably. Also adding: UniFi USW-Lite-8-PoE, wired cameras, IoT VLAN, HA Voice PE. - Phase 5 (future): NAS when photos + recordings approach \~1.6TB. Synology DS225+ + 2× WD Red Plus 4TB (\~€480 total, RAID-1, 4TB usable).
LLM stack decision
llamacpp + Vulkan, not Ollama + ROCm. Vulkan is faster on AMD (confirmed by multiple people who tested both). Pre-built binaries available on the llama.cpp GitHub — no compilation. "Fit" is enabled by default. Open WebUI connects to the llamacpp server as a backend.
Questions
- Does the phase sequence make sense, or is there a better order? Specifically: Immich before HAOS, or HAOS first?
- Is NVMe-first (Phase 5 NAS only when the 2TB starts filling) reasonable, or should I add a NAS earlier for RAID redundancy on the photo library?
- The K12 third M.2 slot could take a third NVMe before needing a NAS — is that a valid intermediate step or does it just delay the inevitable?
- Anything about this plan that is obviously not upgradeable or will create a dead end I haven't seen?
Happy to share details on any part of the stack.
Veritas-keept@reddit
This is a legendary roadmap. Phase 2 (Immich migration) is where most people realize that 'Cloud Ownership' is the only way to avoid 10-year subscription traps.
I'm curious about Phase 4: Why are you leaning towards llamacpp + Vulkan specifically for the Qwen 32B run? I’m currently struggling with a similar local-first setup on Android (Veritas Keept) and the thermal throttling is a nightmare during long indexing sessions.
Also, for your "Administrative Debt" (receipts, warranties that don't fit in Immich), are you planning to use a separate OCR/RAG pipeline or just dump them into a folder? 🧘
Pablo_Gates@reddit (OP)
llamacpp + Vulkan because Vulkan benchmarks \~50% faster than ROCm HIP on the 780M.
Phoronix ran the comparison and RADV Vulkan wins clearly on RDNA 3. No ROCm installation headaches either, just pre-built binaries from the llama.cpp GitHub releases page.
Thermal throttling shouldn't be an issue on the K12 specifically: vapor chamber cooler, and multiple reviewers confirm sustained load without throttling (peaks \~94°C, well below the 105°C spec). That's a desktop context though, so not directly comparable to mobile.
On administrative docs: hadn't planned a pipeline yet but Paperless-ngx is what I'd reach for; self-hosted, OCR built in, Docker-native, tags and document types and correspondent matching. Will add it once the core stack is stable.
Veritas-keept@reddit
Thanks for the breakdown. My project is strictly mobile-first though, so no vapor chambers for me lol. Just trying to figure out if current SLMs are actually ready for real-world document indexing on a phone, or if the hardware is still too much of a bottleneck. Appreciate the insight on Vulkan though!