You can build a capable homelab from a single old laptop or a $100 mini-PC. The rack below is years of accumulation and a hobby budget — not a starting requirement.

Past — how it started

It started the way most labs do: one retired consumer desktop, a couple of virtual machines, and a lot of curiosity. The goal wasn't to replicate a datacenter — it was to learn how datacenters work without needing access to one. A hypervisor installed late one night, a VM that wouldn't boot, several hours on forums, and then it worked. That's the origin story.

From there, the scope crept in a direction that probably felt familiar to anyone who's done this: one service leads to another, one server isn't enough, and before long you're thinking about redundancy. The consumer gear lasted until the limitations became the lesson, and then it was time for enterprise iron.

Present — what runs today

Today the lab is anchored by three physical servers in a proper rack. Each one has a job, each job has a reason, and the whole thing is documented the same way a real shop would document it.

Internet Remote access Tailscale Firewall OPNsense · HA pair Core switch 24×1G + 4×10G uplinks Hypervisor node VMs + containers Hypervisor node VMs + containers Storage server bulk + backups cluster Dozens of VMs and containers run across the two-node cluster.
High-level architecture — the shape of it, sanitized: no addresses, hostnames, or topology detail.

Compute cluster — two Dell PowerEdge R640s

The R640 is a 1U dual-socket rack server from Dell's 14th-generation lineup. Both nodes are identically specced, which makes maintenance and capacity planning simple.

  • CPU: Each node carries two Intel Xeon Silver 4208 processors (8 cores / 16 threads each) — 16 cores and 32 threads per node. These are Cascade Lake-SP chips on the LGA 3647 socket, with AVX-512 and hardware-accelerated AES. They're not the fastest Xeons ever made, but at this density and price point for used enterprise gear, they're hard to beat for running dozens of VMs simultaneously.
  • Memory: Both nodes are fully populated with 768 GB of DDR4 LRDIMM across 24 slots — 32 GB per slot, all four-rank. That's roughly 1.5 TB of RAM across the cluster (the Live Infra page shows the slightly lower figure Proxmox actually reports). In practice, it means experiments never fight production workloads for memory, and VM density is constrained by CPU and storage well before RAM.
  • Storage: Each node runs ZFS on enterprise SAS SSDs. The primary node's VM pool is three mirrored pairs of 800 GB Western Digital SAS SSDs striped together (six drives) — roughly 2.2 TB of fast, redundant VM storage. The secondary node runs two mirrored pairs from the same WDC SAS family (about 1.5 TB). Both nodes boot from mirrored Micron M.2 SATA SSDs on Dell BOSS cards — a clean separation of OS and workload storage.
  • Networking: Both nodes received a 10-gigabit NIC upgrade in early 2026. The original 1GbE onboard NICs and a legacy 10G card were replaced with quad-port 10G SFP+ NDCs (Dell 68M95, OEM ConnectX-4 Lx silicon). One port carries all VM traffic via a trunked bridge; a second port handles direct point-to-point connectivity between the two nodes for cluster traffic. Two ports remain available for future use.
  • Out-of-band management: Both nodes have Dell iDRAC 9 — dedicated remote management that works independently of the OS. Full KVM, virtual media, and hardware event logs without touching the host.
  • Power: Each node has redundant 750W PSUs. Both draw roughly 240–270W at typical load — modest for the capabilities on offer.
  • Hypervisor: Proxmox VE, clustered across both nodes for live migration and high availability. ZFS is the storage layer on each.

Storage server — Supermicro CSE-847

The CSE-847 is a 4U Supermicro chassis with 36 drive bays. It runs Unraid, which is well-suited for mixed-capacity arrays and Docker-based services that don't need virtualization overhead.

  • CPU: A single Intel Xeon E5-2698 v3 — a Haswell-EP chip on the LGA 2011-3 socket. 16 cores, 32 threads, 40 MB of L3 cache, and a 135W TDP. Unraid is not CPU-constrained at this workload level; the chip is comfortable headroom for transcoding, Docker containers, and parity calculations running simultaneously.
  • Memory: 192 GB of DDR4 RDIMM across 6 of 8 slots, with two channels still open for future expansion.
  • Array storage: Twelve data drives plus one parity drive — a mix of 4 TB, 6 TB, 10 TB, 12 TB, and 14 TB spinning disks from HGST, Western Digital, and Seagate. Total raw capacity is roughly 114 TB; most of the array is actively used. The array currently runs a single parity drive; a second parity drive is planned to guard against data loss as the pool keeps growing. The oldest drives in the fleet are HGST 4 TB units at over 96,000 power-on hours (about 11 years of continuous operation) — they're healthy by SMART but flagged for replacement on priority.
  • Cache pool: A fast landing zone for writes before they settle onto spinning disk — a pair of 3.84 TB Samsung enterprise SAS SSDs (PM1645a and PM1633a). The older, smaller SATA SSDs that used to share this pool have since been pulled out.
  • Networking: A dual-port Intel 82599ES 10G NIC handles storage traffic. The onboard Intel I350 quad-port 1GbE handles management.
  • Power: Dual redundant Supermicro PSUs rated at 1280W on 208V. 80 Plus Platinum efficiency.

Networking layer

The network is segmented by function — separate broadcast domains for different classes of traffic — enforced at the switch and firewall levels.

  • Firewall / router: OPNsense, running as a high-availability pair of virtual machines on the compute cluster — one instance per node, with failover handled at the OS layer (CARP) rather than by a dedicated appliance. Virtualizing it instead of buying a separate box was a deliberate choice; the HA pair is still being finalized. It handles routing, DHCP, DNS, NAT, and firewall policy across all segments.
  • Core switch: A managed Dell N3224T-ON — 24 gigabit base-T ports plus four 10G SFP+ uplinks, with full VLAN support. The three servers connect at 10G over the SFP+ ports via DAC cables; the gigabit ports handle everything else. It's an enterprise-grade platform running Dell's networking OS.
  • Wireless: UniFi access points — deployed for personal devices, guests, and IoT separately.

Power infrastructure

  • Rack UPS: An APC rack-mount UPS keeps the servers alive through brief outages and provides a clean shutdown window for longer ones. Runtime at typical load is enough to drain gracefully.

Workstation and endpoints

The daily driver isn't a separate physical box — it's a VM on the cluster, accessed over RDP. That means the "workstation" hardware is the servers themselves, and upgrading the cluster upgrades the desk.

  • Desktop workstation VM: Runs on one of the compute nodes. Full Linux desktop environment, accessed remotely. Because it lives on the same hardware as production services, it naturally has low latency to everything it manages.
  • Infrastructure control node: A small VM dedicated to running Terraform and Ansible. It has no user sessions — it just executes IaC against the cluster on demand.

Specific model variants, serial numbers, IP addresses, and network topology are not published here. Model families and capacity figures are accurate as of mid-2026.

Future — the roadmap

A homelab in active use is never "done." The current roadmap reflects the natural tension between what the lab can do today and what it still can't do well.

AI host — dedicated GPU server

The single biggest gap right now is GPU compute. Running large language models locally requires a GPU; the current servers have none worth mentioning. The planned AI host is a dual-socket LGA 2011-3 Supermicro board with four onboard 10GBASE-T ports, several PCIe slots, and room for 768 GB of RAM. The target GPU is a professional-class 48 GB NVIDIA RTX workstation card. The goal is to move all AI workloads off cloud inference and onto hardware I own, with no per-token cost and no data leaving the building.

The chassis for this build is the remaining open question — a purpose-built 4U chassis with dedicated GPU airflow paths is the front-runner. The board, CPU pair, and most of the RAM are already on hand.

TrueNAS storage build

The spinning-disk Unraid array does its job, but it can't serve Proxmox shared storage in a way that enables true HA and live migration without manual intervention. A TrueNAS SCALE build is planned to change that — ZFS on enterprise SAS SSDs and spinners, with NFS/iSCSI for the compute cluster and a NetApp DS2246 shelf for additional capacity. The TrueNAS host is built on a Supermicro board chosen to share spare parts with other planned builds, keeping the maintenance story simple.

CPU upgrades

The Silver 4208 processors in both R640 nodes are capable but not exceptional — 8 cores per socket at 2.1 GHz base is comfortable today but leaves performance on the table. The same LGA 3647 socket accepts Platinum-class chips up to 28 cores and over 3 GHz sustained on all cores. Platinum 8173M processors represent the most cost-effective single upgrade in the roadmap — a 3.5x jump in per-node thread count for a fraction of what this hardware would have cost new. Used server CPU prices have compressed significantly as this generation of enterprise iron ages out of data-center refresh cycles.

Aging drive replacement

Three HGST 4 TB drives in the Unraid array are at or past 96,000 power-on hours — roughly 11 years of continuous spinning. SMART numbers are clean, but rated service life for enterprise HDDs is typically 5 years. These are on the replacement list.

Optical rip station

A separate physical machine for Blu-ray ripping is in the plan — four UHD-capable optical drives in a tower chassis, running Makemkv or a libredrive-patched firmware stack. The chassis is already on hand (an Antec 1200, sourced used). Board, CPU, and drives are on the shopping list.

Physical Proxmox Backup Server

PBS currently runs as a VM on the cluster — which works, but means a cluster-wide failure takes the backup server with it. Moving it to a small dedicated physical tower (a spare case already in inventory) decouples the backup layer from the compute layer, which is how it should work.

The roadmap items above are sourced from the internal planning docs. The "why" is consistent: each build reduces a single point of failure, closes a capability gap, or drops a recurring cloud cost. Not all of it is urgent — some of it is just satisfying to think through.
Theme
Font