Most homelab buying guides start with the case or the drives, but the CPU and motherboard decide almost everything downstream of them. PCIe lane count sets how many cards you can run at once. ECC support decides whether a bit flip in RAM silently corrupts your ZFS pool or gets caught and corrected. IOMMU group layout decides whether GPU or HBA passthrough to a VM is a ten-minute config change or a wall you can’t get past no matter what you try. None of that shows up on a spec sheet the way clock speed and core count do, which is exactly why it gets skipped over until someone hits it the hard way.

Consumer desktop platforms: AMD Ryzen and Intel Core

This is where most homelabs start, and for a lot of builds it’s the right call.

What you get. Modern consumer CPUs are efficient at idle, cheap to buy new, and have wide software and community support since they’re the same chips everyone’s desktop runs. Motherboards are inexpensive and easy to find in mini-ITX and micro-ATX for a compact build.

The lane ceiling. This is the part that catches people. A consumer platform typically gives you 20-24 total PCIe lanes from the CPU, split across the primary x16 slot, any M.2 NVMe slots, and chipset-connected lanes for secondary slots and USB. Populate a GPU in the x16 slot, two NVMe drives, and an HBA card, and you’re already contending for lanes that a server platform hands out without a second thought. Check the specific board’s block diagram, not just the CPU’s rated lane count, before assuming a given combination of cards will actually run at full speed simultaneously.

ECC, mostly not supported. Intel Core desktop chips don’t support ECC memory at all outside of a narrow set of workstation-oriented chipsets (W680 being the notable current one). AMD Ryzen is murkier: the non-Pro consumer chips technically support unbuffered ECC UDIMMs at the silicon level, but whether it actually works depends entirely on the motherboard vendor implementing and validating it, and plenty of consumer boards simply don’t, or only partially do (no error reporting even if correction technically works). If ECC matters to you, verify it against that specific board’s own documentation, not the CPU’s general reputation for “supporting” it.

Used enterprise platforms: Xeon, EPYC, and Threadripper

This is the value play a lot of experienced homelabbers land on once they’ve outgrown a consumer board once.

Real PCIe lanes. A used Xeon Scalable, EPYC, or Threadripper platform routinely offers 64-128+ PCIe lanes depending on generation and socket. That’s the difference between “pick two of GPU, HBA, and 10GbE NIC” on a consumer board and running all three plus room to add a fourth card later without ever thinking about lane budgets again.

ECC as the default, not the exception. Server and workstation platforms are built around ECC RDIMMs or LRDIMMs as the normal case, not a special-order option. For anything running ZFS with data you actually care about, this closes the exact gap consumer platforms leave open.

Built-in remote management. Most of these boards ship with an onboard BMC (iDRAC, iLO, or a generic IPMI implementation depending on vendor), giving you KVM-over-IP and remote power control out of the box, a feature covered in more depth in the IPMI/iDRAC/iLO article on this site. A consumer board gives you none of that unless you add it separately.

The real costs. Older enterprise CPUs draw more power at idle than a modern efficiency-focused consumer chip, sometimes considerably more on first-generation EPYC or older Xeon E5 platforms, so run the numbers against the electricity-cost math elsewhere on this site before assuming “used and cheap” beats “new and efficient” over a few years of 24/7 uptime. RDIMM/LRDIMM pricing on the used market can also swing wildly by capacity and generation, sometimes cheaper per GB than consumer DDR4 or DDR5, sometimes not, so price the RAM alongside the board rather than assuming it’s automatically the bargain. And going back a generation or two on server gear generally means going back a generation or two on single-threaded performance too, which matters if your workload leans on it (a handful of latency-sensitive VMs) rather than parallel throughput across many containers.

IOMMU groups: the thing that decides if passthrough works at all

This is the part that doesn’t show up on any spec sheet and burns more homelabbers than lane counts or ECC combined.

What it actually is. IOMMU (Intel VT-d or AMD-Vi, enabled in BIOS) is what lets Proxmox hand a specific PCIe device directly to a VM instead of the whole hypervisor. For passthrough to work cleanly, the device you want to pass through needs to sit in its own IOMMU group, or at least a group containing only devices you’re comfortable handing to the same VM as a set.

Why it varies by board, not just by CPU. IOMMU grouping is determined by how the motherboard’s PCIe topology is wired, which PCIe switches and bridges sit between slots, not purely by the CPU or chipset model. Two boards built around the identical CPU can produce completely different, and differently usable, IOMMU group layouts. This is the single most common reason someone follows a GPU passthrough guide to the letter and it still doesn’t work: their specific board groups the GPU together with something else on the same IOMMU group (often a USB controller or another slot) that they can’t or don’t want to also hand off.

How to actually check before buying. Search the specific motherboard model plus “IOMMU groups” or “passthrough” before purchasing if passthrough is part of the plan at all, homelab and Proxmox forums are full of people who’ve already posted their dmesg/lspci group breakdowns for popular boards. If you already own the hardware, you can check it yourself with a short script that walks /sys/kernel/iommu_groups/ and lists which PCIe devices land in each group, run it before you commit to a passthrough plan, not after wiring up the VM.

Matching the platform to the actual build

A lightweight LXC-and-a-few-VMs homelab, no passthrough planned, bulk storage lives on a separate NAS: a consumer Ryzen or Intel Core build (or a mini PC built around one) is the right call. Lower idle power, cheaper to buy, and the lane ceiling never becomes a real constraint if you’re not trying to populate three expansion cards at once.

A build that wants GPU passthrough, an HBA for direct drive access, and a 10GbE NIC all running together, or that wants ECC as a non-negotiable for a ZFS pool: a used enterprise platform is worth the extra idle watts. This is the build where consumer-platform lane limits stop being theoretical and start actually blocking what you’re trying to do.

Anything where passthrough is part of the plan, on either platform: verify the specific board’s IOMMU group layout before buying, not after. This is the one factor that a bigger budget or a better CPU can’t fix after the fact if the board’s PCIe wiring groups the wrong things together.

Bottom line

Clock speed and core count are the easiest numbers to compare and the least likely to actually block you. PCIe lane count, ECC support, and IOMMU group layout are harder to find and far more likely to be the thing you hit a wall on six months into a build. Check all three against your actual plan, not just the CPU you already like, before picking the platform the rest of the homelab gets built on top of.