Project Zomboid Server RAM Allocation: Verify It

If an edit seems to have no effect, verify the Project Zomboid server process instead of trusting a file or dashboard value. This Project Zomboid server RAM allocation walkthrough is limited to one tested Linux Docker image, danixu86/project-zomboid-dedicated-server:42.20.4-release. Its image-specific MIN_MEMORY and MAX_MEMORY variables appeared as JVM flags in the running server after restart. They are not universal Docker settings, and this test does not prove how a native SteamCMD install, another image, a rental panel or Windows works. It also does not prescribe a memory target; choose that separately for your workload and host.

Confirm the exact image before changing its server memory#

The memory controls below belong to the Danixu Project Zomboid dedicated-server image. The tested tag was danixu86/project-zomboid-dedicated-server:42.20.4-release, with local digest sha256:a98b0f219f63ad9f08b0658cf77c2c165705ab8d74775fd3db6e50fd6f4961e1. Pinning a tag and recording its digest gives you a way to describe exactly what ran; a mutable tag can point to different image content later.

The server log in the test identified the game as 42.20.4 b0bbce05d5 and reached *** SERVER STARTED ****. Indie Stone’s September 23 announcement says 42.21 is available on Steam’s Unstable branch, while the tested image tag is explicitly the 42.20.4 release. If you run an Unstable build, match each client to that server build and treat its behavior as a separate check. A result from this tag is not proof that a different release, branch, image or panel uses the same launch controls.

This guide verifies the image’s process arguments and startup marker only. The test used an isolated container with no exposed ports or mounted world data. It did not test a player joining, public reachability, gameplay quality or whether an existing world survives replacement. If your current server is not this image, stop here and use that deployment’s own documentation for its authoritative memory setting.

Separate the JVM heap limit from Docker memory#

-Xmx is the JVM’s maximum heap setting; it does not mean the server process is using that much memory at the moment. The operating system’s resident-memory display can stay below the limit, move for other reasons or include memory that does not belong to the Java heap. A graph that has not moved is not enough to prove an edit failed.

Docker’s container memory limit is another ceiling. In the test it was 4 GB, while the original server process received -Xms1024m -Xmx2048m. That pair describes the Java launch arguments; the 4 GB cgroup cap limits the container as a whole, including memory outside the JVM heap. Keep an allocation below the actual container ceiling and leave room for the operating system and other work. Do not copy the test cap or its JVM values as a recommendation for your world.

If you still need to decide what the server should receive, first size it against the group’s workload and the host’s available resources. Changing a ceiling cannot create physical memory, and a larger cap alone does not establish that RAM caused a lag spike. Treat performance symptoms as a separate diagnosis.

Find this image’s Project Zomboid RAM controls#

The image’s README documents three runtime variables: MIN_MEMORY for the JVM’s initial heap, MAX_MEMORY for its maximum heap, and MEMORY as a fallback used for both when the pair is absent. In the image entrypoint, the first two become -Xms and -Xmx arguments. Those variable names belong to this image; don’t assume another Project Zomboid container recognizes them.

For an existing Compose deployment, the relevant part may look like this inside the existing service definition:

environment:
  MIN_MEMORY: 1024m
  MAX_MEMORY: 2048m

The values above reproduce the original pair observed in this test. They are not a sizing recommendation. Keep the rest of your current service configuration as it is, and edit the definition or environment file that actually creates the container. Changing a local .env file that the service never reads will not change the running container.

The image also logs its startup arguments, and its README warns that an admin password passed at startup can appear in logs. Avoid posting complete logs, environment output, or command lines publicly. When checking memory, filter output to only the -Xms and -Xmx values as shown below.

Recreate safely without losing the world#

Docker environment variables are stored with a container when it is created. Editing the Compose service or its environment file does not rewrite an existing container, and a plain docker restart repeats the same configuration. The tested change therefore used a fresh disposable instance and recreation; it did not validate migrating or retaining anyone’s save data.

Before applying a change to a real server, identify how your deployment stores the world and configuration, make a recoverable backup, and confirm that its documented update procedure preserves that data when it replaces a container. The image README recommends persistent storage, but this article did not test a volume layout or a restore. If docker inspect shows no mounts, or you cannot identify where the live world is saved, do not recreate the container yet. A replacement without the right data mount can start a fresh world and make the old one appear missing.

Once the data path is confirmed, update only the memory variables in the deployment’s existing definition. Recreate the service using the same image tag and its documented workflow, not a hand-built replacement command that might omit ports, network settings, admin configuration or mounts. Keep the previous values and image reference so you can restore them. For a general guide to game options in the server INI, use the Project Zomboid server INI verification guide; JVM heap variables are a different control.

Verify the Project Zomboid server RAM allocation in its process#

After the replacement container starts, check its state and then inspect only the relevant arguments from the process named by this image. Substitute your current container name for pz-server:

docker inspect pz-server --format 'state={{.State.Status}} oom={{.State.OOMKilled}}'
docker exec pz-server sh -lc '
for d in /proc/[0-9]*; do
  [ "$(cat "$d/comm" 2>/dev/null)" = "ProjectZomboid6" ] || continue
  tr "\000" "\n" <"$d/cmdline" | grep -E "^-Xm[sx]"
done'

The tested original pair returned these two lines:

-Xms1024m
-Xmx2048m

Do not treat that example as the right allocation for your server. Compare the values you deliberately configured with the running process. A generated JSON file or saved Compose setting proves only that a value exists somewhere; the process arguments show what this server launch received.

Then check that the server completed startup. This filter avoids printing the image’s full startup arguments, which may contain sensitive values:

docker logs pz-server 2>&1 | grep -E 'version=|SERVER STARTED'

For the isolated test, the matching lines reported build 42.20.4 b0bbce05d5 and *** SERVER STARTED ****. If the container is running but the process flags do not match, the deployment may still be using old environment values or a different image. If the expected process is not found, do not infer success from the config file; confirm the container name and image, then follow that image’s current troubleshooting steps.

Roll back to the previous known-good pair#

If startup fails or the new cap causes trouble, restore the last working variables in the same deployment definition and recreate through its normal data-preserving procedure. This image’s environment cannot be changed by restarting an already-created container. The rollback check is the same process inspection: the original test returned -Xms1024m and -Xmx2048m, then reached the ready marker again without a Docker OOM event.

Keep a short record of the image tag/digest, the previous pair and the new pair alongside your deployment notes. Do not change multiple resource controls at once; that makes a failed start harder to trace. If the old pair returns but the server still fails to start, the heap edit was not the only problem. Restore a known-good image and saved data using your established recovery process before experimenting further.

Diagnose a RAM display that still looks unchanged#

First separate three readings: the -Xmx process argument, the container memory ceiling, and current resident memory. They answer different questions. If the process command line has the expected -Xmx, the setting reached the launcher even if the OS graph is lower. If the command line still has the old value, fix the source that creates this image’s container and recreate it safely.

A larger heap does not prove that Project Zomboid will use it, and it does not automatically fix CPU load, network delay, a mod problem or world-growth behavior. If the JVM flag is correct but memory continues rising, collect observations over time and investigate the workload rather than repeatedly raising the cap. If the underlying problem is a game option instead of process memory, use the separate server INI guide.

If you would rather not maintain the container yourself, check the Project Zomboid hosting page for its current offer and signup status. Its plan button currently leads to a waitlist page, and that page reported a signup error during this check. The provider’s memory controls and panel behavior were not tested here, so confirm access and the exact control before relying on a hosted allocation.