7 Days to Die Server Settings That Survive Updates
Settings that “reset” are one of three things: a key V3 no longer reads, a serverconfig.xml an update replaced, or a command-line override. How to tell which, and how to run the server on your own copy so restarts and updates leave it alone.
November 5, 20266 min read
Share:
Share
On This Page
"I changed the settings and they reset" is a common 7 Days to Die server complaint, and it usually isn't one problem. It is one of three, and they look identical from the outside: the setting is no longer read, the file was replaced, or something else is overriding it. This article explains how to tell which one you have and how to set a server up so its settings stay put through restarts and updates.
Cause 1: you edited a setting V3 no longer reads
Since V3.0, thirty gameplay properties are no longer read from serverconfig.xml. They include GameDifficulty, every BloodMoon* setting, DayNightLength, DayLightLength, XPMultiplier, LootAbundance, LootRespawnDays, DropOnDeath and the zombie-speed settings. The Fun Pimps' V3.0 release notes say they "have been moved to a new SandboxCode XML property". You set them by building a code in the game's Sandbox Options menu and pasting it in.
An old line left in the file doesn't cause an error. The community wiki at wiki.7d2d.net says the server simply ignores it. So the edit "does nothing", and it looks as if the setting reset itself. If the setting you changed is about difficulty, blood moons, day length, loot, XP or zombies, this is almost certainly your cause. The full list and the fix are in SandboxCode explained.
Tired of an update undoing your settings?
Your server runs on its own copy of the settings file, which Steam updates never touch, and the Server Settings tab has a field for V3's Sandbox code instead of settings the game no longer reads. Backups, file manager and SFTP on every plan.
serverconfig.xml is not a file the server creates. It is shipped with the game, part of the depot Steam downloads for app 294420. That makes it Steam's file, and when an update ships a changed copy, Steam writes that copy over yours. The community wiki says the shipped file "is overwritten on every game update", and community Docker images for the server warn the same. However often it happens in practice, the conclusion doesn't change: don't keep your settings in a file Steam owns.
The symptom would be a server that played correctly for weeks and then, after an update, comes back as "My Game Host" on the default difficulty with no password.
Cause 3: the command line overrides the file
Any setting can be passed when the server starts, as -SettingName=value. The game's changelog added "overriding serverconfig settings via command line ('-settingname=value')". A command-line value beats the file. If a start script, a panel or a host passes -ServerMaxPlayerCount=8 or -ServerPort=26900, then whatever the file says, that is what the server runs. Check how your server is started before you assume the file is wrong.
The fix: run the server on your own copy
The way to make Cause 2 impossible is to point the server at a file Steam doesn't own:
cd /opt/7dtd
cp serverconfig.xml serverconfig.mine.xml
./7DaysToDieServer.x86_64 -configfile=serverconfig.mine.xml -quit-batchmode-nographics-dedicated
serverconfig.mine.xml isn't in the depot, so neither an update nor a validate touches it. Make every edit in your copy. The shipped serverconfig.xml stays as it is, and it is useful as a reference for the current defaults.
There is one trade-off. When an update adds a new property, your copy doesn't have it, and the server uses the game's default for it until you add the line. Comparing your copy against the freshly updated serverconfig.xml after a big update is the way to spot new properties.
Does the server rewrite its own config?
Some games write their settings back out at shutdown, which can undo an edit made while the server was running. We tested 7 Days to Die on V3.4.0 on 4 November 2026: the game does not rewrite its config file at shutdown, and edits made to the file survived restarts. That still means editing with the server stopped, or restarting after an edit, because the server reads the file only when it starts. But the game won't fight you over it.
Versions need their own files
If you pin a server to an older version for an overhaul mod, one settings file isn't enough. A V3 file contains SandboxCode, and older versions don't know it. In our test, a V2.6 server refused to start on a V3 settings file, stopping at "Unknown config option" for SandboxCode. A pre-V3 file, in turn, has properties V3 ignores. Keep a separate copy per version and point -configfile at the right one. More in running Darkness Falls or Undead Legacy on a dedicated server.
A checklist when a setting "reset"
Is it one of the thirty V3 removed? Then it lives in SandboxCode. Change the code, not the line. Running getsandboxoptions (gso) in the console shows what the server is actually using.
Which file is the server reading? Look at the -configfile= on its start line. If it is serverconfig.xml, an update can replace it.
Is the setting also on the command line? If so, the command line wins.
Did the server restart after the edit? Settings are read at start.
Is the server on the version you think? The start of the log names it. A version change can mean a different settings file is in play.
Back up the file
Whatever else you do, keep a copy of your edited settings file somewhere other than the server folder. The Fun Pimps "always encourage a new save with every update". A backup of the settings costs nothing and makes a bad update a five-minute fix.
Or let us run it
On 7 Days to Die server hosting at Connect, this is how the server is built. The game runs on serverconfig.connect.xml, which isn't part of the game's files, so Steam never replaces it. The first start copies it from the game's default serverconfig.xml. Delete it and the next start makes a fresh copy, which is the way to start over from defaults. The settings players change, Sandbox Code included, are on the Server Settings tab, and the thirty removed settings aren't offered at all. A property a later update adds runs on the game's default until you set it. Each game version keeps its own settings file. Backups, a file manager and SFTP come with every plan. Details in Server settings.
Frequently Asked Questions
Why did my 7 Days to Die server settings reset after an update?
Usually because the server reads serverconfig.xml, which ships with the game and can be replaced when an update ships a changed copy. Run the server on your own copy with -configfile=.
Why does changing GameDifficulty do nothing?
V3.0 moved GameDifficulty and about thirty other gameplay settings into SandboxCode. The old line is ignored.
Does the server overwrite serverconfig.xml when it shuts down?
Not in our test on V3.4.0: the game did not rewrite its config file at shutdown, and edits survived restarts.
Can a start script override my settings file?
Yes. Any setting passed as -SettingName=value on the command line beats the file.
Do I need a different settings file for an older version?
Yes, if you switch between V3 and V2.6 or earlier. In our test, V2.6 refused to start on a V3 file because it doesn't know SandboxCode.
Settings that survive every update
Your server runs on its own copy of the settings file, which Steam updates never touch, and the Server Settings tab has a field for V3's Sandbox code instead of settings the game no longer reads. Backups, file manager and SFTP on every plan.