Build a Proxmox Server: Homelab Virtualization Host

You want to run a stack of VMs and containers at home without renting a cloud, and a Proxmox server is how you do it. The trick is building one that actually behaves: a NIC that does not drop under load, storage that survives a power cut, and enough room to pass a GPU straight through to a VM. This guide is three complete, parts-verified Proxmox builds, entry to beast, each one a machine I would run in my own homelab.

Every parts list here is checked as a working machine, not a wishlist, because the gotchas in a virtualization host are the ones a gaming build never hits: ECC support that depends on the exact board and CPU pairing, Realtek NICs that stall Proxmox under load, and IOMMU groups that decide whether passthrough works at all. The storage and RAM numbers come from a real Proxmox host, not a spec sheet. If you would rather buy than build, a prebuilt mini PC for a homelab is the no-assembly route.

Built around parts I verified this month, on the same Proxmox host I run in my homelab, June 2026.

The three builds at a glance

Pick the tier by how much you are running and whether you need ECC and serious passthrough. Each total is the approximate parts cost in June 2026, and 2026 DRAM prices are the swing factor, so check live before you order.

• Quiet entry homelab: an AM5 APU box for 5 to 10 light VMs, low idle watts, no ECC by design. Approx $630 to $820.
• Serious mid homelab: a 16-core AM5 host with ECC support, a ZFS boot mirror, a power-loss-protected datastore, and room to pass one GPU through. Runs 15 to 30 VMs. Approx $1,200 to $2,200.
• Beast with heavy passthrough: a used EPYC server platform with registered ECC and 128 PCIe lanes, so a GPU, an HBA, and a 10GbE NIC each pass to their own VM. Approx $2,100 to $2,930 before a GPU.

How we picked, and what the lab showed

The numbers behind these choices came off a live Proxmox host, not a datasheet. Two of them shaped the storage and RAM picks across every tier.

On ZFS, a SATA SSD managed 642 fsync operations per second while an NVMe drive hit 2024, and when we forced the pool to honor every sync write, a consumer drive collapsed from 334,000 IOPS to 2,041, a 160-fold drop. That gap is the entire reason the mid and beast builds add a power-loss-protected datastore SSD rather than running VMs off a consumer drive. The other lesson is RAM: ZFS ARC will quietly eat half your memory and look like a leak, so every tier is sized with headroom and the ARC capped. Where each tier lands on VM count tracks what we have seen per node in the how-many-VMs testing.

Build comparison: which Proxmox server fits you

Quiet entry build: a low-power AM5 host for a first homelab

The entry build is small, quiet, and cheap, and it runs 5 to 10 light VMs or a stack of LXC containers without breaking a sweat. It is built on a Ryzen 5 8600G, an APU whose Radeon 760M graphics keep a console on the host, drawing 15 to 30 watts at idle, which matters on a box that never turns off. Build this if you are starting out and want to learn Proxmox on real hardware without a server-grade budget.

Skip it if you need ECC memory (this APU cannot use it, by design) or you plan heavy multi-device passthrough. Those are the mid and beast builds.

Two things on this build need a word. First, the ASRock board’s onboard NIC is a Realtek 2.5GbE chip, the one Proxmox users keep filing bug reports about, so the build adds a cheap Intel i226 card and uses that as the bridge instead. It is a $30 fix for a problem that otherwise stalls every VM at once. Second, the 8600G gives you a strong iGPU and a low idle, but it cannot use ECC. If ECC matters more to you than the iGPU at this price, swap to a non-G Ryzen 5 7600 and an ECC kit on the same board. For a first homelab, non-ECC is fine, and a UPS covers the consumer NVMe that lacks power-loss protection.

Serious mid build: a 16-core AM5 host with ECC and passthrough

This is the build most homelabbers actually want: a 16-core Ryzen 9 9950X with its own iGPU for the host console, a board that genuinely validates ECC memory, a ZFS boot mirror, a power-loss-protected datastore, and a free x16 slot to pass one GPU or HBA into a VM. It runs 15 to 30 VMs comfortably. Build this if your homelab is doing real work and you want it to survive a bad shutdown with your data intact.

Skip it if you need to pass through several devices at once (AM5’s IOMMU grouping fights you there) or your VM count is small enough that the entry build covers it.

The ProArt earns its place here. Its onboard NIC is Intel, not Realtek, with a Marvell 10GbE port alongside the Intel i225-V 2.5GbE, so the networking is sorted on a clean install. ASUS validates unbuffered ECC on it, which is rare on a consumer board. The catch worth knowing: ECC UDIMM on Ryzen 9000 caps around 5200 MT/s, and there is no pre-paired ECC kit to buy, so you order two matched ECC modules. The default pick above is fast non-ECC memory at 6000; the ECC swap is a deliberate choice you make at order time. For storage, the two SN850X drives form the ZFS boot mirror and the Micron 7450 is the power-loss-protected datastore that the fsync numbers argue for. The 9950X ships with no cooler, so the NH-D15 G2 is not optional. If you want to trim cost, the 12-core 9900X runs cooler and saves money with no real loss for this workload, and a smaller PSU is fine if you skip the GPU.

Beast build: used EPYC for ECC and heavy passthrough

When you need to pass a GPU, a storage HBA, and a 10GbE NIC into three different VMs at once, consumer platforms run out of PCIe lanes and clean IOMMU groups. The answer is not a new high-end desktop, it is a used server platform. A used EPYC 7313 brings 128 PCIe Gen4 lanes and eight-channel registered ECC, and the Supermicro H12SSL-i exposes five x16 slots plus the ACS support that gives every slot its own IOMMU group. DDR4 and Zen 3 are old news, which is exactly why the used market makes this the value play. Build this if multi-device passthrough and real ECC are the point.

Skip it if you only ever pass one device through (the mid build does that for less) or you are not comfortable buying used server gear off eBay and flashing an HBA to IT mode.

This tier lives and dies on three specifics. The memory must be registered (RDIMM) ECC, not the unbuffered ECC the AM5 build uses; an EPYC will not even POST on the wrong type, so do not carry a UDIMM kit over from the mid build. The cooler must be the SP3 version of the NH-U14S, not the visually similar SP6, because the socket is different. And the CPU, HBA, and 10GbE NIC are used-market parts: buy an EPYC listed as unlocked (not vendor-locked), an HBA explicitly flashed to IT mode so ZFS sees raw disks, and a genuine Intel X520. The board, RAM, SSDs, PSU, and cooler are all current retail. A GPU is deliberately left off the list, because which one is your call; the 850W supply has room for one mid-range card, and you step up to a 1000W unit for a 5090-class GPU.

Lay out the storage before you install

The single decision that bites homelabbers later is storage layout, so settle it before Proxmox touches the disks. Two rules carry most of the weight.

First, boot from a mirror. Proxmox installs happily onto a single disk, but a homelab host you actually rely on should boot from two SSDs in a ZFS mirror (the installer offers RAID1 right in the disk step). Lose one drive and the host keeps running. Second, do not run VMs off a cheap consumer SSD as a ZFS datastore if writes matter. We measured this on a live host: a SATA SSD in a ZFS pool managed 642 fsync operations per second, an NVMe drive hit 2024, and forcing ZFS to honor every sync write (sync=always) collapsed a consumer drive from 334,000 IOPS to 2,041, a 160-fold drop. A drive with power-loss protection rides that out because it can safely acknowledge a sync write from its onboard cache. That is the whole case for a power-loss-protected datastore SSD, covered in depth in the NVMe-versus-SATA datastore test and the server SSD guide. A consumer boot drive is fine if you pair the host with a UPS for graceful shutdown.

Size the RAM for the VMs and for ZFS

Proxmox RAM math has two halves, and the second one surprises everyone. The first half is obvious: add up what your VMs and containers need and leave headroom. The second half is ZFS. The ARC (Adaptive Replacement Cache) defaults to using up to half your RAM, and on a busy host it and your VMs end up fighting over the same pages. The gotcha here is that an unconstrained ARC will look like a memory leak the first time you watch free -h.

So size generously and cap the ARC. A host running a handful of light VMs is comfortable at 32 to 64GB; a serious homelab with databases, a few always-on services, and ZFS wants 64 to 128GB. Set an explicit ARC ceiling so it cannot starve your guests. The full sizing logic, including the ARC cap command, is in the Proxmox RAM guide; for the modules themselves the DDR5 guide tracks the 2026 pricing.

Verify IOMMU and PCIe passthrough before you commit

If the plan is to pass a GPU, an HBA, or a NIC straight through to a VM, the board has to put that device in its own IOMMU group. This is the check that separates a board that passes through cleanly from one that fights you, and it is worth running on the actual hardware before you build the rest around it. On current Proxmox kernels, IOMMU is on by default for both AMD and recent Intel CPUs, so the real gate is the BIOS: enable IOMMU there, along with SVM on AMD or VT-d on Intel.

If the groups still do not appear, add the flag to the kernel command line, amd_iommu=on iommu=pt on AMD or intel_iommu=on iommu=pt on Intel, where iommu=pt is a useful passthrough performance option. Then confirm the IOMMU came up. An AMD host prints AMD-Vi lines and an Intel host prints DMAR:

dmesg | grep -e DMAR -e "AMD-Vi" | grep -i enabled

On a host with it active you get a line like this:

DMAR-IR: Enabled IRQ remapping in x2apic mode

Now list the groups. The thing you are checking for is separation: the device you want to pass through should sit in a group by itself, with no chipset functions sharing it.

for g in /sys/kernel/iommu_groups/*/devices/*; do
  grp=$(echo $g | sed -E 's#.*/iommu_groups/([0-9]+)/.*#\1#')
  printf "IOMMU group %s: " "$grp"
  lspci -nns "$(basename $g)"
done | sort -V

On a real host that separates cleanly, the network card and the NVMe controller each land in their own group, which means either can be handed to a VM without dragging a neighbor along:

IOMMU group 0:  00:02.0 VGA compatible controller [8086:1912]
IOMMU group 4:  00:17.0 SATA controller [AHCI mode] [8086:a282]
IOMMU group 9:  00:1f.6 Ethernet controller: Intel I219-LM [8086:15b7]
IOMMU group 10: 01:00.0 Non-Volatile memory controller: Samsung NVMe SSD [144d:a804]

If instead your GPU shares a group with a pile of chipset devices, the board’s IOMMU grouping is too coarse, and you either enable the ACS override patch (with the security caveats that carries) or move the card to a slot wired directly to the CPU. This is exactly where the platforms diverge: a consumer AM5 board does single-device passthrough fine but needs the override hack for several devices, while the EPYC server board hands every slot its own group. Find this out before the parts are in the case, not after.

Install Proxmox and bring the host up

With the hardware sorted, the software is the easy part. Write the Proxmox VE ISO to a USB stick, boot it, and the installer walks you through the rest, including the ZFS mirror for the boot disks. The one screen worth slowing down on is storage: pick zfs (RAID1) and select both boot SSDs so the host survives a dead drive. The full walkthrough, including the post-install repository fix, is in the Proxmox VE install guide.

After the first boot, confirm the host sees the right NIC and the ZFS pool before you load it with VMs:

ip -br link
zpool status

The Intel NIC should show up as the bridge uplink and the boot pool should report ONLINE with both mirror members. From there it is the web UI at port 8006 and your first VM.

What actually matters in Proxmox host parts

A Proxmox box is not a gaming PC with a different sticker. The parts that matter are the ones a gaming build ignores, and the flashy ones barely move the needle.

The NIC: Intel, not Realtek

This is the cheapest mistake to avoid and the most common one. Realtek 2.5GbE chipsets are notorious for dropping under sustained load on Linux, which on a hypervisor means every VM on the box stutters at once. Intel NICs (the i210, i225, i226, or an onboard Intel chip) just work. If a board you like ships a Realtek NIC, budget for a cheap Intel card and pass the onboard one through to a VM or ignore it. A managed 2.5GbE or 10GbE switch finishes the network off.

ECC: worth it on the host that holds your data

ECC memory catches the bit flips that silently corrupt data, and on a host running ZFS, where RAM caches everything, that protection matters more than on a desktop. The catch is platform support. AMD AM5 supports unbuffered ECC, but only on specific boards that validate it, and only with ECC UDIMMs. Intel consumer boards need a W680 chipset for ECC. Threadripper and EPYC use registered (RDIMM) ECC, which is a different module entirely. Match the memory type to the platform or it simply will not post.

An iGPU keeps a passthrough build sane

If you plan to pass your only GPU to a VM, the host loses its display. A CPU with integrated graphics (a Ryzen with Radeon graphics, or an Intel chip with its iGPU) keeps a console on the host while the discrete card goes to the guest. On a server board like the Supermicro, the onboard BMC gives you remote KVM instead, which solves the same problem a different way.

Idle power, because it runs 24/7

A homelab host is on all the time, so idle draw matters more than peak. A tower that idles at 90W instead of 45W costs you real money over a year of always-on uptime. Favor an efficient platform, enable the C-states in the BIOS, and do not overbuy a power supply, because supplies are least efficient at the bottom of their range where an idle host actually sits.

The mistakes that bite first-time Proxmox builders

Most failed homelab builds trip on the same handful of things, and every one of them is cheaper to dodge than to fix after the parts arrive. The Realtek NIC that stalls under load. ECC memory bought for a CPU that cannot use it, or the wrong register type for the socket. A consumer SSD as a ZFS datastore that crawls the moment a database starts issuing sync writes. A GPU stuck in an IOMMU group it shares with half the chipset. None of them show up on a spec-sheet comparison, and all of them show up the first week you actually run the box.

So the order that works: pick the NIC and the memory type around the platform first, settle the storage layout before you install, and verify the IOMMU groups on the real hardware before you build everything else around a passthrough plan that the board cannot deliver. Get those right and the rest of a Proxmox build is just assembly.