Short version: 10GB is the honest minimum for a real Build 42 server, most groups belong at 12GB, and heavily modded or 20+ player servers want 16GB. We measured this the hard way: a fresh B42 world being generated in an 8GB container was OOM-killed by the kernel, twice, before it ever finished — total usage during generation peaks above 9GB. B42 is substantially hungrier than B41 was, and undersizing shows up as stutter and rubber-banding long before anything crashes. Here's the reasoning, so you can size for your group instead of guessing.
Why Build 42 needs more than B41 did
Server admins ran B41 comfortably on 4–6GB for years. Three B42 changes moved the floor:
- Animals. Herds graze, migrate and path across the map continuously, server-side, whether players watch or not.
- Basements and true multi-storey buildings. More world volume loaded and simulated per cell, plus the lighting model that came with it.
- The crafting/world-state overhaul. Far more persistent objects tracked per tile than B41.
On top of that, the server is a Java application: it doesn't just use memory, it cycles it. The JVM allocates constantly and reclaims in garbage-collection passes. Give it too little heap and GC runs hot — and every major GC pause is felt by every player at once.
The numbers
As of Build 42.20, community consensus and our own fleet experience agree on roughly:
| Server | Heap (-Xmx) | Machine RAM | Notes |
|---|---|---|---|
| 2–4 friends, vanilla | 4–5GB | 6–8GB | Runs, but no headroom for mods or a growing save |
| Up to ~10 players, light mods | 6GB | 10GB | The honest entry point for B42 — first-boot world generation alone peaks above 9GB |
| 10–20 players, real mod list | 8–9GB | 12GB | Where most settled groups belong |
| 20+ players, heavy mods, old world | 11–12GB | 16GB | Long-running community servers |
Two rules hide in that table:
- The ~6GB base is before mods. A B42 server with a serious mod list starts above where a vanilla one peaks. Item-heavy and map-expansion mods cost the most.
- Budget roughly ½GB per player beyond the base as a planning figure. Player count matters less than people assume — the world simulation is the fixed cost — but connections, loaded cells around each player, and their vehicles add up.
The 75% rule: heap ≠ machine RAM
The JVM heap (-Xmx) must be smaller than the machine's RAM — the JVM itself, the OS, and off-heap memory need the rest. Server admins' rule of thumb: leave ~3GB outside the heap — B42's world generation and map streaming allocate native memory the heap number never shows, e.g.:
# 10GB machine ./start-server.sh -Xmx6g # 16GB machine ./start-server.sh -Xmx12g
Set -Xmx to the full machine size and Linux's out-of-memory killer will eventually terminate the server mid-save — worse than the GC stutter you were trying to fix. (On managed hosting this derivation is done for you; on our servers the heap is set to 75% of the plan automatically.)
Symptoms of too little RAM
- Rhythmic whole-server hiccups — everyone freezes for half a second at once, every minute or so: classic major-GC pauses from a heap running near-full.
- Rubber-banding that gets worse with uptime and resets after a restart: heap pressure climbing as the session ages.
- Login storms hurt — three players joining at once spikes allocations; an undersized server stutters hard exactly when people arrive.
- Eventual
OutOfMemoryErroror the OOM killer in the logs — the end state.
If that list sounds familiar but RAM checks out, the cause may be simulation load instead — see B42 server lag and desync fixes.
How to measure what your server actually uses
Don't size on vibes — the numbers are easy to read:
- On the box:
htop(orfree -h) shows the server process's resident memory. Watch it across a full evening session, not at boot — a B42 server's working set grows for the first hour as cells load and players spread out. - Heap vs resident: the Java process's resident memory will sit above
-Xmx— heap plus the JVM's own overhead and off-heap buffers. That gap is exactly why the 75% rule exists. - The number that matters: peak resident during your busiest session, plus ~20% headroom. If that lands above the machine's RAM, you're borrowing from the OS page cache and the stutter has already started.
Measure again after any big mod-list change — a single map-expansion mod can move the baseline by a gigabyte.
Growth over time: why week one lies to you
A fresh B42 world is the smallest your server will ever be. Three growth curves stack on top of each other:
- Session growth — heap fills as the session ages; a restart resets it. Normal, managed by scheduled restarts.
- World growth — every looted container, corpse and player-built wall persists. A three-month world carries meaningfully more state than a fresh one, and it never shrinks on its own.
- Mod-list growth — lists only ever get longer.
Practical upshot: size for month three, not day one. A group that exactly fits 10GB at launch belongs on 12GB, because they'll be there by October anyway — moving before the stutter starts is cheaper than diagnosing it after.
Swap is not a substitute
One tempting dodge: give the machine swap and oversize the heap. It doesn't work here — the JVM touching swapped-out heap during a GC pass turns a 100ms pause into a multi-second freeze. A Zomboid server should fit in physical RAM, full stop; if it can't, reduce the heap and the mod list, or get a bigger machine.
Frequently Asked Questions
How much RAM does a Build 42 server need for 10 players?
About 7GB of heap on a 10GB machine for a lightly-modded server — 12GB of machine RAM if your mod list is real. B42's base simulation costs ~6GB before mods, which is why the old B41 4GB folk wisdom no longer applies.
Does more RAM fix server lag?
Only lag caused by heap pressure (the rhythmic everyone-freezes stutter). Lag from simulation load — animals, huge bases, save bloat — is CPU-side and needs different fixes. Diagnose before buying.
What is -Xmx and what should I set it to?
The JVM's maximum heap. Leave about 3GB for everything outside the heap — -Xmx7g on 10GB, -Xmx13g on 16GB. Too high risks the OS killing the server during world generation; too low causes GC stutter.
Do mods really use that much memory?
The big ones do. Item packs, map expansions and overhaul mods each add persistent objects the server tracks continuously. Server admins commonly see a 50+ mod list add several GB over vanilla — it's the difference between the 8GB and 12–16GB rows above.
Sizing honestly is why our Project Zomboid hosting plans start at 8GB — a B42 plan smaller than that would be selling you the stutter.
