How Much RAM Does a Project Zomboid Server Need?
For Build 42 we recommend 8 GB as the floor, 10-12 GB for a normal 5-10 player server and 12-16 GB or more for bigger or modded worlds. Here is why player spread and mods matter more than headcount, how to set the Java heap so the RAM actually gets used, and how to tell when you have run out.
A group playing together is far easier on the server than the same group split across several towns, because every separate area stays loaded and simulated at once.
-Xmx caps the Java heap. If it is set too low, garbage collection runs constantly; if it is set too high for the plan, the process can be killed outright.
For Build 42, an 8 GB plan is the practical minimum worth buying, even for a small group. Old Build 41 expectations are too optimistic.
Main-thread CPU speed, sane player limits, and a tidy mod list matter just as much once the server is busy.
What actually uses memory on a Project Zomboid server
Project Zomboid’s server is a Java process, so the RAM you care about most is the Java heap. That heap is where the server keeps live world state: loaded map areas around players, zombies that need updating, containers and loose items, vehicle and tile state, modded objects, and the Lua side of many mods.
The biggest point most guides skip is that player spread matters more than simple headcount. If everyone is together in one neighbourhood, the server is loading and simulating one main bubble of the world. If the same group is split between several towns, the server has to keep several bubbles alive at once. That costs more heap because more chunks, objects, zombies and pathing state are active at the same time.
Zombies add memory load in two ways. First, there is the basic state for each loaded zombie. Second, there is the simulation around them: movement, pathing, target checks and the surrounding chunk state needed to keep that simulation coherent. As population ramps up over world age, that active state grows in the places players visit most.
Items and world objects are the quieter memory users. A fresh server is comparatively light. A server that has been running for weeks has more dropped items, more changed containers, more player-built structures and more altered tiles saved into the world. Not all of that sits in memory at once, but a mature world usually needs more heap because more of what gets loaded is no longer clean default map data.
Mods raise memory use in several directions at once:
- Lua code stays live and adds garbage collection pressure.
- Map mods increase the amount of world data the server may need to load.
- Item and tile mods increase world object counts and save complexity.
- Poorly behaved mods can create extra churn, which means more GC work on the CPU as well as more heap use.
That is why “How much RAM do I need for X players?” is only a rough starting question. The better question is: How many places will be active at once, how modded is the server, and how long is this world expected to run?
Plan RAM vs Java heap: why -Xmx must sit below the plan size
The server does not automatically use all plan RAM just because you bought it. What really limits game memory is the Java heap, set with -Xms and -Xmx. -Xms is the starting heap size; -Xmx is the maximum heap size. For sizing, -Xmx is the number that matters most.
Java also uses memory outside the heap: native libraries, thread stacks, garbage collector structures, buffers and general runtime overhead. That is why setting -Xmx equal to the full plan size is risky. The practical rule of thumb used by server operators is to keep heap at about 70-80% of the plan or machine RAM. The trade-off is simple: a larger heap reduces GC pressure, but less headroom increases the chance of the process being killed by the system before it can save cleanly.
Build 42 server launch arguments use ZGC, which is the garbage collector. ZGC helps with pause behaviour, but it cannot fix a heap that is simply too small. If the world needs more live memory than the heap allows, the collector just has to work harder and more often, costing CPU time and causing whole-server stutter.
How to set heap on Windows, Linux and a host panel
On Windows, edit StartServer64.bat. On Linux, edit the vmArgs in ProjectZomboid64.json. If you use a rented panel, the field may be called memory, Java arguments, startup command, or the equivalent of the in-game Host menu’s Server Memory setting. The important part is that the panel must end up writing sensible -Xms/-Xmx values rather than leaving the defaults untouched.
Linux, in ProjectZomboid64.json (trimmed, 6 GB example):
"vmArgs": [
"-Djava.awt.headless=true",
"-Xmx6g",
"-XX:+UseZGC",
...
] Windows, the java line inside StartServer64.bat (6 GB example):
".\jre64\bin\java.exe" -Djava.awt.headless=true -Dzomboid.steam=1 -Dzomboid.znetlog=1 -XX:+UseZGC -XX:-CreateCoredumpOnCrash -XX:-OmitStackTraceInFastThrow -Xms6g -Xmx6g -Djava.library.path=natives/;natives/win64/;. -cp %PZ_CLASSPATH% zombie.network.GameServer -statistic 0
The shipped Windows batch file comes set to 16 GB, so it must be edited to fit the actual machine or the server fails to start with memory errors. After changing heap, restart the server and watch behaviour over a normal session: if the server lasts longer but still shows group-wide pauses as the world fills up, heap was part of the problem but not the whole story.
If you are self-hosting and need the full install path and launch basics rather than just the memory piece, use our dedicated server setup guide.
RAM sizing by players, mods and map spread
These are the RAM tiers we recommend buying for a Build 42 server, the same figures we use in our host comparison. They line up with what hosts themselves advise: LOW.MS says 8 GB is comfortable for a small Build 42 group and 12-16 GB suits 10-20 players with light mods, while GTX Gaming suggests 6-8 GB for a small group and 12-16 GB for larger modded communities.
| Server shape | RAM to buy | Move up a tier when |
|---|---|---|
| 2-4 players, vanilla or a few light mods | 8 GB | Players split up across towns, you add map mods, or the world will run for months. |
| 5-10 players, a normal community server | 10-12 GB | The mod list grows past quality-of-life tweaks, or several bases are active at once. |
| Larger groups, or a heavily modded server | 12-16 GB or more | You stack map packs and scripted systems, or regularly see 10-20 players online. |
Hosts don’t all sell memory the same way, which matters when you compare plans. Here is what the plan we compare for each host gives you, in our ranking order:
| Host (our rank) | How memory is sold | Plan we compare |
|---|---|---|
| 1. Indifferent Broccoli | Uncapped RAM, priced by player slots | 4-player plan |
| 2. LOW.MS | Fixed RAM | 10 GB |
| 3. Host Havoc | Managed game package | Standard Project Zomboid package |
| 4. Kinetic Hosting | Fixed RAM performance tiers | 12 GB (8 GB tier also available) |
| 5. DatHost | Fixed RAM, unlimited slots | 16 GB |
| 6. GTX Gaming | Memory set when you configure the order | Base package |
| 7. Shockbyte | RAM tiers tied to player counts | 8 GB+ (16+ players); 4 GB and 6 GB tiers below it |
| 8. Apex Hosting | Fixed RAM tiers | 8 GB |
An uncapped plan suits Project Zomboid unusually well, because memory use grows with the world even when the player count doesn’t. On a fixed plan, size for where the world will be in a month, not on day one.
The decision rule is straightforward. Start from the smallest tier that matches your group, then move up one step for each of these: players commonly spread out, you run map mods, you keep long-lived saves, or you expect population-heavy late-game areas. If two or more of those are true already, buying the next tier now is usually cleaner than trying to squeeze a borderline heap into a tight plan.
For a broader plan comparison, including upgrade flexibility and control features, see our Project Zomboid server hosting comparison. For the mod side of the equation, especially map load order and broken Workshop entries on Build 42, keep the Workshop and map mods guide handy.
Why Build 42 usually needs more RAM than Build 41
Build 42 should be sized more generously than Build 41, not because of one magic setting but because the overall server load is heavier in practice. More systems are active, many groups have moved to more ambitious mod lists, and the world tends to become denser over time as people build, loot, move and revisit more places.
There is also a world-age effect. In Build 42 sandbox defaults, population ramps from a lower start to a higher peak by day 28. That means memory and CPU pressure can rise even if your player count does not change, simply because the active areas become busier. When players are spread across several towns, the server is not dealing with one busy place but several.
If you are upgrading from an older setup, do not assume your Build 41 plan and heap values carry over cleanly. Build 41 saves are not compatible with Build 42, and server plus clients must match the same build. If the move itself is still ahead of you, use our Build 42 migration guide before you size the new server.
How to tell you are out of memory, not chasing some other bottleneck
A genuine RAM problem has a distinctive pattern: everyone feels it. When heap is too small, garbage collection interrupts the whole server, so players see the same hitching or rubber-banding at roughly the same time. One player complaining while everyone else is fine usually points somewhere else.
Tune before you upgrade.
| Symptom | Likely cause | First fix |
|---|---|---|
| Whole server stutters in bursts, and it gets worse as the session or world goes on | Heap too small, so Java is collecting garbage constantly | Raise -Xmx if the plan has safe headroom; otherwise move up a RAM tier or trim mods/map spread |
| One player lags badly while others are fine | Usually client network, client performance, or that player loading an area for the first time | Do not change heap first; check the player’s connection, build match, and local issues |
| Server process vanishes or is restarted with no clean shutdown and no recent save | -Xmx set too close to the plan limit, so the system kills the process | Lower heap slightly below the limit, then buy more RAM if you no longer have room for the world |
OutOfMemoryError in server-console.txt | The heap is exhausted | Increase heap if possible, reduce memory pressure, and check mods that add lots of world state |
| Desync and poor map streaming after raising player slots too high | Often CPU or streaming pressure rather than heap alone | Respect the warning around higher MaxPlayers values and review broader performance settings |
The cleanest confirmation is in the server log. Check server-console.txt in the Zomboid folder for heap errors like this:
java.lang.OutOfMemoryError: Java heap space
If you see that line, the diagnosis is simple: the Java heap was too small for the live server state. If you do not see it and the process simply died, that is more consistent with the server being killed because total memory use hit the plan or machine limit. That is why leaving headroom below the plan size matters.
Upgrade the RAM, or tune something else?
RAM is only one part of server performance. Project Zomboid still cares a lot about single-thread CPU speed because key simulation work and world updates do not spread perfectly across many cores. If the heap is large enough but the main simulation thread is busy, you can still get lag that looks similar from the player side.
Player cap matters too. The default MaxPlayers=32 is there for a reason, and the developers warn that going above 32 may cause poor map streaming and desync. That is not just a memory question; it is about the amount of world state that has to be updated and delivered in time.
| Situation | Tune first | Upgrade first |
|---|---|---|
| Group-wide stutter grows worse over time and the world is heavily modded or long-running | No, unless heap is obviously mis-set | Yes |
| Only one or two players are affected | Yes | No |
| Players are often in several towns at once | Partly, by reducing spread-sensitive settings | Usually yes |
| You are already near the safe 70-80% heap range for the plan | Only for minor relief | Yes |
You raised MaxPlayers beyond the default and now see desync | Yes | Not before you lower pressure elsewhere |
Keep tuning brief and targeted. If the heap is sane, the next levers are usually zombie population-related pressure, over-ambitious player caps, and a mod list that is larger than it needs to be. For the actual settings side, use our Project Zomboid server lag guide rather than trying to solve every problem with more RAM.
If your current server is already sitting near the safe heap limit, buying the next RAM tier is usually cleaner than nursing a borderline setup through a long Build 42 world.
Compare the best Project Zomboid server hostsPre-purchase checklist before you rent or upgrade
Before buying a bigger plan, check the practical admin bits. A server can have enough RAM on paper and still be awkward to run if the panel hides heap settings, upgrades force a migration, or backups are an afterthought.
| Check | Why it matters | What good looks like |
|---|---|---|
Can you set -Xmx yourself? | You need control over the actual Java heap, not just the plan size. | A clear startup or memory field, or direct access to the server files that set heap. |
| Can you upgrade RAM without migrating the server? | Mid-season moves are when mistakes happen and downtime appears. | A simple in-place plan change, or at least a documented path with no world copy guessing. |
Do you have easy access to server-console.txt? | You need log evidence for heap errors, bad mods and failed starts. | Direct file access or a panel console that exposes the same errors clearly. |
| What is the backup story? | Out-of-memory crashes and bad mod changes are much less painful when rollback is simple. | Built-in backups are enabled, and you understand where they live and how to restore them. |
| Can you restart cleanly after config changes? | Heap changes and many sandbox changes need proper restarts to take effect. | Simple stop/start controls and no confusion about where the active config lives. |
Project Zomboid does have built-in backups, but they are written to the same disk area as the world itself, so treat them as convenience, not as your only safety net. Before changing mods, maps or branches on an existing world, make a proper copy first. If you need the recovery side in detail, use our backup and restore guide.
Project Zomboid server FAQ
Is 4 GB enough for a Project Zomboid server?
Not for Build 42. Host guidance for even a small group starts at 6-8 GB, and 8 GB is the floor we recommend buying. A tiny private server may start on less, but it leaves very little heap once the world grows and the population ramps up.
How much RAM for 10 players?
For a normal community of 5-10 players we recommend 10-12 GB. If you regularly have 10-20 players online with light mods, host guidance moves to 12-16 GB. Lean to the top of the range if your players spread out across towns or you run map mods.
Do mods need more RAM?
Usually yes. Mods add Lua memory use, more objects and items, extra map areas, and sometimes more garbage collection churn. Map mods and long-running worlds with modded items tend to push you up a tier sooner than simple cosmetic or lightweight quality-of-life mods.
Should I set -Xmx to the full plan size?
No. Java needs memory outside the heap, so setting -Xmx equal to the full plan risks the server being killed by the system with no clean save. A sensible rule of thumb is to keep heap around 70-80% of the total plan RAM.
Does Build 42 need more RAM than Build 41?
In practice, yes. Build 42 servers should be sized more generously because world load, active systems, mod expectations and long-world pressure are heavier, especially once population ramps up and players spread out. If you are moving an older group forward, do not carry over a Build 41 memory plan without rechecking it.
More Project Zomboid server guides
The rest of our Project Zomboid server guides, plus the host comparison.
Written for Build 42 stable (42.21). RAM tiers are our buying recommendations, not official minimum specifications. On a rented panel, the memory field sets the same -Xms and -Xmx values shown above.
