7 Days to Die dedicated server on Linux: SteamCMD, serverconfig.xml, ports

What the server needs from the machine

The Fun Pimps publish system requirements for the game client only. On the Steam store, the Linux minimum is a 2.8 GHz quad-core CPU, 8 GB of RAM and 15 GB of disk, and the recommended line is a 3.2 GHz quad core and 12 GB. The same listing notes that running a dedicated server and the client on one computer doubles the RAM requirement, and that future releases may need more disk.

There is no official per-player or per-map memory figure. Our working rule, not The Fun Pimps': treat the client's recommended line as the floor for a headless server, then size up for larger random worlds, more slots and mods. The shipped config itself flags the settings that cost the most: MaxSpawnedZombies (64 across the whole map, with a large performance impact when raised) and ServerMaxAllowedViewDistance (6-12, high impact on memory).

Install with SteamCMD

On Ubuntu, SteamCMD comes from the multiverse repository and needs the i386 architecture. Install it, create a system user that owns nothing else, and pull app 294420 with an anonymous login: the server tool does not need a game licence on the machine. The firewall lines open the game ports from the Valve developer wiki's page for this server and nothing else.

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

sudo useradd -m -s /bin/bash sdtd
sudo -u sdtd /usr/games/steamcmd +force_install_dir /home/sdtd/server \
  +login anonymous +app_update 294420 validate +quit

sudo ufw allow OpenSSH
sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw enable

Allow OpenSSH before ufw enable, or the session that ran it is the last one you get. The same SteamCMD line, run again, updates the server; validate re-checks every installed file against the depot, so an edited stock serverconfig.xml can be put back to default. The Valve wiki's advice is to work on a renamed copy, which is the next step.

serverconfig.xml: the settings that matter

Work on a renamed copy of the shipped file, and change nothing but the value= attributes. Start with networking, slots and storage:

cd /home/sdtd/server && cp serverconfig.xml myserver.xml

<property name="ServerName" value="Wasteland East" />
<property name="ServerPassword" value="" />
<property name="ServerPort" value="26900" />
<property name="ServerVisibility" value="2" />
<property name="ServerMaxPlayerCount" value="8" />
<property name="UserDataFolder" value="/home/sdtd/userdata" />
<property name="TelnetEnabled" value="true" />
<property name="TelnetPassword" value="" />
<property name="WebDashboardEnabled" value="false" />
<property name="GameWorld" value="RWG" />
<property name="WorldGenSeed" value="MyGame" />
<property name="WorldGenSize" value="8192" />

• ServerVisibility: 2 lists the server publicly, 0 unlists it. The file warns that 1 (friends only) works only once a first player connects by IP, because nobody is a friend of a dedicated server.
• UserDataFolder is commented out by default. Uncomment it with an absolute path and generated worlds and saves land there; AdminFileName (serveradmin.xml) is read relative to its Saves folder.
• GameWorld ships as Navezgane. Set it to RWG and the server generates a world from WorldGenSeed at WorldGenSize.
• ServerAllowCrossplay is false by default; the file says crossplay servers are only found in searches, and only joinable, when sanctions are not ignored and the slot count is the default or fewer.
• ServerDisabledNetworkProtocols ships as SteamNetworking, which the file says suits a server with its ports open and no NAT in front of players.

Admins go in serveradmin.xml at permission level 0, following the commented example inside the file, or through admin add on the console. Levels run from 0 to 1000, and a user may run every command at or above their own level.

Telnet and the web dashboard stay private

Both admin interfaces control the whole server, so neither belongs on the public internet. The config handles telnet for you: with TelnetPassword empty, the server listens for telnet on the loopback interface only. Leave it that way, SSH in, and run telnet 127.0.0.1 8081 from the machine. Once a password is set that loopback-only limit no longer applies, and telnet carries the password unencrypted, so we would not set one.

The web dashboard ships disabled on port 8080. If you enable it (and EnableMapRendering for its map view), keep 8080 shut in the firewall and reach it through a tunnel: ssh -L 8080:127.0.0.1:8080 you@your-server (the account you normally SSH in with, not the service account), then point a local browser at http://localhost:8080. WebDashboardUrl exists for a reverse proxy in front of it. The Valve wiki lists TCP 8080-8081 only for remote administration; a tunnel removes the need.

Running it under systemd

The bundled startserver.sh exits with an error without -configfile=, passes your options through and launches 7DaysToDieServer.x86_64 with -quit -batchmode -nographics -dedicated, writing a timestamped log in 7DaysToDieServer_Data. Always give it your own config file. A unit file keeps it running and starts it at boot:

# /etc/systemd/system/sdtd.service
[Unit]
Description=7 Days to Die dedicated server
Wants=network-online.target
After=network-online.target

[Service]
User=sdtd
WorkingDirectory=/home/sdtd/server
ExecStart=/home/sdtd/server/startserver.sh -configfile=myserver.xml
Restart=on-failure
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target

Enable it with sudo systemctl enable --now sdtd. Before a planned stop or an update, run saveworld and then shutdown from the telnet console, so the world is written by the game rather than cut off by a signal.

Backups and updates

1. Save first: saveworld on the console, or stop the server with shutdown.
2. Archive the whole UserDataFolder, which holds the generated world, the saves and serveradmin.xml: tar czf /backup/sdtd-$(date +%F).tgz -C /home/sdtd userdata.
3. Copy the archive off the machine. A backup on the same disks protects against a bad wipe, not a failed array.
4. Update with the same SteamCMD command, then confirm the build with version on the console. Players must run the same game version to join.

SteamCMD can hold a server on an older build with a beta branch, for example -beta v2.6, when a mod has not caught up. Check which branches exist before pinning one.

Which of our machines fit

Any server on the game server range gives the process every core and all the memory, root, and an unmetered port: 1 Gbps on 10 of our 18 configurable lines, 500 Mbps on the other 8. Nothing counts the traffic, so a new player downloading a large random world costs the same as one who has it already.

Clock speed is the line to read. Much of our range is older hardware at modest clocks, and some of it sits below the 2.8 GHz the game listing names. The Intel processor list gives Intel's base and turbo frequency for every Intel chip we rent, and a custom build chooses the processor, memory and NVMe or SSD part by part. Install Ubuntu from the dashboard, as on any of our Linux servers.

Every rack server and blade carries an out-of-band controller (iLO, iDRAC or a BMC) with a browser console, so a broken firewall rule is fixed from the console rather than a ticket. A racked machine is live about 30 minutes after the order is approved; a build to order takes 4-24 hours. Pick the city nearest your players from our five data centers, each on our own network, AS19624, with a test IP to ping first.

When a whole machine is the wrong answer

A world played by two friends a few evenings a month does not need a dedicated machine: hosting from the game client costs nothing. On a whole machine you run SteamCMD, the config, the mods and the backups yourself.