Project Zomboid Server RAM and CPU: Real Numbers for 8, 32, and 64 Players

Project Zomboid’s server is single-thread dominant: game logic, zombie pathfinding, and map streaming all contend for one core. That makes it the opposite of V Rising — a high-clocked 4-core CPU beats a 16-core server chip for most community sizes. Memory is the second constraint: the persistent zombie population and chunk cache grow with player count and playtime, and modded servers add 200–500 MB per mod. A server that runs clean for 40 players on day one can grind to a crawl by week three as the world accumulates loot, corpses, and vehicle wrecks.

What 8, 32, and 64 Players Actually Need

Component	1–8 players	8–32 players	32–64+ players
CPU	2 cores @ 2.5 GHz	4 cores @ 3.2+ GHz	6–8 cores @ 3.5+ GHz
RAM	4 GB	8–12 GB	16–24 GB
Storage	10 GB SSD	25 GB NVMe	50+ GB NVMe
Bandwidth	100 Mbps	250 Mbps	500 Mbps–1 Gbps
OS	Windows/Linux	Ubuntu 22.04+ / Debian 12	Ubuntu 22.04+ / Debian 12

Single-core clock speed drives pathfinding and the zombie simulation. Choosing between a 6-core at 4.5 GHz and a 12-core at 2.8 GHz for a 32-player server? Take the faster clocks. Extra cores only help with the MapChunkThreads setting, which streams map chunks to players on login — a burst workload, not a steady one.

Install with SteamCMD

The server runs under App ID 380870 (the base game is 108600, used for Workshop resolution):

sudo apt update && sudo apt install steamcmd -y
mkdir ~/pzserver && cd ~/pzserver
steamcmd +force_install_dir /home/ubuntu/pzserver +login anonymous +app_update 380870 +quit

servertest.ini for a 32-Player Community

Core settings in ProjectZomboid64/servertest.ini:

DefaultPort=16261
UDPPort=16262
MaxPlayers=32
PingLimit=200
Open=true
Public=true
SpawnPoint=0,0,0
SafeHouse=true
AdminPassword=CHANGE_ME

Launch with ./start-server.sh -servername MyPZServer, and run it under screen or a systemd unit so it survives SSH disconnects. A minimal unit file:

[Unit]
Description=Project Zomboid Server
After=network.target

[Service]
User=pz
WorkingDirectory=/home/ubuntu/pzserver
ExecStart=/home/ubuntu/pzserver/start-server.sh -servername MyPZServer
Restart=on-failure

[Install]
WantedBy=multi-user.target

Tuning That Cuts CPU Load

• ZombieLore.PopulationMultiplier — 1.5 is challenging and playable; each step up measurably raises pathfinding CPU load. If the server lags at peak hours, this is the first dial.
• SleepAllowed=false — Prevents players skipping dangerous night cycles and keeps the simulation predictable.
• MapChunkThreads=4 — Match to core count for faster chunk streaming on login.
• AntiCheatProtection=true — Review Logs/antiCheat.log weekly.
• SaveInterval=5 — Five-minute saves limit data loss without hammering the disk.

Two underrated settings: ZombieLore.Speed (sprinters cost more CPU than shamblers because pathfinding re-evaluates more often) and vehicle counts — every wreck on the map is a simulated object. If your community is PvE-focused, capping zombie speed and trimming vehicle spawns frees enough CPU to raise the population multiplier instead.

Workshop Mods Without Breaking the Server

Subscribe to mods on Steam, note the Workshop item IDs, then set them in servertest.ini: WorkshopItems=1234567890;2345678901 and Mods=ModName1;ModName2 using the folder names under steamapps/workshop/content/108600/. Popular choices include Hydrocraft (crafting overhaul), Brita’s Weapon Pack, and Superb Survivors (NPCs) — each adds 200–500 MB of RAM and CPU load during pathfinding, so test the full mod list at your target player count before launch. The classic failure mode is adding ten mods at once and blaming the host when the server crashes at midnight; add mods one at a time and watch RAM after each.

Monitoring and Common Failures

tail -f ~/pzserver/ProjectZomboid64/server-console.txt
htop
grep "Player joined" ~/pzserver/Logs/chat.log

Lag spikes usually trace to zombie pathfinding on high population multipliers; crashes after adding mods are almost always incompatible mods — add them one at a time. Packet loss complaints point at bandwidth or the PingLimit setting rather than hardware. One more tip: Project Zomboid’s save directory grows daily, so pair your backup job with a retention policy — a 64-player world plus logs can consume 10+ GB a week.

Saves, Backups, and World Growth

Project Zomboid writes its world to ProjectZomboid64/Saves/ plus a separate directory for server settings. Unlike many games that save compact state, PZ snapshots the entire loaded map region, so saves grow every session and a 64-player world can pass 5 GB within a few weeks. Back up the save directory on a schedule, not ad hoc: stop the server, copy the folder, restart. Keep at least 7 daily and 4 weekly archives, and restore-test one of them monthly — a corrupt save discovered during a panic restore is a community-ending event.

World cleanup is part of the same habit. Corpses, vehicles, and looted containers accumulate in the save over months, and PZ has no built-in vacuum. A monthly maintenance window where you clear abandoned vehicles and cull stale chunks keeps both disk usage and save times under control. Announce it in advance — players will happily move their cars if it means faster server saves.

Anti-Cheat and Moderation Overhead

Beyond hardware, a public PZ server needs an anti-cheat and moderation plan. The built-in AntiCheatProtection=true catches the obvious exploits, but the real load is human: designate two trusted admins with in-game admin powers and review Logs/antiCheat.log weekly. Cheaters who dupe items or teleport will otherwise destabilize your economy — and the player reports will land in your Discord at 2 AM.

A modest server with a clear owner, a backup routine, and one admin is more stable than a big server with nobody watching it. Scale hardware only after you have the operational basics in place.

If OS and process management are not your focus, high-clock bare-metal game servers remove the hardware variable, leaving you to tune the game itself.