RE:NODE

Sizing11 min read

7 Days to Die server RAM: real figures

7 Days to Die server memory by world size and player count, the serverconfig.xml keys that move it, blood moon peaks, the log line that shows it and when to restart.

1 reader

A 7 Days to Die dedicated server needs 8 GB of memory for Navezgane or a 6k random world with up to four players, 10 to 12 GB for an 8k world with six to eight players, and 12 to 14 GB for a 10k world with eight or more players spread across the map. Overhaul mods add another 2 to 4 GB on top. Those are peak figures, and the peak has a date: horde night, when every player is fighting a wave of zombies at once, after a week of memory growth since the last restart. The two settings that move memory most are the world size you generate and the view distance you allow, and both are easier to get right before the world exists than after.

What a 7 Days to Die server holds in memory#

7 Days to Die is a Unity server simulating a voxel world that players dig through, build on and blow up. Memory is made of four parts.

  • Loaded chunks. The world is stored in chunks, and the server keeps the chunks around each player loaded and active. More players spread further apart means more chunks; a group in one base loads a fraction of what the same group exploring in four directions does.
  • Entities. Zombies, animals, players, vehicles, dropped backpacks and loot bags. Each zombie is an AI with pathing, and pathing through a destructible voxel world is expensive in memory and CPU.
  • The world's static data. The generated terrain, the POI layout, the road network, the prefab data for every building that can appear. A larger generated world has more of all of it.
  • Dynamic mesh. The system that lets players see distant POIs and player builds with their damage. It caches meshes for the areas it tracks, controlled by DynamicMeshEnabled and its related keys.

The Unity runtime and the managed heap sit underneath, and like any managed runtime it needs free space to collect in. A server whose live data fills the container leaves the collector no room, and that is when the hitches start before anything runs out.

RAM by world size and players#

World and groupRAMvCPUNotes
Navezgane or 6k world, up to 4 players8 GB2The floor for a comfortable server
8k random world, 6-8 players10-12 GB2-3The common community size
10k world, 8+ players, spread out12-14 GB3Spread matters more than count
Overhaul mods (Darkness Falls and similar)add 2-4 GBadd 0.5-1More zombies, more items, more blocks
World generation on first startpeak above all of these-A one-off spike

7 Days to Die is one of the few games where 8 GB is a floor rather than a comfortable middle. Below it the server will start and run a quiet afternoon, then fall over on its first horde night. The 7 Days to Die server settings guide uses the same figures and goes through the whole configuration.

The player column is honest about one thing that surprises people: the default ServerMaxPlayerCount is 8, and the game is designed around groups that size. Larger servers exist and run, but each extra player who goes off on their own loads another region of chunks and triggers another set of zombie spawns, so memory and CPU rise faster than linearly once a server is past about ten.

The settings that move memory#

All of these are properties in serverconfig.xml. Defaults have shifted between releases, so read the values in your own file rather than trusting any table, including this one.

serverconfig.xml
<property name="GameWorld"                       value="RWG"/><property name="WorldGenSize"                    value="8192"/><property name="WorldGenSeed"                    value="tuesday-group"/><property name="ServerMaxPlayerCount"            value="8"/><property name="ServerMaxAllowedViewDistance"    value="10"/><property name="MaxSpawnedZombies"               value="64"/><property name="MaxSpawnedAnimals"               value="50"/><property name="BloodMoonEnemyCount"             value="8"/><property name="DynamicMeshEnabled"              value="true"/><property name="DynamicMeshLandClaimOnly"        value="true"/><property name="DynamicMeshMaxItemCache"         value="3"/>
PropertyTypical defaultEffect on memory
WorldGenSize6144Size of a random world; bigger means more static data and more to explore
ServerMaxAllowedViewDistance12Caps each client's view distance in chunks; lower means fewer loaded chunks
MaxSpawnedZombies64Zombies alive across the whole map at once
MaxSpawnedAnimals50Animals alive at once
BloodMoonEnemyCount8Horde zombies per player at a time on blood moon
DynamicMeshEnabledtrueDistant POI and build meshes; costs memory to cache
DynamicMeshLandClaimOnlytrueLimits dynamic mesh to land-claimed areas
DynamicMeshMaxItemCache3How many mesh items are held in memory

The two worth acting on first:

`ServerMaxAllowedViewDistance`. The range is 6 to 12, and it caps what any client may request. Dropping from 12 to 10 or 8 reduces the chunks each player keeps loaded on the server, and most players barely notice in a world full of fog, trees and buildings. It is the cheapest memory saving on the list.

`WorldGenSize`. A 10k world is not just larger; it has more cities, more POIs and more road, and its first generation takes long enough that people assume the server has hung. If your group is four people, a 6k or 8k world gives them more than enough to explore and costs noticeably less. Size the world to the group, not to the biggest number in the dropdown. 7 Days to Die world generation covers RWG sizes, seeds and generation time in detail.

Horde night is the load test#

Every seventh day by default, the blood moon sends waves of zombies at every player. BloodMoonEnemyCount is how many are alive per player at a time, so eight players at the default mean 64 horde zombies pathing towards eight positions, often through player-built defences that are being destroyed and recalculated as they go. On top of that sit the normal spawns, the loaded chunks around each base and the block damage being written.

That evening is the peak for memory and for CPU, and it comes at the end of a week of steady growth since the last restart. Three habits make it survivable:

  1. Restart before horde night, not after. A restart in the afternoon of day seven returns the server to its floor right before the heaviest hour. Restart schedules that help covers picking the time and warning players.
  2. Fight in fewer places. Four separate horde bases are four separate pathing problems and four sets of loaded chunks. Two shared bases are half of that.
  3. Do not raise `BloodMoonEnemyCount` for a big group. It is per player. A twelve-player server at 8 is already 96 zombies at a time; the difficulty comes from the count per base, not per player.

Blood moon and performance covers the horde settings and their costs in more depth.

The log line that tells you the truth#

The 7 Days to Die server writes a status line to its log roughly once a minute. It looks like this, with the exact fields varying a little between versions:

code
Time: 412.03m FPS: 38.21 Heap: 3215.4MB Max: 4120.7MB Chunks: 612 CGO: 74 Ply: 6 Zom: 41 Ent: 63 (112) Items: 0 CO: 6 RSS: 9874.2MB

The fields worth reading:

  • `FPS` is the server's simulation rate. It is CPU, not memory. Sustained values below about 20 are where players notice zombies teleporting.
  • `Heap` and `Max` are the managed heap in use and the largest it has been. A heap that keeps setting new maximums across days is growth or a leak.
  • `RSS` is the whole process's resident memory - the number the container limit actually counts. Compare it with your plan's limit. If RSS at the end of horde night is within about 10% of the limit, you are one bad evening from being stopped.
  • `Chunks` and `Zom` and `Ent` show what drives the numbers: chunks loaded, zombies alive, entities in total.

Grep the log for these lines and you have a memory history without any extra tools. The admin console's mem command prints a similar summary on demand and triggers a garbage collection, which is useful for checking whether a high reading is live data or just garbage waiting to be collected. 7 Days to Die admin commands lists the rest of the console.

World generation and the save folder#

A random world is generated on the first start with a given name, seed and size. Generation builds the terrain, places towns and POIs, lays roads and writes the result to the generated worlds folder. It is a heavy, one-off job: memory during generation can exceed what the finished world needs to run, and a 10k world can take a long time. On a plan that is fine for running the world, generation can still fail.

Two ways around it:

  1. Generate on a quiet server with nobody connected and nothing else running, then take a backup the moment it finishes.
  2. Generate in the game client on your own PC with the same name, seed and size, then upload the generated world folder to the server. The server finds it and skips generation.

After that, the save grows as players play. Each region of the world is a .7rg file under the save's Region folder, and regions that have been dug, built on or damaged carry that data. A well-travelled 10k world's region files can reach several gigabytes, which is disk rather than memory, but loading and saving them is part of what the server does each time a player moves into a new area.

Mods: modlets and overhauls#

7 Days to Die mods range from single-file modlets that change one recipe to complete overhauls that replace most of the game's content.

  • Modlets that adjust XML - recipes, loot, stack sizes - cost almost nothing in memory.
  • Content modlets that add blocks, items or zombie types add their assets and their spawns.
  • Overhauls such as Darkness Falls add new zombie classes, many new blocks and items, new POIs and changed spawning. They are effectively a different game with different requirements: add 2 to 4 GB and half a core, and expect a slower start.

Overhauls follow the base game's major versions with a delay, so check that the version you install matches the server's game version exactly; a mismatch usually stops the server at load rather than using extra memory. Overhaul mods on a server covers installing them and keeping clients in step.

A worked example: six players on an 8k world#

A group of six wants an 8k random world, default zombie counts, one modlet pack of quality-of-life changes and blood moon every seven days. The table says 10 to 12 GB. Here is how to confirm it on real data rather than trusting the table.

  1. Generate first, size second. Generate the world on a quiet server or in the client and upload it, so the generation spike does not decide the plan.
  2. Note the floor. Start the server with nobody online and read RSS from the status line after five minutes. On an 8k world that is the engine, the world's static data and the modlets.
  3. Read a normal evening. With all six online and spread across the map, watch RSS, Chunks and Zom during the busiest hour. Spread shows up as a high Chunks figure.
  4. Read horde night. The same fields at the height of the blood moon on day seven, without a restart beforehand, give the true peak of the week.
  5. Decide. If that peak is under about 85% of the plan, it fits. If it is close, the cheapest fixes are a restart before horde night and ServerMaxAllowedViewDistance lowered by two. If neither is enough, move up a tier.

Most groups of this shape land comfortably on 10 GB with a pre-horde restart, and on 12 GB without one. The difference between those two plans is often one scheduled task.

What happens at the limit#

When a 7 Days to Die server runs out of memory inside a container, it does not log a friendly error. The process is stopped, the log ends mid-line, and the last region files written are what you have. Region files caught mid-write are one of the ways a 7 Days save is damaged, which is why the habit of keeping backups matters more on this game than most.

On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than being left to swap; a swapping 7 Days server is unplayable anyway. Backup slots come with every plan and the Schedules tab can run a backup before the pre-horde-night restart. 7 Days to Die plans start at 8 GB from $20 a month and go up to 14 GB, and the Steam login the install needs goes on the Setup tab. Moving up a tier raises the limit on the server you already have, so the world stays where it is.

FAQ#

Is 8 GB enough for a 7 Days to Die server?

For Navezgane or a 6k random world with up to four players, yes. For an 8k world with six to eight players it will run but will be tight on horde night at the end of a week without a restart. Below 8 GB the server is not worth running.

Why does my 7 Days server lag on horde night?

Because horde night is the peak for both memory and CPU: dozens of zombies pathing through destructible blocks at several bases at once. Check the FPS field in the log. If it collapses while RSS is well below your limit, it is CPU and fewer horde bases will help more than memory. If RSS is near the limit, restart before the next one.

Does a bigger world need more RAM?

Yes, more than in most games. A larger random world carries more static data and more POIs, and players spread further across it, loading more chunks. A 10k world for four players is paying for map they will never visit.

How much RAM does Darkness Falls need?

Plan on 2 to 4 GB more than the same world would need in vanilla, and an extra half core. Overhauls add zombie types, blocks and items and change spawns, so they raise both the floor and the horde night peak.

Does restarting help 7 Days to Die memory?

Yes. Memory grows across days of uptime, and a restart returns the server to its floor. Time it before horde night, not after, so the heaviest hour of the week starts from the lowest point.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000