Proxmox Hardware and Sizing

Choosing the right Proxmox hardware follows one simple rule: a 64-bit x86 CPU with virtualization support (Intel VT-x or AMD-V), enough RAM to cover all your VMs plus a reserve for the hypervisor, and fast SSDs instead of spinning disks. Proxmox VE itself is frugal and runs on roughly 2 GB of RAM. Your actual needs are driven by the virtual machines you run, the storage you choose (ZFS in particular), and whether you are building a homelab or a production system. This guide separates the two clearly and gives concrete rules of thumb, current as of June 2026 with Proxmox VE 9.

CPU: which processor for Proxmox

A 64-bit CPU from Intel (Intel 64) or AMD (AMD64) with the virtualization flag enabled, that is Intel VT-x or AMD-V, is mandatory. Without it, KVM cannot start full virtual machines. If you want to pass hardware through to a VM, such as a GPU or an HBA, you additionally need VT-d (Intel) or AMD-Vi/IOMMU (AMD). Both are present in practically every server CPU and most desktop CPUs today, but often have to be switched on in the BIOS/UEFI first.

For sizing: more cores mean more parallel VMs, while strong single-thread performance helps latency-sensitive services such as databases. Proxmox can overcommit CPU cores (assign more vCPUs than physically present), because VMs rarely run at full load all at once. A realistic starting point is one physical core per two to four moderately loaded VMs. For production we recommend server CPUs such as Intel Xeon or AMD EPYC: they offer high core counts, plenty of PCIe lanes, more memory channels and, crucially, official ECC support. In a homelab, modern consumer CPUs (Intel Core, AMD Ryzen) do an excellent job, often cheaper and more power efficient.

RAM: rules of thumb and why ZFS wants extra

The hypervisor itself uses only about 2 GB. The rest of the memory belongs to the guests. Estimate the RAM needs of your VMs and containers realistically and add a buffer of 10 to 20 percent for the host. Unlike CPU, RAM cannot be heavily overcommitted without risk; an exhausted machine leads to swapping or the OOM killer.

The biggest variable is ZFS. ZFS uses a read cache (ARC) that by default helps itself generously to RAM. As a rule of thumb, Proxmox budgets about 1 GB of RAM per TB of used storage for ZFS (and the same for Ceph). The ARC can be capped, but that costs read performance. So:

• No ZFS, small workloads: 16 GB is a usable entry point.
• With ZFS or multiple VMs: 32 GB is the lower bound, 64 GB is comfortable.
• Production with several applications and ZFS: 128 GB and more is not unusual.

Is 32 GB enough? For a handful of small VMs without ZFS: yes. Once the ZFS ARC and several production VMs come together, it gets tight. When in doubt, add more RAM; it is the cheapest insurance against performance problems. ECC RAM is not officially required, but for production and ZFS we strongly recommend it: an undetected bit flip in RAM can otherwise be written silently to disk, and that is precisely what ZFS cannot protect against.

Storage: NVMe/SSD, ZFS and no hardware RAID

Storage is the most common bottleneck. Spinning disks slow down any virtualized system; go with SSDs or NVMe. For production we recommend enterprise drives with power-loss protection (PLP). They are many times faster on synchronous writes, which ZFS relies on, and far more durable under sustained load than consumer SSDs.

The most important point for ZFS setups: no hardware RAID. ZFS is a file system, volume manager and RAID in one, and it wants direct access to the raw disks. A RAID controller that presents the disks as a single volume strips ZFS of its checksumming and self-healing, and it is officially unsupported. Use an HBA in IT mode instead, which passes the disks through unchanged. Hardware RAID with a battery-backed write cache (BBU) is only an option if you run classic LVM/ext4 rather than ZFS.

Practical recommendations:

• OS disk: 32 to 64 GB is enough for Proxmox VE; a ZFS mirror of two small SSDs protects against a system-disk failure.
• VM storage: at least two NVMe/SSD in a ZFS mirror (RAID1) for redundancy; for more capacity, RAIDZ or several mirror vdevs.
• Plan for growth: snapshots, backups and thin provisioning eat space over time.

Which file system makes sense when is covered in our article on Proxmox storage: ZFS, Ceph or LVM.

Network: a dedicated NIC for the cluster

For a single node a single Gigabit network card is enough. As soon as you build a cluster, the picture changes substantially. Proxmox recommends redundant (multi-)Gigabit NICs plus additional cards depending on the storage technology. Separate the traffic types:

• Corosync (cluster communication): needs low, stable latency and ideally belongs on its own dedicated network. High latency or packet loss here leads to unstable clusters.
• Storage replication/Ceph: very bandwidth hungry; here 10 GbE or faster is the standard, preferably as a separate network.
• VM/management traffic: keep it separate from the cluster network.

How to solve this cleanly on rented servers is shown for Hetzner in our articles on setting up Proxmox on Hetzner and building an HA cluster.

Homelab vs production

The most important decision is not a single component but the purpose. A homelab can be cheap, power efficient and simple. Production needs redundancy, remote management and enterprise components.

Server choice: mini PC/NUC or dedicated server

For a homelab, modern mini PCs are ideal: quiet, power efficient, NVMe capable and, with 16 to 32 GB of RAM, enough for many always-on services, learning environments and small test clusters (three mini PCs make a usable HA lab cluster). What they usually lack is ECC RAM, redundant power supplies, real out-of-band management and room for multiple drives.

For production there is no way around server hardware, whether in your own rack or rented. Look for ECC RAM, at least two enterprise NVMe/SSDs, redundant power supplies, IPMI/iDRAC for remote management, and enough PCIe lanes for an HBA and fast NICs. Rented dedicated servers, for example at Hetzner, are often the fastest route to production-grade hardware without capital expenditure. For high availability, plan for three nodes from the start (quorum) rather than two.

Operations and support

Hardware sizing is not a one-off purchase but a trade-off between workload, storage architecture and growth. We size, procure and operate Proxmox environments for customers every day, from single nodes to HA clusters with ZFS or Ceph. If you want to be sure your hardware matches the planned load, our team can help via our page on Proxmox and private cloud. A no-obligation initial consultation clarifies your specific setup in a few minutes.