7 Days to Die dedicated server on Linux: SteamCMD 294420, serverconfig.xml, ports and a safe telnet

Short answer: the 7 Days to Die dedicated server is a free Steam tool, SteamCMD app 294420 (the game itself is 251570, which the server does not need). On Linux you install it with SteamCMD as an unprivileged user, copy serverconfig.xml to a file of your own, open TCP 26900 and UDP 26900 to 26902, keep telnet (8081) and the web dashboard (8080) off the internet, and run it under systemd with a stop command that saves the world first. Plan 8 to 16 GB of RAM depending on map size.

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

Map size and mods move the number more than player count. There is no official RAM table for the dedicated server, so treat these as starting points for a vanilla server, then measure on your own world:

Generated worlds must be 6144 to 10240 blocks wide, in steps of 2048. The first start with a new seed builds the world before anyone can join, which is the most CPU- and memory-hungry moment of the server’s life. Check memory under real load, during a blood moon with everyone online, with free -h, and leave 1 to 2 GB for the operating system.

CPU is the other half. Blood moons are where it earns its keep: every zombie needs pathfinding and physics at the same moment, so for a single world, fast cores help more than many slow ones. VMHeaven’s Hi-CPU KVM (AMD EPYC, ECC memory) is built for that kind of load; Standard KVM gives more Intel cores per plan if the box also runs other services. To size 7 Days to Die against eight other games on both lines, see gaming VPS.

How do I install the server with SteamCMD?

1. 1Create a service user and folders

   sudo useradd --system --create-home --home-dir /opt/7dtd \
     --shell /usr/sbin/nologin sdtd
   sudo install -d -o sdtd -g sdtd /opt/7dtd/server /opt/7dtd/data /opt/7dtd/backups

2. 2Install SteamCMD

   It is packaged in Ubuntu’s multiverse and Debian’s non-free component and needs the i386 architecture. Accept the Steam licence when the installer asks.

   sudo add-apt-repository -y multiverse
   sudo dpkg --add-architecture i386
   sudo apt update && sudo apt install -y steamcmd

   sudo dpkg --add-architecture i386
   # skip the file if your sources already include non-free
   sudo tee /etc/apt/sources.list.d/non-free.sources >/dev/null <<EOF
   Types: deb
   URIs: http://deb.debian.org/debian
   Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
   Components: non-free
   Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
   EOF
   sudo apt update && sudo apt install -y steamcmd

3. 3Download app 294420

   sudo -u sdtd -H /usr/games/steamcmd \
     +force_install_dir /opt/7dtd/server \
     +login anonymous +app_update 294420 validate +quit

   That installs the current stable release. Server and players must run the same version, so if your group plays the experimental build, add -beta latest_experimental after 294420. Older stable versions stay available as branches such as -beta v3.2.0. Run the same command again to update.

Which serverconfig.xml settings matter?

Do not edit the shipped serverconfig.xml in place. An update can put the default back, and your settings go with it. Copy it, edit the copy, and point the start script at the copy:

cd /opt/7dtd/server
sudo -u sdtd cp serverconfig.xml myserver.xml
sudo -u sdtd nano myserver.xml

Change only the value= part of each line; the comments in the shipped file explain every property for your version. These are the lines worth touching first. UserDataFolder is commented out in the stock file: remove the comment markers around it, or the server keeps writing to its default location.

<property name="ServerName"           value="Our 7DTD server" />
<property name="ServerPassword"       value="a-password-for-friends" />
<property name="ServerPort"           value="26900" />
<property name="ServerVisibility"     value="2" />   <!-- 2 public, 1 friends, 0 unlisted -->
<property name="ServerMaxPlayerCount" value="8" />
<property name="GameWorld"            value="RWG" /> <!-- or Navezgane -->
<property name="WorldGenSeed"         value="pick-any-seed" />
<property name="WorldGenSize"         value="8192" />
<property name="GameName"             value="Season1" />
<property name="SandboxCode"          value="paste-the-code-from-the-game" />
<property name="UserDataFolder"       value="/opt/7dtd/data" />
<property name="TelnetEnabled"        value="true" />
<property name="TelnetPort"           value="8081" />
<property name="TelnetPassword"       value="" />   <!-- empty = loopback only -->
<property name="WebDashboardEnabled"  value="false" />

GameName names the save and seeds the decoration, so changing it later starts a new save on the same map.

Since V3.0 the difficulty and game-rule settings are no longer separate properties. Old lines such as GameDifficulty, XPMultiplier or BloodMoonFrequency are ignored without an error. Instead, pick the rules in the game’s sandbox options on your PC, copy the code the menu generates and paste it as the SandboxCode value. Do not edit the code by hand, and leave the shipped value alone if the default rules suit you.

A broken tag can stop the server from starting or from reading your settings, so check the XML before every restart:

sudo apt install -y libxml2-utils
xmllint --noout /opt/7dtd/server/myserver.xml && echo OK

Which ports does a 7 Days to Die server need?

The game uses ServerPort (26900 by default) over TCP and UDP, and the next two UDP ports, 26901 and 26902. If you change ServerPort, the two UDP ports move with it. Open exactly those and nothing for 8080 or 8081:

sudo ufw allow 26900/tcp comment '7DTD'
sudo ufw allow 26900:26902/udp comment '7DTD'
sudo ufw status

# with the server running: game ports on all addresses, telnet on 127.0.0.1 only
sudo ss -tulpn | grep -E ':(2690[0-2]|8080|8081)\b'

How do I keep telnet and the web dashboard safe?

Both admin interfaces can run the whole server: kick and ban players, spawn items, shut it down. Treat them like SSH, not like the game port.

• Telnet is on by default, and that is fine while the password is empty. With no TelnetPassword, the server binds port 8081 to the loopback interface only, so nothing outside the machine can reach it. Setting a password makes it listen on every address, and telnet sends that password in plain text. The default lockout, 10 failed logins and then a 10-second block, slows guessing but does not stop it.
• Use the console over SSH instead. With telnet on loopback, this gives you the console from anywhere, encrypted: ssh -t you@your-server nc 127.0.0.1 8081. On Debian, install netcat-openbsd first if nc is missing.
• The web dashboard stays off unless you need it. If you turn on WebDashboardEnabled, leave port 8080 closed in the firewall and open it through an SSH tunnel: ssh -L 8080:127.0.0.1:8080 you@your-server, then browse to http://localhost:8080. The dashboard speaks plain HTTP, which is one more reason not to publish the port. Dashboard logins are created from the in-game console with createwebuser, which opens the dashboard in your browser; with the port closed, set WebDashboardUrl to http://localhost:8080/ and keep the tunnel open while you do it.
• Map rendering costs resources. EnableMapRendering draws map tiles for the dashboard while players explore. Leave it off unless you use that view.

To make yourself admin, join the server once, open the console over SSH as shown and run admin add YourPlayerName 0. Permission level 0 is the highest. The list is stored in serveradmin.xml in the Saves folder, which is /opt/7dtd/data/Saves/ with the setup above.

How do I run it as a systemd service?

Under systemd the server starts on boot and comes back after a crash. The stop is the part to get right. Instead of only signalling the process, the unit below connects to the local telnet port, sends saveworld, waits, sends shutdown, and then waits for the process to exit.

[Unit]
Description=7 Days to Die dedicated server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=sdtd
Group=sdtd
WorkingDirectory=/opt/7dtd/server
ExecStart=/opt/7dtd/server/startserver.sh -configfile=myserver.xml
# save and shut down over local telnet, then wait for the process to exit
ExecStop=/bin/bash -c 'exec 3<>/dev/tcp/127.0.0.1/8081 || exit 0; printf "saveworld\r\n" >&3; sleep 10; printf "shutdown\r\n" >&3; while kill -0 $MAINPID 2>/dev/null; do sleep 2; done'
TimeoutStopSec=180
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd
sudo systemctl status 7dtd

# the start script writes a timestamped log; follow the newest one
sudo sh -c 'tail -f "$(ls -t /opt/7dtd/server/7DaysToDieServer_Data/output_log__*.txt | head -n 1)"'

Where are the saves, and how do I back them up?

With UserDataFolder set as above, everything the server generates lives under /opt/7dtd/data: the save in Saves/<world name>/<GameName>/ and generated maps in GeneratedWorlds/. For a generated world, the world name is the one the generator gave the map, not RWG. Without UserDataFolder, the same folders sit in ~/.local/share/7DaysToDie of the service user. A world you generated in the game on your PC can be uploaded into GeneratedWorlds/; set GameWorld to its folder name and the server loads it instead of generating one.

Back up after a saveworld, so the archive matches what players see:

#!/bin/bash
set -euo pipefail
DEST=/opt/7dtd/backups
# flush the world to disk over local telnet; skip that if the server is not running
if { exec 3<>/dev/tcp/127.0.0.1/8081; } 2>/dev/null; then
  printf 'saveworld\r\n' >&3
  sleep 15
  exec 3>&-
fi
# exit code 1 only means a file changed while it was read; the archive is still usable
tar -czf "$DEST/7dtd-$(date +%F-%H%M).tar.gz" -C /opt/7dtd data || [ $? -eq 1 ]
# keep 7 days of archives
find "$DEST" -name '7dtd-*.tar.gz' -mtime +7 -delete

sudo nano /opt/7dtd/backup.sh     # paste the script above
sudo chown sdtd:sdtd /opt/7dtd/backup.sh && sudo chmod 750 /opt/7dtd/backup.sh
sudo crontab -u sdtd -e
# add:  30 5 * * * /opt/7dtd/backup.sh

Long-running worlds grow, and so do archives. On a VMHeaven VPS you can add disk space to a running server from the panel in 15 GB storage blocks, and the panel’s own backups, by hand or on a schedule, give you a way back from a bad update.

Why can’t players join? Common problems, most likely first

1. The server does not show up or refuses connections

Check the firewall rules and the ss output above. Then try a direct connection by IP and port from the game’s server browser, which skips the list. If that works but the listing does not, check ServerVisibility and give the master list a few minutes.

2. Version mismatch

The players’ game and the server must be on the same build. Compare the versions, then reinstall the server on the matching branch with -beta as shown in the install step.

3. Stuck on first start

A new RWG seed is being generated, which can take a long time on a 10240 map. Follow the log; to skip it, generate the world on your PC and upload it as described above.

4. Lag during blood moons

That is CPU, not bandwidth. MaxSpawnedZombies (64 by default) caps how many zombies the whole map holds at once, and the blood moon horde size sets the peak. Lower the first in the config file; the horde size has been part of the sandbox options since V3.0, so lowering it means generating a new SandboxCode. The alternative is faster cores; VPS high CPU usage shows how to confirm the bottleneck.

5. The server disappears without an error

Look for the OOM killer: sudo journalctl -k | grep -i 'killed process'. If it fired, the world has outgrown the RAM; see processes killed when memory runs out.

6. Config changes do nothing

The server reads its config only at start, and only the file named in -configfile. Edit myserver.xml, not the shipped file, run xmllint, then restart. If difficulty, XP or day length still look like the defaults after an update to V3, the old properties are being ignored: set SandboxCode as described above.

The SteamCMD and systemd steps follow the same pattern as the Satisfactory server guide. Game servers also attract floods; DDoS filtering is on by default in both VMHeaven locations, Amsterdam and Frankfurt, and the DDoS-protected VPS guide explains what it covers.

Frequently asked