7 Days to Die Server Config: Find and Edit the Right File

The 7 Days to Die server config is the serverconfig.xml file read by a dedicated server when it starts. On Steam, find it inside the dedicated-server install folder; with SteamCMD, it is in the install directory you chose. The file the server reads can differ if its launch command uses -configfile. Stop the server, back up the right file somewhere Steam will not manage, make one small change, and check the startup log after restarting. This keeps you from editing a sample or a shipped copy that a later validation can replace. If an older tutorial also asks you to set XP, loot, or zombie rules in XML, see the 30 gameplay settings that V3.0 moved to SandboxCode.

Find the 7 Days to Die server config file#

For a Steam Tools install on Windows, open the Steam library that contains 7 Days to Die Dedicated Server and browse to steamapps\common\7 Days to Die Dedicated Server\serverconfig.xml. Steam can use more than one library, so the drive letter and parent folders vary. In Steam, right-click the dedicated-server tool, choose Manage → Browse local files, then open serverconfig.xml in that folder.

For SteamCMD, the location is the directory passed to force_install_dir, followed by serverconfig.xml. If the command installs to D:\games\7dtd-server, check:

D:\games\7dtd-server\serverconfig.xml

On Linux, use the same rule: the active file is in the SteamCMD install directory you selected. For example, if you install to /home/yourname/servers/7dtd, check:

/home/yourname/servers/7dtd/serverconfig.xml

The Steam Tool can instead install under a Steam library’s steamapps/common/7 Days to Die Dedicated Server/ directory. Do not confuse this dedicated-server file with the single-player client’s local settings, a serveradmin.xml permissions file, or XML files under Data/Config. Valve’s dedicated-server instructions describe the Steam Tool and SteamCMD routes; your selected library or install directory determines the path on disk.

For a rented server, open the game’s file manager and locate the provider’s active serverconfig.xml, or use the provider’s settings form if it manages the field you need. Panel layouts and storage paths differ. Ask the host where its active config lives if the file manager shows multiple copies; the file beside an old backup is not necessarily the one used at startup.

Check which config file the server actually loads#

Do not assume that the first serverconfig.xml you find is active. The dedicated-server launch script passes -configfile=serverconfig.xml by default, which selects the file relative to the working directory. A different path in the launch command takes precedence for that startup. The shipped Windows startdedicated.bat includes the option, and the Linux startserver.sh uses the same -configfile pattern.

Before editing, inspect the command or script that starts your server and note the path after -configfile=. If there is no custom path, use the stock file in the server install directory. If the option contains a full path, that is the copy to back up and edit. For service managers or hosting panels, check the configured startup command or ask support which file their process uses rather than guessing from folder names.

You can point a self-hosted server to a separate file by passing an absolute path:

7DaysToDieServer.exe -configfile="D:\games\7dtd-config\myserver.xml" -dedicated

./startserver.sh -configfile="/home/yourname/7dtd-config/myserver.xml"

The option only helps if your launch method passes it through and the file is readable by the service account. After changing a script, restart once and look for the Parsing server configfile: line. It should name the exact file you intended. If the log names another path, fix the command before changing XML values; otherwise you will keep editing a file the server ignores.

Keep an editable copy outside the Steam install#

1. Stop the server

   Wait for the process to exit before copying its configuration. This prevents the service or panel from writing another version while you edit.

2. Copy the active file outside the install

   Copy it to a folder outside steamapps, for example D:\games\7dtd-config\myserver.xml or /home/yourname/7dtd-config/myserver.xml. A copy beside the install is still part of the Steam-managed files and is easier to replace by accident.

3. Keep a known-good backup

   Before each set of changes, save another dated copy. If the next start fails, stop the process and restore that copy rather than trying several fixes at once.

SteamCMD’s app_update 294420 validate checks the installed server files and repairs files that differ from the selected depot. To run the check yourself, use the install folder that contains the server files:

steamcmd +force_install_dir "/path/to/7dtd-server" +login anonymous +app_update 294420 validate +quit

In an isolated copy of the V3.3.0 public server build (25661908), I changed the stock ServerName, recorded its hash, then ran this check. SteamCMD verified the install, restored the shipped serverconfig.xml to its original hash, and reported the app fully installed. The separate custom copy remained outside the managed install. That is why a personal config belongs elsewhere; it is not a safe assumption that edits to a shipped file will survive validation. This is a historical V3.3.0 test, not a new V3.4.0 runtime check.

Keep the backup until the server restarts cleanly and the expected value appears in the startup log or game. If an update changes the stock XML, compare the new file with your copy instead of replacing it wholesale. Reapply only the options you still want and confirm each property exists in the file shipped with the version you are running.

Edit one XML value without breaking the file#

With the server stopped, open the active copy in a plain-text editor. A setting is a property element with a name and a value; change the value inside the quotation marks and leave the surrounding XML intact. For example, ServerName appeared in the V3.3 server file used in this guide’s test:

<property name="ServerName" value="My Game Host" />

Change only the value you need:

<property name="ServerName" value="My Friends' World" />

Keep the quotation marks, angle brackets, property name and closing slash. Do not add a second property with the same name or paste an entire old configuration over the current file. If a value contains an ampersand or angle bracket, XML requires escaping; avoid special characters in a test value until the server starts successfully.

1. Change one value

   Edit the text inside the current property’s value quotes. Leave its name, tags and surrounding XML intact, and do not add a second property with the same name.

2. Check the saved file

   Save as plain text with the .xml extension, then open the file again. Confirm the change is there and your editor did not add .txt or leave a temporary file as the only copy.

The server can parse a valid XML file while ignoring a property that is no longer supported, so syntax alone does not prove a setting still does anything.

Restart and confirm the change in the log#

1. Start with the same launch command

   Use the launch method you checked earlier. Read the newest startup log and confirm the Parsing server configfile: entry names your active copy.

2. Confirm the changed value

   Find the property or resulting value the log reports. For the ServerName example, check the server listing from a client after startup as a second confirmation. Wait for the server’s normal ready state before inviting players.

3. Restore the backup if startup fails

   Stop the process, restore the known-good file, and inspect the final log lines for the parse error. Retry with one corrected change at a time.

Do not make several edits at once: one change makes the first failure much easier to identify. A successful XML parse still does not establish that every setting is supported or that it is safe for an existing world.

If the file parses but the log names another path, go back to the launch command. If the path is correct but the option has no effect, check the property against the current version’s shipped XML. For V3 gameplay rules such as XP, loot and blood-moon options, use SandboxCode; old guides may list standalone properties that no longer control those rules. The Fun Pimps’ V3.0 release notes describe that configuration change. For what each current setting means, see our V3 server settings reference.

Protect an existing world before changing map options#

Some settings describe the server and access rules; others affect how a world is generated. A valid edit is not automatically a safe edit for a save your group already uses. Before changing a world, seed, size or save-name field, make a backup of the whole save while the server is stopped and check whether the change applies only to a new world. Do not assume that changing a value in XML regenerates or repairs an existing map.

Keep map changes separate from the file-location task: first prove which file the server loads, then review the setting’s version-specific behavior. If you are unsure whether a change applies to a running save, leave it alone until you have a restorable backup and have checked the impact. This avoids using a config edit as an untested migration plan.

Use a panel form for settings it already manages#

If you rent a server, you may not need to edit XML for common fields. Game Hosting’s 7 Days to Die panel saves the settings it manages into data/serverconfig.xml when the server starts and keeps the other values in the file. That gives you a form for managed fields such as the server name, password and map, while leaving custom values intact. It does not mean every host exposes the same file path or lets you change its launch arguments. If you are comparing panels, use the control-panel checklist to check whether the host exposes the files and controls your group needs.

Use the form for fields it explicitly controls, and keep a copy of custom XML values before saving or changing a version. If you need a setting the panel does not expose, check whether the provider supports direct file editing and whether its startup command can point to a separate file. The useful question is not just “Can I upload XML?” but “Which file does the running process read, and can I restore the previous copy?”