7 Days to Die Server Setup: SteamCMD, serverconfig.xml, Ports & Telnet
How to stand up a 7 Days to Die dedicated server: installing the free app 294420 with SteamCMD (anonymous login works), the serverconfig.xml keys that matter and the ServerName vs GameName trap, all three UDP/TCP port groups to forward, the V3.0 SandboxCode change that silently ignores legacy difficulty/XP/loot properties, adding admins in serveradmin.xml, and remote administration over telnet and the built-in web control panel.
7 Days to Die is easy to self-host - the dedicated server is a free, anonymous SteamCMD download that runs on modest hardware for a small group. What actually trips up new hosts: three separate port groups (game, telnet, web panel), the ServerName vs GameName mix-up that silently loads a different save, the V3.0 SandboxCode migration that made the old difficulty/XP/loot properties dead weight, and EAC mismatches. This guide covers all of them.
Installing the server with SteamCMD
The dedicated server is its own free Steam app - 294420 ("7 Days to Die Dedicated Server"), separate from the game client (251570). Anonymous login works - you do not need an account that owns the game:
so you can keep your config out of the install dir:
./startserver.sh -configfile=myserver.xml
Wrap it in a systemd unit or restart loop for unattended operation - the server does not restart itself.
Versions and save compatibility
7 Days to Die left its long alpha era with V1.0 in July 2024 and has shipped major versions since (V3.0 "Dead Hot Summer" went stable in mid-2026 - check the current status before you install). The rule that has held across every major jump: major versions break save compatibility. A new major version generally means a fresh world, and there is no downgrade path for a world once it has been opened by a newer version - back up your save folder before every upgrade, and pin a Steam branch if you need to stay put.
serverconfig.xml: the keys that matter
The config is a flat XML file of <property name="..." value="..."/> lines. The ones most hosts touch first:
ServerName - the display name in the server browser. Cosmetic only.
GameName - not cosmetic: it is the on-disk save-folder key (<Saves>/<GameWorld>/<GameName>/). Changing it silently creates/loads a different world - the #1 "my server wiped itself" false alarm.
ServerVisibility - 2 = public list, 1 = friends only, 0 = not listed (direct connect still works).
GameWorld - Navezgane (the hand-made map) or RWG for a random world, with WorldGenSeed and WorldGenSize (supported sizes 4096-10240, multiples of 2048). Bigger worlds cost real RAM and a long first-boot generation - expect several minutes before the server is joinable the first time.
EACEnabled - must match how clients launch (EAC on vs the no-EAC launcher option). A mismatch shows up as instant kicks on join.
The V3.0 change: SandboxCode replaced the old gameplay properties
Since V3.0, the gameplay/sandbox knobs (difficulty, XP multiplier, loot abundance, blood moon settings and many more) are consolidated into a single SandboxCode property - a code string you generate from the in-game Sandbox Options menu and paste into serverconfig.xml:
The legacy properties (GameDifficulty, XPMultiplier, LootAbundance, ...) are removed or non-functional on current stable, and there is no warning: an old config keeps starting fine but the server silently runs default settings. If you copied a serverconfig.xml from a pre-V3.0 guide and your difficulty/loot settings "don't apply" - this is why.
Ports to forward
The game uses ServerPort plus the two ports above it, and they move together if you change it:
26900/TCP + 26900/UDP - server list and query traffic.
26901/UDP - SteamNetworking transport (disabled by default).
26902/UDP - LiteNetLib, the default transport actually carrying game traffic.
Forward all of them (26900-26902/UDP + 26900/TCP in the default layout). Two more ports exist but are admin surfaces, not game ports: telnet (8081/TCP) and the web control panel (8080/TCP) - do not forward those to the internet unless you have set strong passwords and mean to expose them.
Admins: serveradmin.xml
Admin permissions live in serveradmin.xml - in the save/user-data folder, not the install folder (Linux: ~/.local/share/7DaysToDie/Saves/, Windows: %APPDATA%\7DaysToDie\Saves\; the tree is created after the first run). Permission levels run 0-1000 with 0 the highest; anyone not listed is 1000. The easiest way to add yourself is from the server console:
admin add <Steam64-id or in-game name> 0
or edit the XML directly: <admin steamID="7656119..." permission_level="0" />.
Remote admin: telnet and the web control panel
7 Days to Die's remote console is telnet - it does not speak the Valve Source RCON protocol, so RCON clients will not connect. In serverconfig.xml:
With an empty TelnetPassword the console only listens on localhost - a sane default; set a password only if you genuinely need remote telnet, and firewall the port to your own IP. There is also a browser control panel (console + explored-map view): set ControlPanelEnabled=true (default port 8080) and create a login from the server console with createwebuser.
The simulation is single-thread bound - CPU clock speed beats core count. For a small (4-8 player) vanilla server plan on 8-16 GB RAM and an SSD; large RWG worlds and mods push RAM up quickly, and first-time world generation is the most expensive thing the server ever does.
MantaScope tracks your 7 Days to Die server from the browser - live player count, population history, uptime and downtime incidents, server rank, and decoded server attributes (difficulty, EAC, loot and blood-moon settings where servers report them) - so you can watch your community without a desktop tool, alongside scheduled monitoring, Discord status alerts, and an embeddable status banner for your community page.
7DTDServer Admin
