Building a Three-Node Proxmox Cluster From Mini PCs: Hardware, Quorum and Shared Storage (2026)

A single mini PC running Proxmox handles a surprising amount of home lab work. The moment it reboots for a kernel update, though, everything on it goes dark at once: DNS, Home Assistant, the reverse proxy, the thing your household actually notices. Clustering is how you stop one reboot from becoming an outage.

This guide is for anyone who already runs Proxmox on one box and is weighing a second and third. It covers why the node count matters, what a cluster genuinely delivers at home versus what the marketing implies, how to pick three machines that behave the same way, and the three realistic shared-storage paths. It also covers the case against clustering, because for plenty of home labs a single larger host is the smarter build.

Specifications quoted here come from the manufacturer listings for each machine. Nothing below is a measured result.

Why three nodes and not two

Proxmox uses Corosync to maintain a quorum, and quorum needs more than half the votes present to allow changes. With two nodes, each holds one vote. Lose either one and the survivor has 50%, not a majority, so the cluster goes read-only and refuses to start guests.

Three nodes fix that arithmetic. Two surviving votes out of three is a majority, so the cluster keeps operating and can restart guests from the failed node elsewhere. You can bolt a QDevice onto a two-node cluster to act as a tiebreaker vote, and that works, but it needs a third always-on device anyway and it does not give you anywhere to run the recovered workloads.

Four nodes do not improve fault tolerance per dollar of power compared with three: you still only tolerate one failure, because two out of four is not a majority. Odd numbers are the sensible shape, and three is the smallest useful one.

What clustering actually buys you at home

The honest list is shorter than people expect, but each item is genuinely useful.

• One management plane. Log into any node and see every VM, container, backup job and storage pool across the cluster. No more bookmarking three web UIs.
• Live migration. Move a running VM to another node with no shutdown. This is the feature that makes patching painless — drain a node, update it, reboot, move things back.
• High availability. With HA configured and shared or replicated storage, a dead node’s guests restart automatically on a survivor after a short fencing delay.
• Shared configuration. Users, storage definitions and firewall rules live in the clustered filesystem, so they apply everywhere.

What it does not buy you: protection against a bad update you applied to all three nodes, or against deleting a volume. HA is not backup. You still need a proper backup strategy running against the cluster, ideally to storage that lives outside it.

Choosing three machines that match

Matched nodes make life easier. Identical CPU generations mean live migration works without masking CPU flags, identical RAM capacity means you can actually fit the workloads anywhere, and identical NVMe layouts mean your storage config is copy-paste across all three.

The low-power route: N150-class nodes

An Intel N150 cluster is the cheapest way in terms of electricity. The Beelink EQ14 is a reasonable template: N150 with a 3.6 GHz boost, 16GB DDR4, a 500GB NVMe drive, two M.2 PCIe 3.0 slots supporting up to 8TB total, and crucially dual 2.5G LAN. Two NICs per node is what lets you separate cluster traffic from everything else without USB adapters.

The ceiling is real. Four efficiency cores and a 16GB soldered-or-single-channel memory budget means three of these together still total 48GB. Fine for DNS, Home Assistant, a reverse proxy, Pi-hole, monitoring and a few small containers. Not fine for a Windows VM with a GPU passthrough dream attached.

The capable route: Ryzen 8845HS / 8945HS-class nodes

Zen 4 mobile chips change what fits on a node. The GMKtec K8 Plus pairs a Ryzen 7 8845HS (3.8 GHz base, up to 5.1 GHz, 8 cores) with 16GB DDR5-5600 and a 1TB PCIe 4.0 NVMe, two SO-DIMM slots taking up to 128GB, two M.2 2280 slots, dual 2.5GbE and selectable 35W, 54W or 65W modes. That power-mode switch is genuinely relevant for an always-on cluster node.

The Minisforum UM890 Pro steps up to a Ryzen 9 8945HS with 8 cores and 16 threads, ships with 32GB DDR5-5600 and a 1TB PCIe 4.0 drive, expands to 96GB, and includes two M.2 2280 slots plus dual 2.5G Ethernet and an OCuLink port. Starting at 32GB per node means a three-node cluster has 96GB of RAM on day one, which is enough headroom to lose a node and still run everything.

Both of these are covered in more depth in our roundup of mini PCs for a Proxmox home lab if you want the single-host comparison.

RAM, NVMe and the cluster network

Size RAM for n-1. If three nodes each hold 32GB and you want to survive one failure, your total committed guest memory should fit in 64GB. That is the real cost of HA — you buy capacity you deliberately leave empty.

Two NVMe slots per node is close to mandatory. One drive carries the Proxmox install, the second becomes your replicated or Ceph data drive. Consumer drives are workable for home clusters, but write endurance matters more here than in a desktop, because replication and Ceph both amplify writes. A Gen 4 drive like the Samsung 990 EVO Plus, rated to 7,250 MB/s sequential read with a nickel-coated controller for thermal efficiency, is a sensible data drive in the Ryzen nodes with their PCIe 4.0 slots.

For networking, put Corosync and storage replication on the second 2.5G NIC through a dedicated switch or VLAN, and leave the first NIC for guest and management traffic. Corosync cares far more about consistent low latency than bandwidth; a saturated link shared with a backup job is what causes spurious node fencing. Ceph is the exception that genuinely wants throughput, and 2.5G is the practical floor for it.

Shared storage: Ceph, ZFS replication or a NAS share

This is the decision that shapes the whole build.

Approach	Minimum sensible nodes	Failover behaviour	Network demand	Best fit
Ceph (hyper-converged)	Three with OSDs on each	Near-zero data loss, guests restart on survivors	High; wants dedicated 2.5G or faster	Ryzen-class nodes with spare RAM and a second NVMe each
ZFS replication	Two, three for quorum	Rolls back to last replication snapshot	Low to moderate, bursty on schedule	Most home clusters, including N150 nodes
NAS share (NFS or iSCSI)	Three for quorum	Instant failover, but NAS is a single point of failure	Moderate and constant	Labs that already own a capable NAS
Local storage only	Three for quorum	No automatic failover; manual restore from backup	Minimal	Clusters built for management convenience, not HA

ZFS replication is the right default for most people. You set a schedule, Proxmox ships incremental snapshots to the other nodes, and a failover loses only the minutes since the last sync. Ceph is more elegant and loses nothing, but it asks for RAM, CPU, drive endurance and network headroom that N150 nodes do not have.

The NAS route is tempting if you already have one, though it concentrates risk: the NAS dying takes down every guest at once. If you are weighing storage topologies more broadly, our comparison of DAS versus NAS for a mini PC server covers the attachment options.

Power, noise and when one bigger host wins

Three always-on machines draw roughly three times the idle power of one, and idle is where a home lab spends almost all its time. Nobody should pretend otherwise. N150 nodes keep that penalty small; a trio of 8945HS boxes is a meaningfully different electricity bill, even with power-mode limits applied.

Choose a single larger host instead if your workloads are mostly stateless containers you can rebuild quickly, if you have no second NIC and no managed switch, or if the services you run genuinely tolerate a ten-minute monthly reboot window. One 64GB Ryzen box with good backups is simpler, quieter and cheaper to run than three nodes, and simplicity has real value when you are the only administrator.

Whichever shape you pick, put the cluster behind a UPS. A dirty power event across all three nodes simultaneously defeats the entire point of HA, so sizing a UPS for a home server is part of the build, not an afterthought. Keep the nodes well ventilated too — stacked mini PCs recirculate each other’s exhaust, and cooling mods for mini PC servers are worth reading before you shelve them tightly together. Any new circuits or in-wall wiring for the rack should follow local electrical code and go to a licensed electrician where required.

The build to actually make

For a cluster meant to run real household services with HA, buy three Minisforum UM890 Pro units. The 32GB of DDR5 per node gives you the n-1 headroom that makes failover honest, the dual 2.5G ports let you isolate Corosync properly, and two M.2 slots per node support either ZFS replication or a modest Ceph pool. Add a second NVMe per node — the Samsung 990 EVO Plus suits the PCIe 4.0 slots — and keep replication on a dedicated 2.5G switch.

If budget and power draw are the binding constraints, three Beelink EQ14 nodes with ZFS replication produce a cluster that does live migration and HA for small services at a fraction of the idle load. Accept the RAM ceiling and keep workloads light. The GMKtec K8 Plus sits between the two: Zen 4 performance with selectable 35W, 54W and 65W modes, so you can tune each node toward efficiency after the lab settles down.

Build one node first, get your storage and backup pattern working, then add the other two. A cluster you understand beats a cluster you assembled in one weekend.

How these picks were chosen: HomeNode compares products using manufacturer specifications, current Amazon listing details and published owner feedback. Products are not tested in-house, and listings change often, so confirm current specifications on the product page before buying.

Affiliate disclosure: As an Amazon Associate, HomeNode earns from qualifying purchases at no additional cost to you.