Sizing 7 Days to Die and Other RAM Hogs

Day 30, Blood Moon, 2 AM, Dead Server

The horde spawns. Your friends are on the roof with the good guns. Then the game freezes, Discord fills with “wtf,” and docker ps shows nothing running. The kernel’s OOM killer took your server, and it did it at the worst possible minute.

You can stop this. Game servers that eat RAM are predictable once you know what drives the number: the world, the mods, and how long the process has been up. Player count matters less than most hosting ads suggest. The fix is three habits: size from measured peaks, compare against the other hogs (Palworld, Valheim, modded Minecraft), and cap each server so a spike kills one container instead of your whole box.

What the Vendors Actually Say

Start with what is documented. Plenty of numbers float around, and most come from hosting companies selling you a plan.

Treat the third column as the real content. An “official” number is a floor the developer will defend. A community number is someone’s server on someone’s Tuesday.

The 7 Days to Die figure comes from the wiki’s dedicated-server page. Its separate hardware-guidance page is more conservative: 12 to 16 GB for 4 to 8 players, plus 4 to 8 GB for large modpacks. Plan on the higher number if your group is full.

The wiki also says the game is heavily single-thread-bound and asks for fast cores. That is a CPU problem, but it matters here: a server stalled on one thread will not look memory-bound in top, so measure before you buy RAM.

Why 7 Days to Die Is Hungry

The dedicated server tool is Steam app 294420. It is a separate free download from the game itself (app 251570). As of mid-October 2026, V3.3.0 is the stable build. It opened on the experimental branch on 24 September and went stable on 5 October 2026, replacing V3.2.0 (stable since 26 August). Those dates come from the community wiki and hosting sources, not an official changelog, so check the Steam branch list before you pin a version.

Four things push RAM up.

1. World size and generation. GameWorld picks the map: Navezgane, RWG (random generation), or a custom name. For RWG, WorldGenSize sets the map size in metres, with a default of 6144 according to one community reference. Bigger maps mean more terrain, more points of interest, and more chunk data in play.
2. Entities. MaxSpawnedZombies is the server-wide zombie cap (that reference lists a default of 64). MaxSpawnedAnimals is the animal cap, listed at 50. Blood moon is when everyone is near the cap at once.
3. Mods. The wiki’s 10 to 16 GB range exists because overhaul mods add content that gets loaded and kept. Large modded worlds are its stated reason to allocate more.
4. Players spread out. ServerMaxPlayerCount defaults to 8. RAM follows how much of the map is loaded around players. Four players on four mountains cost more than eight in one base. The MaxUncoveredMapChunksPerPlayer property also limits map data held per player.

One version gotcha. V3.0 removed 29 legacy properties (difficulty, XP, loot, blood moon frequency, and others) and replaced them with a single generated SandboxCode value. If an old guide tells you to tune one of those properties and nothing changes, that is probably why. There is no official list of the properties that remain, so check the ones above against the serverconfig.xml your server ships after every upgrade.

<property name="GameWorld" value="RWG"/>
<property name="WorldGenSeed" value="mysecretseed"/>
<property name="WorldGenSize" value="6144"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="MaxSpawnedZombies" value="64"/>
<property name="MaxSpawnedAnimals" value="50"/>

I did not find a trustworthy per-day or per-player RAM curve for 7 Days to Die, so I will not invent one. Measure your own (next section).

The Rest of the Hog Pen

Palworld. The official requirements page lists 16 GB and says 8 GB boots but raises the chance of out-of-memory crashes. Hosting guides widely report RAM climbing with uptime until a restart. Those guides disagree on intervals (from every 2 to 4 hours up to daily), and I found no developer statement on it, so call it community-reported. The usual workaround is a scheduled restart, covered below.

Valheim. The developer publishes no RAM figure. One vendor measured about 1.3 GB on a fresh idle 1.0 world and argued memory tracks the world, not the player count. One measurement from a server vendor is thin evidence, but it fits my expectation that old worlds with a lot of built structure get heavier.

Minecraft Java, modded. Here you decide the number yourself. The JVM heap is capped with -Xmx, and the popular itzg/minecraft-server image sets it through MEMORY (default 1G). Its docs say that setting covers only the heap and that the container limit should leave room for non-heap memory, suggesting an extra 25%. Skip that and the JVM keeps its heap fine while the kernel kills the container anyway.

services:
  mc:
    image: itzg/minecraft-server
    environment:
      EULA: "TRUE"
      MEMORY: "6G"        # heap, becomes -Xms and -Xmx
    ports:
      - "25565:25565"
    mem_limit: 8g         # 6G heap + headroom for non-heap memory
    memswap_limit: 8g     # same as mem_limit, so no swap
    volumes:
      - /opt/gameservers/mc:/data
    restart: unless-stopped

The 6G and 8G are an example of the ratio, not a recommendation for your pack. Read the modpack’s own page for its heap advice.

Measure Before You Buy

Guessing from forums is how you end up with 32 GB for a four-person server. Measure instead. Four tools, from broadest to narrowest.

# 1. Per-container view, one shot
docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}'

# 2. Host view: who owns the RAM
ps -eo pid,rss,comm --sort=-rss | head -5

# 3. Proportional share (splits shared pages fairly)
sudo smem -t -k -P 7DaysToDieServer

# 4. One process, straight from the kernel
grep -E 'VmRSS|VmHWM' /proc/$(pgrep -f 7DaysToDieServer | head -1)/status

Notes on each:

• docker stats reports container memory as the runtime sees it. Treat it as a good trend line, not an exact number.
• ps rss counts shared pages in every process that touches them. For one big game process that is fine.
• smem reports PSS, which divides shared pages between users. It is the fair number when several containers run on one host. It may not be in your base install.
• VmHWM in /proc/<pid>/status is the peak resident size since the process started. That one number answers “how big did it get during the horde.”

To see growth over uptime, which is how you catch the Palworld pattern, log it:

#!/usr/bin/env bash
# Append a timestamped memory sample every minute. Run from a systemd timer.
docker stats --no-stream --format '{{.Name}},{{.MemUsage}}' \
  | sed "s/^/$(date -Is),/" >> /opt/gameservers/mem.csv

Run it for a week, with a blood moon in it, and look at the peak. Size the box to the peak plus 20 to 30% headroom. That headroom figure is my rule of thumb, not a measured law. A line that climbs steadily from startup and never falls after players leave is a leak. A line that jumps when players explore and falls back is just the world loading and unloading.

Cap It So the Container Dies, Not the Host

Without a limit, one runaway game server can push the whole box into the OOM killer, and the kernel chooses the victim. It might pick your database. With a limit, the kernel kills processes inside that container’s cgroup and the rest of the host lives.

Docker’s docs put it plainly: by default, when a container hits an out-of-memory error, the kernel kills processes in the container. Here is a 7 Days to Die compose file with a cap, using the vinanrra/7dtd-server image (LinuxGSM-based). Check its README for the current variable list before you copy it.

services:
  sdtd:
    image: vinanrra/7dtd-server
    container_name: sdtd
    environment:
      START_MODE: "1"       # 1 = start
      VERSION: "stable"     # game branch
      PUID: "1000"
      PGID: "1000"
    ports:
      - "26900:26900/tcp"
      - "26900:26900/udp"
      - "26901:26901/udp"
      - "26902:26902/udp"
    volumes:
      - /opt/gameservers/7dtd/data:/home/sdtdserver/.local/share/7DaysToDie/
      - /opt/gameservers/7dtd/lgsm:/home/sdtdserver/lgsm/config-lgsm/sdtdserver/
      - /opt/gameservers/7dtd/serverfiles:/home/sdtdserver/serverfiles/
    ulimits:
      nofile:
        soft: 10240
        hard: 10240
    mem_limit: 12g
    memswap_limit: 12g
    restart: unless-stopped

The image’s docs list those ports and mounts and warn against restart: unless-stopped with START_MODE 0, 2, or 4. Mode 1 is fine. deploy.resources.limits.memory is the equivalent under the deploy key, and Compose requires mem_limit to agree with it if you set both. Pick one.

Two details on memswap_limit. Compose says a positive value needs memory set too, and Docker says that setting it equal to the memory limit gives the container no swap. I disable swap here on purpose, and the next section explains why.

When the limit is hit, you see exit code 137 and an OOM flag:

docker inspect sdtd --format 'oom={{.State.OOMKilled}} exit={{.State.ExitCode}}'
# oom=true exit=137

Exit 137 means SIGKILL (128 + 9). It also appears for a plain docker kill, so check OOMKilled before you blame memory. With restart: unless-stopped the container comes back on its own, which is a worse failure than it sounds if the world was mid-save. Back up on a schedule. The vinanrra image has BACKUP, BACKUP_HOUR, and BACKUP_MAX options for this.

Do not reach for --oom-kill-disable here. Docker warns it is only safe with a memory limit, and even then a frozen game server is no better than a dead one.

Swap and zram: Useful, but Not for the Hot Path

Swap does not fix a server that needs more RAM. It turns a crash into a slideshow. A game server swapping its working set to a spinning disk will miss tick deadlines long before it dies, and your players will call that “lag” and leave.

I still like a small swap, and zram in particular, as a safety valve for the host. Zram compresses pages in RAM, so the penalty is CPU instead of disk latency. On systemd distros with zram-generator:

[zram0]
zram-size = ram / 4
compression-algorithm = zstd

The sizing is my preference, not a standard. The pattern I use: no swap for the game container (memswap_limit equals mem_limit, as above), and a modest zram device for everything else on the host, so a cron job or a package update does not push the box over. If you want a game container to swap, set memswap_limit higher than mem_limit and accept the stutter.

Scheduled Restarts for the Leaky Ones

For a server that grows with uptime, the honest fix is a scheduled restart, ideally at a time nobody is playing. Pick the interval from your logged curve. Do not copy a number from a hosting blog: the Palworld guides I found range from every few hours to daily, and none cite a developer source.

A systemd timer beats a cron line because it logs and can catch up after a reboot:

[Unit]
Description=Restart game server container

[Service]
Type=oneshot
ExecStart=/usr/bin/docker restart sdtd

[Unit]
Description=Nightly game server restart

[Timer]
OnCalendar=*-*-* 05:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl enable --now gs-restart.timer
systemctl list-timers gs-restart.timer

docker restart sends SIGTERM first and waits ten seconds by default before SIGKILL. A big world may need longer to save. Use docker restart -t 60 sdtd in the unit if your save takes a while.

Putting Numbers on One Box

Here is how I would split a single 32 GB home server. This is my rule of thumb from the sources above, not a benchmark, and it assumes you ran the logging script first.

Those caps add up to more than 32 GB if you run everything at once, and that is the point. Caps are ceilings. Sum your measured peaks, not your caps, and decide which servers never run at the same time. A 7 Days to Die box that also hosts Palworld is two forklifts sharing one parking spot: each fits alone.

Common Questions

How much RAM does a 7 Days to Die server need?

A small vanilla 7 Days to Die server needs about 6 GB, and overhaul mods or larger groups need 10 to 16 GB, according to the community wiki at wiki.7d2d.net. Those are planning figures, not guarantees. Log your own peak across a blood moon and add 20 to 30% headroom.

Does player count matter more than world size for server RAM?

No, for most of these games world size and mods drive RAM more than player count. One Valheim host measured about 1.3 GB idle on a fresh world and found the difference between two and ten players small. Players still matter in 7 Days to Die when they spread across the map and load more chunks.

Why does my game server container exit with code 137?

Exit code 137 means the process received SIGKILL, and for a game server it usually means the kernel killed it for exceeding the container memory limit. Confirm with docker inspect --format '{{.State.OOMKilled}}' <name>. A manual docker kill also produces 137, so check that flag first.

Should I give a game server swap?

Give the host a small zram device, but do not let the game container swap. A server that swaps its working set misses tick deadlines and lags before it crashes. Setting memswap_limit equal to mem_limit in Compose gives the container no swap, so it fails fast and restarts clean.

Related Reading

• LinuxGSM: Boring Game Servers Done Right
• Docker Resource Limits: Stop Letting Containers Eat Your RAM
• The Linux OOM Killer: Why It’s Killing Your App
• zram vs Swap: What’s Actually Faster for Low-RAM Servers
• Systemd Timers vs Cron: Scheduling That Doesn’t Suck