7 Days to Die server laggingBlood moon, zombie count and the levers in the config and SandboxCode

Published on August 9, 2026 · last updated on November 4, 2026

Check first: server or client?

As with every game, the cross-check applies: if it stutters for everyone at the same time, it is the server. If it only stutters for one player, it is their frame rate or connection.

7 Days to Die is also demanding on the client side - view distance and texture quality bring even good computers to their knees. So before you tweak the server configuration, clarify where the bottleneck is.

The pattern reveals the cause

Before you change values, it is worth looking closely at how it stutters. Four patterns can be clearly told apart:

• Evenly sluggish, permanently. Everything runs as if in slow motion, but without jumps. That is computing load: too many enemies, too many active objects, too much at once. The values from the next sections apply here.
• Short dropouts at regular intervals. Fractions of a second of standstill, recurring regularly, getting worse over hours and gone after a restart - that points to tight memory, see how much RAM do I need?.
• Dropouts when advancing into new territory. Usually only affects the person who is on the move and disappears afterwards - that is world generation, not a permanent problem.
• Lagging behind and rubber-banding for one person. Zombies stand still briefly and then teleport - that is this person's connection, not the server.

The distinction saves a lot of wasted work: anyone who lowers the zombie count for a memory problem changes the feel of the game and solves nothing. So note the time, player count and game day when it occurs - only these three details together give a picture.

The blood moon night is the peak load

Every seventh day brings the horde night - and with it by far the highest load. Two values control it directly:

• Blood moon horde size (formerly BloodMoonEnemyCount) - zombies per player on the blood moon night. The most effective lever of all: with several players, the value multiplies. Since version 3.0, you set it in the sandbox options; it ends up as part of the SandboxCode in the serverconfig.xml.
• MaxSpawnedZombies - the upper limit of simultaneously active zombies on the entire server. This value is still a separate entry in the serverconfig.xml.

A round with six players and a large blood moon horde quickly produces more enemies than can sensibly be calculated. Lowering this value costs less game feel than expected - the night stays challenging, the server stays playable. If you have taken over a serverconfig.xml from before 3.0: a BloodMoonEnemyCount still entered there is ignored.

The routine around the horde night

Against blood moon lag, not only the configuration helps but also the routine around it. This one has proven itself:

1. Adjust values on a quiet day, not on the seventh. Every change to the serverconfig.xml needs a restart - in the middle of the night is the worst possible time.
2. Restart shortly before nightfall. The server goes into the most demanding stretch with tidied-up memory.
3. Defend together if possible. Four separate bases keep four map sections active at the same time and make enemies spawn in four places. A shared base noticeably lowers the load without changing anything in the configuration.
4. Clean up after the night. Collapsed builds leave rubble and fallen blocks that continue to be calculated. A second restart the morning after costs nothing and brings a lot.

If you lower the horde size, do it in steps and observe for a night, instead of halving the value. Two small steps show you where your server's limit is; one big step only makes the night boring. If it still becomes unplayable every horde night despite lowered values, the number of simultaneously active players and not the configuration is the bottleneck - then the way leads to more resources.

Before you change several things at once, back up the current state: a broken configuration makes the server start with default values, and that is often only noticed days later, see create backups.

Animals, clean-up and permanent load

Besides zombies, other things permanently cost computing time:

• MaxSpawnedAnimals - animals count towards the entity load just like zombies.
• Fallen blocks and rubble after big collapses - a typical cause of load spikes after the horde night.
• Large player bases with many traps, turrets and electrical installations.
• Widely scattered players - each keeps their own map section active.

Regular restarts help noticeably: they clear away leftover objects and free up memory. A daily restart during a quiet hour is a proven routine with 7 Days to Die.

World size and world generation

A large random world (RWG) costs more than the fixed Navezgane map - not permanently, but while it is being explored: when players enter unknown territory, the server has to generate new areas, and that causes noticeable dropouts.

This lag disappears as soon as the area has been explored. If you want things calmer from the start, choose a smaller world size or Navezgane - the choice is explained in Navezgane & RWG.

Mods and overhauls

Big overhauls such as Darkness Falls change spawn tables, recipes and enemy types - and with them the load behavior. After installing an overhaul, the server is no longer comparable with the vanilla state.

• If the lag starts with the installation, the connection is clear - then check the pack's spawn values.
• Overhauls often recommend their own guide values; they take precedence over the vanilla defaults.
• Switching to an overhaul requires a new world anyway - see install Darkness Falls.

If the server stays slow even with lowered values, the resources are the bottleneck. The plans are on the product page.

Frequently asked questions