7 Days to Die server settings: serverconfig.xml explained

7 Days to Die keeps a voxel world that players are actively destroying, which is a harder problem than it looks. A server wants 8 GB to start and 12 or more once eight people are spread across a 10k random world, one fast core it can keep, and three ports. The settings that matter for performance are the ones that decide how much of that world is awake at once, and horde night is where every choice you made shows up in a single evening. This guide goes through the whole file - what each setting does, what it costs, the ports, the admin and telnet interfaces, modlets, and the specific way a 7 Days save goes bad.

What the dedicated server is, and what makes it heavy#

The dedicated server is free and comes from SteamCMD as app id 294420. It runs headless, loads one world and one save, and simulates it whether or not anybody is online.

Four things drive the load, and only one of them is player count:

1. Loaded chunks. Each player keeps a set of chunks around them alive. Eight players in one town are cheap; eight players in eight corners of a 10k map each hold their own working set, and the totals add up.
2. Entities. Zombies, animals and dropped items each tick. MaxSpawnedZombies is the single most important number on the server for this reason.
3. The dynamic mesh. Modern versions recalculate structural support and collapse for player-modified buildings in the background. It is the reason a server writes to disk constantly, and it can be narrowed or turned off.
4. World size, mostly at generation time and on disk. A 10k random world takes real time and real memory to build the first time, and then a large number of region files to store.

The world is generated once, into a GeneratedWorlds folder holding a heightmap, biome and splat images and a prefabs.xml listing every point of interest placed. The save that players affect is separate. Knowing the two are different is what lets you reset a server without regenerating the map, and regenerate the map without a fresh install.

Requirements and resource usage#

• Generation is a spike. Building a 10k random world on first start uses far more memory than running it, and takes long enough that people assume the server has hung. It has not. Generate the world once, then take a backup of it.
• CPU: the world simulation is dominated by one thread. Clock speed decides how many zombies can path at once, which is the same as saying it decides horde night.
• Disk: the install is around 20 GB, and the save grows with every block a player breaks. Region files for a well-travelled 10k world can reach several gigabytes.
• Network: the heaviest moment is a new player's first join, when the server streams the explored world to them.

Installing and starting the server#

$ steamcmd +force_install_dir /home/7dtd/server +login anonymous \    +app_update 294420 validate +quit$ cd /home/7dtd/server$ ./startserver.sh -configfile=serverconfig.xml

On Windows the same job is done by startdedicated.bat, which calls 7DaysToDieServer.exe with the same argument. SteamCMD explained covers branches and update scripts if you want to pin a version rather than take every update.

On RE:NODE the 7 Days to Die install asks for a Steam login on the Setup tab. The server is created straight away and the install waits for those credentials, which are stored as you type them - so use a spare Steam account rather than your main one.

serverconfig.xml: the settings that matter#

The file is XML, one property per line, and it ships with a comment on nearly every entry. Do not delete the comments; they are the best documentation the game has.

<?xml version="1.0"?><ServerSettings>  <property name="ServerName" value="Longship Crew"/>  <property name="ServerPassword" value=""/>  <property name="ServerMaxPlayerCount" value="8"/>  <property name="ServerVisibility" value="2"/>  <property name="ServerPort" value="26900"/>  <property name="GameWorld" value="RWG"/>  <property name="WorldGenSeed" value="Longship"/>  <property name="WorldGenSize" value="8192"/>  <property name="GameName" value="LongshipSave"/>  <property name="GameDifficulty" value="2"/>  <property name="DayNightLength" value="60"/>  <property name="MaxSpawnedZombies" value="64"/>  <property name="BloodMoonEnemyCount" value="8"/>  <property name="EACEnabled" value="true"/></ServerSettings>

World and identity

GameWorld and GameName together decide which save loads. Changing either starts a new one beside the old, which is both how you reset a server deliberately and how people lose a world by accident.

Difficulty and rates

DayNightLength is the setting groups argue about most and it costs nothing either way. Sixty minutes is the default; ninety gives a working day that fits an evening session, and it also stretches the week between blood moons by half.

Zombies and blood moon

Land claims, bases and decay

Performance and housekeeping

DynamicMeshLandClaimOnly is the performance setting nobody mentions. Left on, the expensive structural work happens only around claimed bases. Turned off, it happens everywhere players have dug, which on a months-old server is most of the map.

Blood moon is the load test#

Everything is fine until night seven, when the zombie count multiplies across every player at once. If the server is going to fall over, it will do it then. Size for the horde and the rest of the week takes care of itself.

The arithmetic is the part people get wrong. BloodMoonEnemyCount is per player: four players at eight each is thirty-two zombies, eight players at eight each is sixty-four, and eight players at sixteen each would be a hundred and twenty-eight. MaxSpawnedZombies caps the total for the whole server, so at its default of 64 that last configuration quietly becomes 64 anyway - and players who have been told the horde is bigger will report that the game is broken when it is only clamped.

Two more habits help. Ask players to fight the horde from bases reasonably close together, because four separate horde bases means four separate pathfinding problems running at once. And restart the server before horde night rather than after - memory use climbs across a week, and horde night is the worst moment to discover the limit. Restart schedules that help covers picking the hour, and on RE:NODE the Schedules tab will run it for you with a warning message first.

Ports, telnet and the web dashboard#

Port 26900 needs both TCP and UDP, which is unusual enough that it is worth checking rather than assuming - a UDP-only rule leaves the server unlistable. Some documentation extends the block to 26903; opening 26900-26903 costs nothing and removes the question. Game server ports explained covers why the listing and the game use different paths in the first place.

RE:NODE's 7 Days to Die plans come with two allocations, and the Network tab adds the rest - including a separate one if you want telnet or the dashboard reachable.

Telnet is the remote admin interface, and it is plain text: the password crosses the network in the clear, and anything typed into it has full server rights. If TelnetPassword is empty the server only listens on loopback, which is the safe default. If you open it, set a strong password, restrict the source address, and read RCON safely first - the same reasoning applies to every remote console.

WebDashboardEnabled turns on a small web interface on port 8080. EnableMapRendering makes it draw the explored map, which is genuinely nice and costs both CPU and a steadily growing folder of tiles.

Admins and console commands#

Admin rights live in serveradmin.xml beside the config file. The server writes it on first start, and that generated file is the authority for the exact format - older versions identified people by a steamID attribute, and current versions use a platform and user id pair, because console players are on the same servers now.

<adminTools>  <admins>    <admin platform="Steam" userid="76561198012345678" permission_level="0" />  </admins>  <permissions>    <permission cmd="dm" permission_level="0" />  </permissions>  <whitelist />  <blacklist /></adminTools>

Permission levels run from 0, which is the owner and can do everything, to 1000, which is every player. Each command has its own required level, so you can hand a moderator kick and ban without handing them the creative menu.

mem is the one to learn. It prints entity counts alongside memory, and an entity count that keeps climbing between restarts tells you something is not despawning - usually dropped bags or animals - long before the server runs out of memory. Reading a server load graph covers what the memory side of the same story looks like from outside.

Mods and modlets#

Mods go in a Mods folder in the server root, one folder each, containing a ModInfo.xml and usually a Config directory of XML files that patch the game's own configuration with XPath operations. That design has an unusually pleasant consequence:

• A modlet that only patches XML is server-side. The server sends its configuration to joining clients, so a modlet that changes recipes, loot, spawns or progression works with nobody installing anything. This covers a large share of the popular quality-of-life mods.
• A mod that adds assets or code is not. New icons, models, sounds or a DLL mean every client must install it too, and EACEnabled must be false for anything using Harmony patching. Turning EAC off is a real trade - you are removing the anti-cheat to gain the mod.
• Overhauls are both, plus a new world. Darkness Falls and its peers expect a fresh save, not an existing one.

Add one modlet, restart, play an evening, add the next. It is slower than pasting a list and it is the only method that tells you which one broke the server, because the answer is always the last one you added. Every game update invalidates modlets until their authors catch up, so a modded server should not take updates automatically - keeping a modded server clean has the wider version of that argument, and the admin commands and modlets guide goes deeper into the XPath side.

Saves, region files and the slow corruption#

The save lives under the user data folder, in Saves/<World>/<GameName>/: the game state, a Player folder with one file per person who has ever joined, and a Region folder of .7rg files, each covering a square of the map.

That last detail is the useful one. The world is not one file, it is hundreds, and a server killed mid-write can leave exactly one of them damaged. The symptom is odd and specific: a particular area that crashes clients who walk into it, while the rest of the map is fine. The repair is proportionate - restore that one .7rg from a backup and lose only what was built inside it, rather than rolling the whole world back.

• Stop the server properly. shutdown, or the panel's Stop, both of which save first. Killing the process is what damages region files in the first place.
• Back up the whole save folder, not just the region directory. The player files hold everybody's inventory and skill points, and restoring a world without them is its own disaster.
• Test a restore once. A backup nobody has restored is a hypothesis - backups that actually restore is the short version of why.
• Keep a copy of the generated world too. Regenerating from the same seed should produce the same map, but "should" is doing work in that sentence across game versions.

On RE:NODE, backup slots are on every 7 Days to Die plan, backups are stored off the machine they protect and can be locked against rotation, and the Schedules tab can run an ordered task list - a saveworld command, a short delay, then the backup. If the server ever reaches its memory limit the container is stopped and restarted clean rather than left to swap, which is safer than the alternative but is still an unsaved stop, so a nightly scheduled backup matters more on a server running near its ceiling.

Troubleshooting#

The server does not appear in the list. Check ServerVisibility is 2, check 26900 is open on both TCP and UDP, then wait a few minutes. Test by connecting directly to the address from the client's Connect to IP option; if that works, it is a listing problem, not a server problem.

The first start takes forever. Random world generation on a 10k map is slow. Watch the log rather than the clock, and let it finish - stopping halfway leaves a partial world that will have to be regenerated anyway.

New players time out while joining. They are downloading the explored world. Raise ServerMaxWorldTransferSpeedKiBs from its default of 512.

Modded clients are kicked immediately. Easy Anti-Cheat. Set EACEnabled to false if the mod needs it, and accept what that means.

One area crashes everybody who enters it. A damaged region file. Find the .7rg covering those coordinates and restore that one file.

Memory climbs all week and the server dies on horde night. Restart daily. 7 Days does not release everything it allocates, and horde night is the worst possible moment to find the limit.

Players lost their characters after a config change. GameName or GameWorld changed, so a new save loaded. The old save is still on disk under its own name.

FAQ#

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

Eight gigabytes for Navezgane or a 6k world with a few friends, ten to twelve for an 8k random world with a full group, and more with overhaul mods. World generation spikes above the running figure, so the map you can create is a smaller map than the one you can run.

Is BloodMoonEnemyCount per player or for the whole server?

Per player. Four players at eight each means thirty-two zombies. MaxSpawnedZombies is the server-wide ceiling and silently clamps the total, which is why raising the per-player count sometimes changes nothing at all.

Do players need to install the server's mods?

Only if the mod adds assets or code. A modlet that just patches XML - loot, recipes, spawns, progression - is sent to clients by the server and needs nothing installed. Anything with new models, icons or a DLL has to be on both sides.

Can I change the world size without losing our save?

No. World size is a property of the generated world, and changing it generates a new one. Your existing save stays on disk under its old GameName, so the change is reversible, but there is no way to expand a world in place.

Why does the server stutter on a schedule?

It is saving, or it is the dynamic mesh doing structural work. A regular hitch every few minutes is the save; an irregular one after a base collapses is the mesh, and DynamicMeshLandClaimOnly narrows where that work happens.

Should I turn Easy Anti-Cheat off?

Only if a mod you want requires it, and only on a server where you know everyone. EAC is the main defence against client-side cheating in 7 Days to Die, and there is no partial setting.