Project Zomboid server RAM: heap and plan

A Project Zomboid dedicated server needs about 3 GB of memory for two to four players sharing one town on vanilla settings, 4 to 6 GB for eight to sixteen players spread across the map, and 8 to 10 GB for sixteen to thirty-two players with workshop mods and map mods. Because the server is a Java program, the plan is only half the answer: the Java heap, set with -Xmx, has to sit at roughly 70 to 80 per cent of the plan so the rest of the process fits around it. Get the plan right and the heap wrong and the server is stopped for running out of memory while Java still believes it has room. The biggest driver after that is not player count but spread - four players in four towns cost more than ten in one.

What a Zomboid server keeps in memory#

The server runs the whole world for every player, and its memory is made of four things.

• Loaded map cells and chunks around each player. The map is a grid of cells, and the server keeps the area around every connected player loaded: buildings, furniture, containers, items on the floor, vehicles and zombies in that area. Players in the same town share one loaded area. Players scattered across Muldraugh, Riverside and Louisville load three.
• Zombies. The zombie population is tracked across the map, and zombies near players are fully simulated. Population settings set how many exist; how many are active at once follows how many areas are loaded.
• Items and vehicles. Every item in a loaded container or on the floor, every vehicle with its parts and trunk contents. Players hoard, and a base with thirty stuffed crates and a car park of looted vehicles is a lot of objects.
• Mods. Lua scripts, item definitions, textures for the server's own bookkeeping, and for map mods whole additional regions of cells.

All of it sits in the Java heap, apart from the JVM's own overhead, which is outside it and is the reason the heap must be smaller than the plan.

RAM by group and server type#

Read the table by where players will be, not just how many. A small private group that all lives in one compound needs the first row even if it has eight people. A community of twelve who each claim a different town needs the third, before any mods are installed.

Setting the Java heap correctly#

The server is started by a Java launcher that reads its JVM arguments from a JSON file in the server folder, ProjectZomboid64.json on 64-bit installs. The heap is the -Xms and -Xmx entries in its vmArgs list:

{    "mainClass": "zombie/network/GameServer",    "classpath": ["."],    "vmArgs": [        "-Djava.awt.headless=true",        "-Xms2g",        "-Xmx4g"    ]}

The real file carries more arguments than this, including garbage collector options that vary between game builds. Change only the two heap lines and leave the rest as shipped. On the Windows batch launcher the same two flags appear in StartServer64.bat. On a panel-based host the heap is often exposed as a Startup variable instead; if it is, use that rather than editing the file, because the panel may rewrite the file on reinstall.

What the two flags mean:

• `-Xmx` is the maximum heap. This is the number that matters.
• `-Xms` is the starting heap. A modest starting value is fine; setting it equal to -Xmx makes the JVM claim everything up front, which is harmless if the maximum is correct and makes the memory graph easier to read.

The rule for the maximum is the same as for any JVM server: leave room outside the heap. Metaspace for loaded classes, thread stacks, the JIT compiler's code cache and native buffers for networking all count against the container's limit and none of them is inside -Xmx.

What raises memory without new players#

Several sandbox and server settings change memory more than adding a player does. They live in the two files for your server name - servertest.ini and servertest_SandboxVars.lua by default, in the Zomboid/Server folder.

Zombie population

Zombies sets the overall population preset, and the ZombieConfig block refines it:

Zombies = 3,ZombieConfig = {    PopulationMultiplier = 1.0,    PopulationStartMultiplier = 1.0,    PopulationPeakMultiplier = 1.5,    PopulationPeakDay = 28,    RespawnHours = 72.0,},

Population scales memory and CPU directly. Note the peak: with the defaults, density rises towards one and a half times the starting level by day 28, so a server sized on day three can be short in week four for no reason anyone changed. Size for the peak. RespawnHours matters too - respawn refills cleared towns, so zombies never stop being a cost. Setting it to 0 disables respawn, and on many multiplayer servers that is both a gameplay improvement and a slow reduction in load. SandboxVars explained covers every option.

Items on the floor

Players drop things. Over months, a server accumulates dropped clothing, empty cans and bags in every street people have walked down. The server ini has a cleanup for this:

HoursForWorldItemRemoval=24.0WorldItemRemovalList=Base.Hat,Base.Glasses,Base.MaggotsItemRemovalListBlacklistToggle=false

HoursForWorldItemRemoval sets how many hours an item must lie on the floor before it is removed (0 turns the cleanup off), and WorldItemRemovalList names which item types the rule applies to. With ItemRemovalListBlacklistToggle=true the list becomes the exceptions instead, so everything except the listed items is cleaned up. That is aggressive and can remove things players placed deliberately, so announce it before switching it on. Check the defaults in your own file: they have changed between builds.

Vehicles

Every vehicle on the map is a persistent object with parts, condition and contents. CarSpawnRate in the sandbox settings sets how many spawn; a server that sets it high for fun ends up with car parks in every town, all loaded whenever someone is nearby. Players also collect them. A base with twenty cars is twenty sets of trunk contents.

Mods and map mods#

Project Zomboid mods come from the Steam Workshop, listed by workshop ID and mod ID in the server ini. Most cost little memory: an item pack or a quality-of-life change is a handful of Lua files and definitions.

Map mods are different. They add new cells to the world - new towns, new roads, sometimes whole new regions - and those cells hold buildings, containers and loot like the base map does. Two effects follow. The world is larger, so players spread further and load more areas at once. And some map mods are dense, with more containers and more items per building than vanilla towns. The third row of the sizing table is there mainly for map mods.

Practical advice for a modded server:

1. Add mods in batches and watch memory after each. A collection of a hundred items is impossible to debug if the server suddenly needs 2 GB more.
2. Start the server once with nobody online after any mod change and check its idle memory. That is the new floor.
3. Keep the mod list identical between server and clients. Mismatches stop players joining; they do not cost memory, but they cost hours.

Project Zomboid mods and the workshop covers the ini lines and load order.

Proving memory is the problem#

Zomboid's lag has two common causes and they need different fixes.

1. Watch the memory graph during the busiest hour. A JVM sawtooth that climbs, drops after collection and climbs again is normal. A line pinned near the limit with small drops means the heap is too full, and the collector is working hard to free little.
2. Compare with the heap. If the process is near the container limit but the heap is not full, -Xmx is too high for the plan and the off-heap part is what is pushing it over. Lower -Xmx.
3. Check CPU separately. Zombie hordes, many vehicles and players spread across the map cost main-thread time too. Rubber-banding with memory comfortably below the limit is CPU. CPU or RAM: which one is holding your server back is the method, and Project Zomboid performance and lag covers the Zomboid-specific causes.
4. Look for a pattern in restarts. A server that restarts at the same busy hour every evening with nothing in its log is running out of memory. A server that restarts at random with Java errors in the log is a mod or a corrupt save.

On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than being left to swap. That makes an undersized heap obvious - an abrupt restart, not a slow decline - and the console's memory graph shows exactly how close each evening came.

A worked example: twelve players outgrowing 4 GB#

A group of twelve starts a vanilla server on a 4 GB plan with -Xmx3g. For the first fortnight it is fine: most of them live in one Muldraugh compound and go on supply runs together. In week three, three players move to Riverside, two claim a farm out by Rosewood, and the evening sessions start ending in abrupt restarts with nothing in the log.

Working through it in order:

1. The restarts are memory. Nothing in the log, at the busiest hour, and the panel graph shows the process pressing against the 4 GB line just before each one. That is the container limit, not a Java error.
2. The heap is not the whole story. With -Xmx3g the heap can only use 3 GB, so the extra pressure is off-heap memory plus a heap that is full. Raising -Xmx to 3500m on the same plan would make it worse, because it takes room from the part that is already pushing the process over.
3. The cause is spread. Three separate areas are now loaded every evening instead of one, each with its own zombies, containers and vehicles, and the population is approaching its day-28 peak.
4. The options. Move to a 6 GB plan with -Xmx4500m, which fits the spread comfortably. Or keep 4 GB and reduce the load: lower PopulationPeakMultiplier, turn on item cleanup, and agree as a group to keep bases within one or two towns. Many groups do a little of both.
5. Check after a week. The useful number is the peak during the busiest evening session, after the population peak has passed. If it sits below about 85% of the new limit, the plan is right.

The pattern is common enough to plan for. A Zomboid server that will host more than eight people should be sized for the week the group spreads out, not the week it arrives.

Disk and the save folder#

Memory is what fails; disk is what grows. The save for a multiplayer world lives in Zomboid/Saves/Multiplayer/<servername>/, and it holds one map_X_Y.bin file for every map chunk anyone has visited, plus player and vehicle data. A server that has run for a year with a well-travelled map is measured in gigabytes and hundreds of thousands of small files. Backups of it take longer as it grows, and restoring one is slower than people expect. Project Zomboid map and world reset covers resetting parts of the map without wiping players, which is also the honest way to shrink an old save.

Project Zomboid plans on RE:NODE start at 3 GB and go up to 10 GB, from $9 a month, with three port allocations. The install needs a Steam login, entered on the Setup tab, and moving up a tier raises the limit on the server you already have without rebuilding it.

FAQ#

Is 4 GB enough for a Project Zomboid server?

For up to about eight players who mostly play in the same area, on vanilla or lightly modded settings, yes, with -Xmx at about 3g. Twelve players spread across several towns, or any map mods, want 6 GB or more.

What should I set -Xmx to?

Seventy to eighty per cent of the plan's memory. That leaves room for the JVM's off-heap memory, which the container also counts. On a 4 GB plan, -Xmx3g; on 8 GB, -Xmx6g. Never set it to the whole plan.

Why does my Zomboid server use more RAM in week four?

Most likely the default population peak: with PopulationPeakMultiplier at 1.5 and PopulationPeakDay at 28, the zombie count rises over the first month. Players spreading out and accumulating items and vehicles add to it. Size for the peak, not the first week.

Do map mods use a lot of RAM?

More than most mods. They add cells to the world, so players spread further and the server loads more areas at once, and dense map mods carry more containers and items per building. A server with several map mods belongs in the 8 GB and up range.

Does restarting the server help?

It returns the JVM to a clean heap and is worth doing on a schedule, typically once a day. It does not remove items, vehicles or zombies, because they are saved in the world. If memory is pinned at the limit within an hour of a restart, the server needs a larger plan or a lighter world.