How Much RAM Do You Need for Proxmox and a Homelab

You’re sizing a homelab box and the RAM question is the one that actually decides what you can run. So how much RAM for Proxmox do you actually need? CPU cores matter, storage matters, but RAM is the wall you hit first. Spin up one VM too many on a 16GB node and the OOM killer starts reaping processes, or worse, swap thrashing drags the whole host to a crawl. I have watched it happen on my own cluster more than once.

This guide breaks down where RAM actually goes on a Proxmox VE host: the hypervisor base, each VM and LXC container, the ZFS ARC cache (the single biggest surprise for newcomers), plus KSM, ballooning, and the headroom you need for backups and live migration. Then a concrete tier table for 16GB, 32GB, 64GB, and 128GB so you can match the box to the workload. The numbers come off two live Proxmox nodes I run, not a spec sheet.

Measured on my Proxmox VE 8.4 nodes in June 2026.

Start with the Proxmox host base

Proxmox VE itself is lean. The kernel, the management daemons (pveproxy, pvedaemon, pvestatd), the web UI, and the cluster stack together idle at roughly 1.5 to 2GB. That is your floor before a single guest boots.

Here is what one of my nodes reports with the hypervisor running plus one light VM (a single Ubuntu guest) booted:

free -h

On a 64GB node, used memory sits around 7GB with just the host and one VM. Most of that is the running guest, not Proxmox:

               total        used        free      shared  buff/cache   available
Mem:            62Gi       7.1Gi        53Gi        65Mi       2.8Gi        55Gi
Swap:          8.0Gi          0B       8.0Gi

Two things to read off that. First, a 64GB stick of RAM shows as 62GiB once the BIOS and integrated graphics carve out their reserved regions, so never plan to use the full nameplate number. Second, swap is present but completely unused, which is exactly what you want. A homelab host that is dipping into swap under normal load is a host that needs more RAM, not a bigger swap file.

Size each VM and LXC container

Every full VM carries the weight of its own guest kernel and userland on top of whatever the workload needs. A bare Linux VM idles around 0.5 to 1GB. Give it a database, a web app, or a Kubernetes node and that climbs fast. A Windows Server guest wants 4GB before it does anything useful.

LXC containers are the cheat code here. A container shares the host kernel, so it skips the whole guest-OS overhead. The same workload that needs a 2GB VM often runs comfortably in a 512MB to 1GB LXC. This trips people up: they default everything to a VM out of habit and then wonder why their RAM evaporated. If the workload is Linux and you do not specifically need kernel isolation or a different kernel version, reach for an LXC first.

A rough per-guest budget I use when planning a node:

These are the amounts to assign, not the absolute minimums. A VM you starve will technically boot and then perform terribly, which is its own kind of waste. Size for the working set, not the floor.

Tame the ZFS ARC (this is the one that surprises everyone)

If you installed Proxmox on ZFS, the ARC (Adaptive Replacement Cache) is the single biggest RAM consumer you did not plan for. ZFS uses spare RAM as a read cache, and the more you give it the faster reads get. The gotcha is the default ceiling.

On a fresh Proxmox VE install (8.1 and newer, including VE 9) the installer caps the ARC at 10% of host RAM, clamped to 16GiB max. That is sane. The problem is pools created outside the installer, or older installs, or a stock OpenZFS setup: there the ARC defaults to up to 50% of RAM (62.5% on ZFS 2.3.0 and newer). Half your RAM silently vanishing into cache is the “ZFS ate my memory” complaint you see on every homelab forum. The cache will give that RAM back under pressure, but VMs and the ARC fighting over the same pages is not a fight you want to referee.

You can see exactly where your ARC is sitting. On my node the cap is set explicitly, and ZFS ships a summary tool:

arc_summary | head -20

The cap, the current size, and the hit ratio all print at the top. Note that the ARC is capped at 6.3GiB and is using 3.3GiB right now, well under its limit:

ARC status:                                                      HEALTHY
        Memory throttle count:                                         0

ARC size (current):                                    51.9 %    3.3 GiB
        Target size (adaptive):                        95.9 %    6.0 GiB
        Min size (hard limit):                         31.3 %    2.0 GiB
        Max size (high water):                            3:1    6.3 GiB

The interesting part is whether that modest cache is actually doing its job. Pull the raw hit and miss counters:

cat /proc/spl/kstat/zfs/arcstats | grep -E '^hits|^misses'

On this node that is 7,771,952 hits against 233,188 misses, a 97% hit ratio from a cache capped at just over 6GiB:

hits                            4    7771952
misses                          4    233188

That 97% number is the point. You do not need to hand ZFS half your RAM to get an effective cache. A few gigabytes serves the working set on a typical homelab pool, which frees the rest for VMs. So cap it.

The cap lives in a tiny modprobe file. Open it:

sudo vim /etc/modprobe.d/zfs.conf

Set zfs_arc_max to a value in bytes. This caps the ARC at 6GiB (6 multiplied by 1024 three times):

options zfs zfs_arc_max=6442450944

Because the ZFS module loads from the initramfs on a ZFS-root system, rebuild it and reboot for the change to stick:

sudo update-initramfs -u -k all
sudo reboot

Skip the rebuild step and the cap silently does nothing after the next boot, because the running module never reads your new file. A sensible starting point is 1 to 2GiB of ARC per terabyte of pool you actually want cached, then watch the hit ratio and adjust. How much pool you have depends on your layout, and the ZFS RAID level you choose changes both usable space and how hard the ARC works. If you are picking SSDs for that pool, the NVMe versus SATA datastore breakdown covers why power-loss protection matters more than raw speed.

Account for KSM, ballooning, swap, and migration headroom

Three Proxmox features quietly stretch the RAM you have, and one workload quietly demands more. Worth knowing all four before you commit to a tier.

KSM (Kernel Same-page Merging) deduplicates identical memory pages across VMs. Run five Ubuntu guests and they share a lot of identical kernel and library pages, so KSM reclaims that overlap. Proxmox starts merging once host RAM usage crosses about 80%, so on a node that is not under pressure you will see pages_sharing sitting at zero, which is normal. It is a safety net for overcommit, not free RAM you can bank on at planning time.

Ballooning lets a VM hand idle RAM back to the host. Set a minimum and a maximum on the guest, and Proxmox reclaims the slack between them when the host gets tight. It helps you overcommit, but a ballooned-down VM that suddenly needs its RAM back can stall, so do not treat the maximum as if it costs nothing.

Swap is your last line of defense, not a capacity plan. On Proxmox the host swappiness defaults to 60. If a node is regularly swapping under normal load, that is the signal to add RAM, not to grow swap. ZFS-root installs ship without a swap partition by default for exactly this reason, so check whether yours even has one.

Migration and backups are the headroom eater people forget. Live-migrating a 16GB VM to another node, or running a Proxmox Backup Server job, both need working memory on top of your steady-state usage. Leave roughly 10 to 15% of total RAM unallocated as breathing room. A node that is provisioned to 100% has nowhere to put a migrating guest.

Match the RAM tier to what you actually want to run

Here is the part you came for. With the host base, per-guest budgets, and a capped ARC in mind, this is what each common RAM tier realistically runs in a homelab. The “comfortable load” column assumes ZFS with the ARC capped sensibly and 10 to 15% headroom left free.

My own nodes run 64GB each, and on the day I captured these numbers one node was using around 7GB and the other under 9GB because most VMs were powered off. That gap is the real lesson: provisioned RAM and used RAM are different numbers. You size for the moment everything is running at once, not for a quiet Tuesday. If you are still choosing the box itself, the homelab mini PC picks for Proxmox call out the RAM ceiling on each model, which matters more than you would think (more on that next).

ECC vs non-ECC, and the SO-DIMM ceiling on mini PCs

Two hardware choices shape what you can actually buy.

ECC versus non-ECC. ECC RAM detects and corrects single-bit errors before they reach your data. For a 24/7 server holding anything you care about, it is the right call. The persistent myth is that ZFS requires ECC or it will corrupt your pool (the “scrub of death”). It does not. The OpenZFS project is explicit that ZFS works fine without ECC, and that ECC is good advice for any important data, ZFS or not. So: ECC is recommended for a server you trust with real data, but a non-ECC homelab node running ZFS is not a ticking time bomb. Run what your hardware supports and your budget allows.

The catch is that most homelab mini PCs simply cannot take ECC. They use laptop-style SO-DIMM slots and consumer chipsets that do not validate ECC. If ECC is non-negotiable for you, that pushes you toward a used enterprise box (a Dell or HPE tower, a small server) with UDIMM or RDIMM slots, where a module like the Kingston Server Premier DDR5 ECC UDIMM drops in. Always check the board’s QVL first; ECC support is a motherboard feature, not just a RAM feature.

The mini-PC ceiling. This is the constraint that quietly decides your future. A typical homelab mini PC has two SO-DIMM slots and tops out at 64GB or 96GB of DDR5 depending on the platform. Some single-slot or LPDDR5 units are soldered and cannot be upgraded at all. So buy the box that can reach the tier you will want in two years, not just the tier you need today. If you land on a 2-slot mini PC, a Crucial 32GB DDR5-5600 SO-DIMM kit takes a 16GB starter box to a comfortable 32GB or 48GB without touching the rest of the build. Full-size servers using RDIMM scale into the hundreds of gigabytes, which is why people who run genuinely heavy labs end up on a used rack server rather than stacking mini PCs. The same logic applies to the storage you bolt on; the SSD and NVMe picks for servers and homelab separate the consumer drives from the enterprise ones with power-loss protection.

What I would change for a production-leaning node

If this were carrying anything I genuinely depended on rather than a learning lab, three things change. I would spec ECC RAM on a board that validates it, which alone rules out most mini PCs and points at a used enterprise box. I would cap the ZFS ARC deliberately from day one rather than discovering it after a VM gets OOM-killed, and I would leave a hard 15% of RAM unallocated so live migration and backups always have somewhere to land. And I would buy the node with the highest RAM ceiling I could justify, because the workload always grows and replacing a sold-out mini PC a year later is its own headache.

The short version: a 32GB node is the honest pick for a first real homelab, 64GB is where it stops feeling cramped, and the ARC cap is the one setting you should not skip. Get those right and the RAM question stops being the thing that decides what you can run. For the full first-boot checklist once the box is built, the post-install steps for Proxmox VE include the ARC cap and a few other settings worth doing early.