7 Days to Die serverconfig.xml explainedAll important server settings

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

Structure of the serverconfig.xml

The file consists of a list of <property> lines with name and value. You edit it via the config editor in the web interface or via WebFTP/SFTP:

<property name="ServerName" value="My 7DtD Server"/>
<property name="ServerPassword" value=""/>
<property name="ServerPort" value="26900"/>
<property name="ServerMaxPlayerCount" value="8"/>

World & map

With GameWorld, you choose between the hand-built map Navezgane and a randomly generated world (RWG). With RWG, WorldGenSeed and WorldGenSize control the result:

<property name="GameWorld" value="RWG"/>
<property name="WorldGenSeed" value="MySeed"/>
<property name="WorldGenSize" value="6144"/>

More on this in the guide Navezgane & RWG: world & seed. These three entries are not affected by the switch to version 3.0.

Since version 3.0: the SandboxCode

With the 3.0 update "Dead Hot Summer" (stable since June 29, 2026), The Fun Pimps fundamentally restructured the game rules. Around 150 sandbox options now determine how a round feels - and they are no longer maintained individually in the serverconfig.xml but combined into a single code:

<property name="SandboxCode" value="AAAJABJACJADJARFBNC"/>

The example value corresponds to the former default difficulty. Around 30 well-known entries have been dropped for this and are ignored by a current server - among them GameDifficulty, XPMultiplier, LootAbundance, LootRespawnDays, DayNightLength, BloodMoonFrequency, BloodMoonRange, BloodMoonEnemyCount, AirDropFrequency, DropOnDeath, EnemyDifficulty, the BlockDamage values and the ZombieMove entries.

The code is not meant to be read or written by hand. The way leads through the game itself:

1. Start 7 Days to Die locally and, when creating a new game, open the menu with the sandbox options.
2. Choose an official preset or set the values individually - difficulty, XP, loot, day length, blood moon and much more.
3. Copy the generated code.
4. Stop the server, paste the code as the value of SandboxCode in the config editor or via FTP and start the server.

If you have taken over a serverconfig.xml from a version before 3.0, the old entries may still be in it. They do no harm, but they no longer have any effect either - if you wonder why a changed XPMultiplier does nothing, this is the explanation. Clear them out the next time you edit, so that the file no longer promises more than it delivers.

Difficulty, progression and loot

The levers themselves have stayed, only their location has changed: they now sit in the sandbox options. The most effective levers are the same as before:

• Difficulty - how much damage zombies deal and take. The most effective lever when a group is either overrun or bored.
• XP multiplier - the speed of progression. Higher values make the group level up faster.
• Loot abundance - how much is in crates and containers.
• Day length and blood moon - how long a game day lasts, every how many days the horde comes and how large it is.

For an after-work group that only plays a few hours a week, a higher XP multiplier and longer days are usually more effective than a lower difficulty: the round stays challenging but makes progress at all. If, on the other hand, you want a hard survival experience, lower the loot abundance first - scarcity changes the game more than tougher enemies. If console players are involved, fixed ranges apply to some of these values, see set up crossplay.

EAC & visibility

EACEnabled controls EasyAntiCheat - for DLL mods and overhauls, the value has to be false (see deactivate EAC). With ServerVisibility, you decide whether the server appears publicly in the server list (2), only for friends (1) or privately (0).

A private server with ServerVisibility=0 is not unreachable, just unlisted: anyone who knows the fixed address made up of IP and port can still join. For a closed group, a ServerPassword therefore belongs on top - see join a server.

How the XML syntax works

Unlike an INI file, every value sits in an element of its own with two attributes - name for the key, value for the value:

<?xml version="1.0"?>
<ServerSettings>
    <property name="ServerName"      value="My 7DTD Server"/>
    <property name="ServerPassword"  value=""/>
    <property name="ServerMaxPlayerCount" value="8"/>
    <property name="GameWorld"       value="Navezgane"/>
    <property name="SandboxCode"     value="AAAJABJACJADJARFBNC"/>
</ServerSettings>

The most common mistakes follow from this: a missing slash at the end of the line, an unclosed quotation mark or an & in the server name. All three cause 7 Days to Die to discard the entire file and start with default values - the server then runs normally, just with completely different settings. So write special characters in the name as &, or leave them out.

Change only a few values per round and restart in between. Anyone who touches ten lines at once and then finds that nothing was applied searches considerably longer for the typo.

Which values survive a restart

Some settings take effect at any time, others only when the world is created. This distinction saves a lot of fruitless troubleshooting:

GameName in particular is often underestimated: the value is not a display name but the folder name of the save. Anyone who changes it unintentionally starts a new world - the old state is preserved and can be reached again via the original name. How to control map and seed specifically is explained under world generation.

About the SandboxCode: the server reads a new code at startup. Because since 3.0 the code bundles a great many rules at once, check in the game after the restart whether the changed values actually arrive in the running world - with a fundamentally different configuration, a new world is often the cleaner way.

A backup is worthwhile before larger changes: backups are self-service throughout with us via WebFTP or SFTP, see create backups.

After saving: check instead of hoping

Because a faulty file is silently discarded, checking after the restart is the step that really matters. A short routine that makes every typo visible immediately:

1. Stop the server before you save - a change while it is running can be overwritten on shutdown.
2. Keep a copy of the working file before you touch several lines.
3. Start and check the ServerName. If the default name appears instead of yours, the file was discarded - then there is a syntax error, and not a single one of your changes is active.
4. Cross-check a second value that shows immediately in the game, for example the day length or the password.

The server name is deliberately the first check point: it is the only value you can see from outside without having to log in. You connect via the fixed server address made up of IP and port - the port is in ServerPort and is 26900 unless you change it. What always counts is the port shown to you in the web interface; how both are used together to connect is described in join a server.

And one more note on order: if you install mods and change the configuration at the same time, do it one after the other. If the server then does not start, it is otherwise impossible to tell whether the XML or the Mods folder is the cause.

Frequently asked questions