How Many VMs Can an N100 Mini PC Run?

The short answer: on a typical 16 GB N100 mini PC, expect two to three full VMs plus half a dozen containers, and expect to run out of memory long before you run out of CPU.

That is the part most capacity questions get backwards. The N100 has four cores and no hyper-threading, which sounds thin, but homelab guests spend almost all their time asleep. Memory does not work that way: a VM holds every megabyte you assign it whether it is busy or not. Cores are shared, RAM is not, and that single asymmetry decides the answer.

The three ceilings, in the order you hit them

Memory, first and hardest. Intel’s specification for the N100 lists a 16 GB maximum. Many boards do run a 32 GB SODIMM in practice, but that is outside the documented spec, it depends on the specific board’s firmware, and boxes with soldered LPDDR5 cannot be upgraded at all. Plan the build around 16 GB and treat anything more as a bonus.

Storage I/O, second. Most N100 boxes have exactly one M.2 slot. Every guest’s writes queue behind every other guest’s writes on one consumer NVMe drive. Four idle VMs are fine; four VMs all running apt upgrade at 06:00 is where the host feels slow. Storage layout for a mini PC homelab covers what a second slot or a SATA position buys.

CPU, a distant third. Four cores at up to 3.4 GHz is plenty for services that idle. It becomes the limit only for sustained work: software video encoding, large compiles, a database under real load.

A memory budget you can actually add up

Proxmox VE’s published requirements are a floor, not a plan. These are workable allocations for a small host, drawn from each project’s own documented minimums plus the headroom a 24/7 box needs:

Guest	Type	Sensible allocation
Proxmox VE host itself	—	2 GB
ZFS ARC (if root is ZFS)	—	~1 GB per TB managed
Pi-hole / AdGuard Home	LXC	128–256 MB
Reverse proxy (Caddy, NPM)	LXC	256–512 MB
Tailscale or WireGuard gateway	LXC	128 MB
Jellyfin or Plex	LXC	1–2 GB
Docker host for small apps	LXC or VM	2–4 GB
Nextcloud	LXC	2 GB
Immich (with machine learning)	VM	4 GB+
Home Assistant OS	VM (required)	2–4 GB
OPNsense or pfSense	VM	2 GB
Proxmox Backup Server	VM	2 GB
Windows 11	VM	6 GB realistic

Two entries in that table deserve attention because they quietly eat the budget.

ZFS ARC. If the Proxmox installer laid the root filesystem out as ZFS, the adaptive replacement cache takes a share of RAM by default. Recent installers cap it at 10% of system memory rather than the old 50% rule, but on a 16 GB box that is still 1.6 GB gone before a single guest starts, and adding a large data pool later pushes it up. The Proxmox ZFS documentation covers how to pin zfs_arc_max to a fixed value; on a memory-constrained host, pinning it is worth doing deliberately rather than leaving it to a percentage.

Home Assistant OS. It is a full appliance image and has to run as a VM, not a container. That one decision costs 2–4 GB of hard-allocated memory on a host that only has 16, which is why it usually lands as the single largest guest in a small lab.

Why containers change the arithmetic

A VM is given memory. A container borrows it.

An LXC container shares the host kernel, so its “memory” is a cgroup limit rather than a reservation — a Pi-hole container capped at 512 MB but using 90 MB leaves the other 422 MB genuinely available to everything else. The Proxmox container documentation describes the model; the practical effect is that ten containers can coexist on a box that would choke on four VMs of the same nominal size.

So the honest formulation of “how many VMs can an N100 run” is: as few as you can get away with. Run everything as an LXC container unless something forces a VM:

• The workload needs a different kernel (Windows, BSD, Home Assistant OS).
• It needs a real, isolated kernel boundary for security reasons.
• It needs a device passed through in a way containers cannot manage.

Notably, hardware video transcoding is not on that list. A Plex or Jellyfin container can reach the N100’s integrated GPU through a device node, no passthrough and no VM required — the LXC route to the iGPU is both simpler and cheaper in memory. What that GPU can and cannot do once it gets there is in the N100 Plex transcoding limits.

Three stacks that fit on 16 GB

Stack A — the media and network box (comfortable). Proxmox 2 GB, Jellyfin LXC 2 GB, *arr-stack Docker LXC 2 GB, Pi-hole 256 MB, reverse proxy 512 MB, Tailscale 128 MB. Total around 7 GB, no VMs at all. Everything else is free for page cache, which is where the remaining RAM does the most good anyway.

Stack B — the home automation box (typical). Proxmox 2 GB, Home Assistant OS VM 4 GB, Zigbee/MQTT LXC 512 MB, Node-RED LXC 512 MB, Pi-hole 256 MB, backup client 256 MB. Around 7.5 GB, one VM. Adding Frigate for camera work is what breaks it: continuous object detection wants both more RAM and sustained CPU, and that is a genuine reason to step up a tier.

Stack C — the “everything” box (tight). Proxmox 2 GB, Home Assistant OS VM 4 GB, Windows 11 VM 6 GB, Docker LXC 2 GB, Pi-hole 256 MB, reverse proxy 512 MB. That is roughly 15 GB of a 16 GB machine with the host’s own page cache still to pay for. It runs, and it is one apt upgrade away from swapping.

The pattern across all three: the number of containers barely matters. The number of VMs is the whole game, and two is a comfortable ceiling on 16 GB while three is an argument.

CPU: how much oversubscription is fine

A guest with 2 vCPUs does not reserve two cores, it is simply allowed to use up to two when it needs them, and the host scheduler sorts out the rest. So the total assigned across all guests can exceed the physical core count — on a four-core N100, two to three times over is unremarkable when the workloads are idle-dominant.

That is permission to oversubscribe, not permission to be careless: hand each guest what its workload can actually use and no more. A container that will never saturate one core does not become faster with four vCPUs, it just adds scheduling overhead for every other guest.

Two rules keep it honest:

• Never give a single guest all four cores. Leave the host a core to schedule on, or a busy guest makes the web interface unresponsive and you lose the ability to fix it.
• Watch io-wait, not CPU percentage. On a single-NVMe box, a host that looks 40% busy but shows high io-wait is storage-bound, and adding vCPUs will not help.

The one workload that changes this calculus is software transcoding. If Quick Sync cannot handle a format and the media server falls back to CPU, a single stream can consume the entire chip. That is a codec problem rather than a capacity problem, and it is worth understanding before blaming the host.

The symptoms of a host that is over-committed

In order of how early they appear:

1. Swap in use on the host. free -h showing anything meaningful in swap on a Proxmox node means the memory budget is already wrong. Fix the allocation; do not add more swap.
2. Kernel samepage merging working hard. KSM deduplicates identical pages between guests once memory pressure rises. Useful, but a KSM figure in the gigabytes means it is papering over an over-commitment.
3. Ballooning fighting the guests. Memory ballooning reclaims RAM from VMs under pressure; guests respond by dropping their own caches and getting slower in ways that look like an application bug.
4. Rising io-wait and sluggish web interface. Usually the single NVMe drive, not the CPU.
5. The out-of-memory killer. By this point something has already been terminated, and it is rarely the guest you would have chosen.

The first two are early warnings you can act on. Set an alert on host swap usage on day one; it is the cheapest capacity monitor there is.

When to buy a bigger box instead

Step up if any of these is true:

• More than two VMs are genuinely required — not “would be convenient”, but required by kernel or OS.
• A workload does sustained CPU work: continuous camera object detection, software encoding, CI builds.
• 32 GB is needed with the vendor’s blessing, rather than as an out-of-spec SODIMM gamble.

The eight-core N305 sold configured with a 32 GB SODIMM is the natural next step — note that this is the vendor going beyond Intel’s documented 16 GB ceiling, on the same single memory channel as the N100, so buy it that way rather than upgrading one yourself. It is a bigger jump than the specification difference suggests; the N100 versus N305 versus N97 comparison sets out why core count rather than clock speed is what separates these parts. If you are buying new in 2026 the shelves are mostly N150 rather than N100, and that refresh changes less than it appears to — same 16 GB single-channel ceiling, so the capacity maths above is unchanged. For the full tiering, including where the jump to a prosumer box with dual 10GbE stops making sense, see the best mini PC for a Proxmox homelab.

Before spending anything, run the intended service list through the mini PC picker and TCO calculator: a box that costs $60 more and idles three watts lower is often the cheaper machine over five years.

TL;DR

• 16 GB N100: two to three VMs and six-plus LXC containers. Memory is the binding constraint, not cores.
• Budget 2 GB for the host, plus ZFS ARC if root is ZFS, before allocating anything to guests.
• Use LXC unless a different kernel is genuinely required. Containers borrow memory, VMs reserve it.
• Home Assistant OS and Windows are the expensive guests — they must be VMs and they dominate a 16 GB budget.
• Oversubscribe vCPUs freely, but leave the host a core, and watch io-wait rather than CPU percentage.
• Host swap in use is the signal to stop adding services, well before the OOM killer makes the decision for you.

Once the service list is settled, the next two chores are the ones that keep the box reachable: the BIOS pass a 24/7 homelab needs, and a starter self-hosting stack that puts the services on in an order that does not paint you into a corner.

Related across the network

• ComfyUI Out of Memory Errors: Causes and Fixes — comfyuiops.com
• ComfyUI GPU Requirements: How Much VRAM You Need — comfyuiops.com