Docs · Project Zomboid

Build 42 server requirements

Project Zomboid Build 42 asks noticeably more of a server than Build 41 did. If you’re sizing a dedicated box — or picking a hosting plan — the two numbers that matter most are RAM and, to a lesser degree, single-core CPU speed. This guide gives you a sizing rule you can actually apply, plus the reasoning behind it.

Why B42 needs more RAM than B41

Build 42 shipped a substantial engine rewrite — a new lighting and rendering system, basements and true vertical geometry, deeper crafting, and animal husbandry. All of that lives in memory. In practice, a B42 server’s Java process claims more heap just to load and hold the world than an equivalent B41 server did.

Concretely: a small B41 server was comfortable at around 4 GB. A B42 server can want 6–8 GB just at startup, before a single player connects, once the map and systems are resident. Treating your old B41 allocation as a starting point for B42 is the most common way people end up with a stuttering, out-of-memory server.

How much RAM does a B42 server need?

A workable rule of thumb: start with a ~6 GB base for the engine and world, then add roughly 0.5 GB per concurrent player. Layer mods on top of that — add about 2 GB for a moderate mod list and up to 4 GB for a heavy one. A single large content mod such as Brita’s Weapon Pack can add 1–2 GB on its own.

Applied to common group sizes, that lands roughly here:

These figures assume a light-to-moderate mod list. If you’re running a heavy modpack, size up one row — mods, as we’ll see, move the needle more than raw player count.

Mods drive RAM more than player count

It’s tempting to size purely by how many friends are joining, but the mod list is usually the bigger variable. Each mod loads its assets and scripts into the same JVM heap the base game uses. A ten-player vanilla server can be lighter than a four-player server running a 60-mod pack with custom vehicles, weapons and map tiles.

Because mods are the volatile factor, the risky moment is updating them. A mod that changes its footprint — or breaks against the current build — can destabilise a previously-healthy server. Forgehold stages mod changes on a canary container first, downloading and validating the new mod set in isolation before it ever touches your live world, so a bad update is caught off to the side rather than on your players.

JVM heap and the RAM ceiling

Project Zomboid’s dedicated server runs on the JVM, and its memory is governed by the Java max-heap flag, -Xmx. The critical constraint: your -Xmx heap must fit inside the plan’s total RAM with headroom left over for the operating system, the container runtime and file-system cache. Setting the heap equal to — or above — the box’s physical RAM is a reliable way to trigger the Linux out-of-memory killer mid-session.

On Forgehold you don’t hand-tune this: heap is set automatically for each tier, sized to leave the OS and container the headroom they need. If you self-host, budget a comfortable margin — on an 8 GB box, a heap in the 6 GB range leaves room to breathe.

CPU and single-core speed

Zomboid’s server simulation leans on a small number of threads rather than scaling smoothly across many cores, so single-core clock speed matters more than core count. A modern CPU with good per-core performance keeps the world tick responsive as your survivor count and zombie population climb. Two to four fast vCPUs cover the group sizes in the table above; the RAM ceiling is what you’ll hit first.

Branches, versions and backups

Build 42 multiplayer arrived in December 2025 on Steam’s newest (unstable) branch, with the stable flip expected soon after. Running on an actively-moving branch has a real consequence: save compatibility can break between major unstable versions. A world created on one B42 build may not load cleanly on the next.

That makes regular off-site backups non-negotiable, not a nice-to-have. If an update ever invalidates a save, a recent backup is the difference between rolling back an hour and losing the run. Forgehold takes automated off-box backups on a rolling schedule so you always have a recent restore point.