Project Zomboid Dedicated Server Hardware and Mod Requirements

Project Zomboid is unusual among survival game servers because its hardware profile is dominated by zombie population, not player count. A 16-player server running the default apocalypse preset spawns far more simulated entities than a 32-player server with zombie population halved. Cellular automaton density, meta-event simulation, and corpse accumulation drive CPU and RAM far more than the number of humans connected. Size the machine against zombie density first and player slots second, or you will overpay for RAM you never touch while running out of single-thread performance you needed.

Hardware Baseline by Population Model

Config	Players	Zombie pop	vCPU	RAM	Storage
Small co-op	4-8	Normal (1.0)	2	4 GB	10 GB SATA SSD
Community default	16	Normal (1.0)	4	8 GB	20 GB NVMe
Community heavy	16-24	High (1.5-2.0)	6	12 GB	40 GB NVMe
Modded public	32+	Insane (4.0)	8	16-24 GB	80 GB NVMe

The Java process allocates a fixed heap, so under-provisioning RAM does not degrade gracefully — it stops the server with an out-of-memory error at the worst moment. Set -Xms equal to -Xmx so the heap is reserved at boot and does not get resized mid-session, and keep heap under roughly 70% of total machine RAM to leave room for the OS page cache that accelerates map chunk reads.

CPU Is the Real Constraint

Project Zomboid’s simulation loop is largely single-threaded. Zombie pathing, cell updates, and the meta-game timer all run through a primary thread, with secondary threads handling map loading and some I/O. That means a 4-core 4.2 GHz processor will beat an 8-core 2.6 GHz processor on the same world, every time. When you compare hosting quotes, look past the core count headline and find the sustained per-core clock. A server advertised as “8 cores” running at 2.4 GHz base with heavy oversubscription will produce tick spikes that a 4-core 4.0 GHz bare metal machine never shows.

Concretely: budget 1.5-2.0 GHz of sustained single-thread headroom per 8 concurrent players, and add a full core of capacity for every major mod overhaul loaded. If your provider cannot tell you the sustained clock under load rather than the boost clock, treat the specification as unknown and assume the worst case.

The Zombie Density Multiplier

Zombie population settings in SandboxVars.lua multiply the base spawn rate across the map. Going from 1.0 to 2.0 roughly doubles the number of active meta-zombies tracked per cell, and the simulation cost scales close to linearly with that figure. Moving from Normal to Insane is closer to a four-fold increase in AI work than a two-fold one, because pathing encounters more collisions and re-evaluations. Budget one additional vCPU for each 0.5 increment above 1.0 in a populated cell region, and test at the highest density you intend to allow, not the default.

Two related settings amplify this. Redistribute hours and respawn multipliers control how zombies migrate toward player activity; high values concentrate AI load in a small number of cells, which is worse for a single-threaded server than a uniform spread. Peak night population settings that spawn hordes on a timer create predictable CPU spikes every in-game night, and those are the seconds you will see rubber-banding. If you must run high density and high redistribution together, cap concurrent players below your nominal slot count to protect the simulation.

Mod Stack Impacts

• Map mods — each added map region expands the loaded cell grid and increases RAM by 1-2 GB per large map. Combine more than three large map mods and you are in 32 GB territory regardless of player count.
• Item and vehicle packs — modest RAM cost but slower boot; a 200-item pack adds minutes to startup as the game builds its item registry.
• Overhaul mods (expanded crafting, AI, or infection systems) — these add per-tick work and are the most likely to break your CPU budget. Test one overhaul at a time.
• Quality-of-life mods — low cost individually, but 60 small mods still add boot time and occasionally conflict in ways that cause tick spikes.
• Vehicle and firearm mods — cheap on memory, expensive on physics and raycast work when many entities are active in one cell.

Track heap usage and tick time after every mod addition. A single poorly written mod can double your average simulation time, and the cause is almost never the one you would guess. Keep a vanilla reference save on the same machine so you can A/B a suspect mod in minutes rather than hours.

Storage and Save Growth

Project Zomboid save folders grow with exploration and corpse accumulation. A server running for months with dozens of players exploring outward can produce multi-gigabyte save directories, and a full backup of that plus the mod set is what actually consumes disk. Allocate three to four times your expected save size for backups and rollback snapshots. NVMe is worth it here because the game reads many small region files during cell loading; sequential throughput is irrelevant but random read latency shows up as a visible hitch when a player crosses into a new cell.

B42 and Forward Compatibility

Build 42 changes baseline simulation behaviour significantly and increases the amount of tracked world state. If you are provisioning hardware now for a server you intend to run for several years, size one tier above what the current build demands. That margin is far cheaper than a mid-life migration, and it gives you the headroom to raise zombie density later without re-provisioning.

Finally, remember that JVM tuning matters as much as raw specs. A modern collector, a fixed heap, and a pinned thread layout on a machine with no noisy neighbours will outperform a faster CPU that is being shared. Dedicated hardware removes the neighbour problem entirely, which is why heavily modded Zomboid servers — with their irregular, bursty CPU demand — benefit disproportionately from bare metal. Compare chassis options for that use case on our dedicated server comparison, and check the full specs and pricing page for the RAM ceiling and NVMe configuration you will need once the mod stack grows.