Proxmox Hardware Requirements and Sizing

Choosing the right Proxmox hardware follows one simple rule: a 64-bit CPU with virtualization support (on x86 Intel VT-x or AMD-V, alternatively a supported Arm64 platform), 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 October 2026 with Proxmox VE 9.2.

For replacing an existing server, see move Proxmox to new hardware for transfer, cutover and handover.

Minimum requirements and recommendation for production

The vendor separates minimum values from recommendations. The minimum values apply explicitly to evaluation only and not to production; for production Proxmox recommends high-quality server hardware (Proxmox VE System Requirements).

The following sections explain these values and add WZ-IT recommendations that do not come from the vendor documentation; they are marked as such. How the installation continues from here is covered in the guide on how to install Proxmox VE.

Which CPU does Proxmox need?

On x86 hosts, 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 (Proxmox system requirements). 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. How a GPU passthrough is set up is covered in the article on GPUs on Proxmox: PCIe passthrough and NVIDIA vGPU.

Since 5 August 2026, Proxmox VE has also been officially available for Arm64 (Proxmox press release). NVIDIA Grace Hopper and NVIDIA Vera are fully supported; other UEFI-based ARMv9-A servers run on a best-effort basis, and single-board computers such as the Raspberry Pi are not supported. A cluster may mix x86 and Arm64 nodes, but live migration only works between nodes of the same architecture (system requirements, Arm64 section). For typical SME workloads, x86 remains the standard.

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 WZ-IT sizing guideline for getting started 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.

How much RAM does Proxmox need? Rules of thumb and ZFS

The hypervisor itself needs at least 2 GB for the operating system and the Proxmox VE services (system requirements). 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). On new installations from Proxmox VE 8.1 onward, the installer limits the ARC to 10 percent of RAM by default, at most 16 GiB; older installations use the ZFS default of 50 percent, or 62.5 percent from ZFS 2.3.0 (Proxmox ZFS documentation). The vendor gives two rules for planning: the system requirements budget about 1 GB of RAM per TB of used storage for ZFS and Ceph. The ZFS documentation sets the ARC at no less than 2 GiB base plus 1 GiB per TiB of storage and advises reducing the ARC only with caution, because that lowers I/O performance.

WZ-IT rules of thumb (not vendor requirements):

• 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.

Two worked examples (no customer reference, only to illustrate the rules):

• Worked example 1, a single node with ZFS: 20 VMs with 4 GiB of RAM each add up to 80 GiB. A ZFS pool with 8 TiB of usable storage gives an ARC planning value of 10 GiB under the rule 2 GiB + 1 GiB per TiB (the example from the ZFS documentation). Add 2 GiB for the host: 80 + 10 + 2 = 92 GiB. With a 10 to 20 percent buffer that is roughly 101 to 110 GiB, so a node with 128 GiB of RAM.
• Worked example 2, a three-node cluster: If the VMs on each node use 60 GB of RAM in total, the two remaining nodes have to carry all 180 GB after one node fails, that is 90 GB of guests each plus 2 GB for the host (plus ARC with ZFS). The HA documentation requires designing a cluster so that it can handle this case (Proxmox HA documentation).

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 required by the system requirements. The ZFS documentation, however, recommends high-quality ECC RAM for ZFS to prevent data corruption (Proxmox ZFS documentation): an undetected bit flip in RAM can otherwise be written silently to disk, and that is precisely what ZFS cannot protect against. WZ-IT recommends ECC RAM for production; in a homelab it is nice to have.

Which storage: NVMe/SSD, ZFS and no hardware RAID

Storage is often the bottleneck. Spinning disks slow down any virtualized system; go with SSDs or NVMe. The vendor recommends SSDs with power-loss protection (PLP) for good performance and discourages consumer SSDs (system requirements). For production we therefore recommend enterprise drives with PLP.

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; according to the vendor, neither ZFS nor Ceph is compatible with a hardware RAID controller. Use an HBA in IT mode instead, which passes the disks through unchanged. Hardware RAID with a battery-backed write cache (BBU) is 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, one Gigabit network card is enough to start; for production the vendor recommends redundant (multi-)Gigabit NICs. As soon as you build a cluster, the picture changes substantially: depending on the storage technology, additional cards come into play. Separate the traffic types:

• Corosync (cluster communication): needs low, stable latency (under 5 ms between all nodes according to the documentation) and ideally belongs on its own dedicated network (Proxmox cluster documentation). 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 or 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.

Mini PC 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; the providers are compared in Proxmox hosting providers compared, and the WZ-IT offer is described on the page for managed Proxmox hosting. For high availability, plan for three nodes from the start (quorum) rather than two; with two nodes, quorum only works with an external QDevice, as the guide on a two-node cluster with a QDevice shows. The costs of software and subscription are covered in How much does Proxmox cost?.

Have your sizing reviewed

Hardware sizing is not a one-off purchase but a trade-off between workload, storage architecture and growth. We size and operate Proxmox environments, from single nodes to HA clusters with ZFS or Ceph. If you want to be sure your hardware matches the planned load, Proxmox consulting delivers an architecture document with hardware sizing; you buy the hardware directly from the manufacturer or provider of your choice. Existing environments can be assessed through an architecture review. If you do not want to run your own hardware, you rent servers with operations through managed Proxmox hosting. Ongoing operations of an existing cluster are part of Managed Proxmox. A no-obligation initial consultation clarifies your specific setup.

Repeatable installations require target disk selection to match the inventory. See automated Proxmox installation for the workflow.