Run a 7 Days to Die Dedicated Server on Linux: Step by Step

A 7 Days to Die dedicated server on Linux is a good fit when you want the world to keep running without leaving a player’s game open. On Ubuntu, install the separate dedicated-server app with SteamCMD, give it its own service account, and store the world outside the Steam-managed install. Then let systemd start the process and send it a normal stop signal. The current public Stable branch is V3.4.0; the optional latest_experimental branch points to the same dedicated-server build in Steam’s branch data checked October 26, 2026. The runtime checks documented here were performed on V3.3.0 Stable, so they do not establish V3.4.0 startup, save, or shutdown behavior. Check the log line that confirms the process reached the game-server login stage, then test the exact build you choose.

Know what this Linux setup covers#

The Fun Pimps publishes a Linux dedicated-server build as Steam app 294420, separate from the playable client, app 251570. Valve’s SteamCMD command-line tool can download the server anonymously, so the machine does not need the game client or a logged-in Steam desktop session. Your players still need compatible game builds to join.

The commands below target Ubuntu 24.04 on x86-64. They keep the server files in /srv/7dtd/server, settings in /srv/7dtd/data, and the world data under /srv/7dtd/data/userdata. You can choose another path, but use the same one in the config, service unit, backup job, and later restore instructions.

This is a manual SteamCMD and systemd setup. It does not install LinuxGSM, Docker, third-party mods, or a router rule. If you are still deciding between a self-hosted machine and another route, compare the ways to run a dedicated server before you start.

Install SteamCMD and create a server account#

Use a separate Linux account so the game process does not run as root. Ubuntu lists steamcmd in the multiverse component as an i386 package; enabling the i386 architecture lets APT install that package and its dependencies. The dedicated-server app itself includes a Linux x86-64 binary, so do not copy old instructions that assume the game server needs the same 32-bit runtime as SteamCMD.

If steamcmd is not found in your enabled sources, add Ubuntu’s multiverse component first. Then install the package and certificate bundle:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository multiverse
sudo apt update
sudo apt install -y steamcmd ca-certificates

Create a system account and directories owned by that account:

sudo adduser --system --group --home /srv/7dtd 7dtd
sudo install -d -o 7dtd -g 7dtd /srv/7dtd/server /srv/7dtd/data

If Ubuntu asks you to accept the Steam license during package setup, complete that prompt before continuing. ca-certificates is also important: without trusted root certificates, this V3.3 server test stopped when it tried to initialize EOS. Installing the package fixed the trust error; it was not a 7 Days to Die setting or a reason to disable TLS checks.

Install the current dedicated-server build#

Use SteamCMD’s anonymous login to install app 294420 into the empty server directory. validate checks the downloaded files against the selected Steam branch. The default public branch is the Stable route used below.

sudo -u 7dtd -H steamcmd \
  +force_install_dir /srv/7dtd/server \
  +login anonymous \
  +app_update 294420 validate \
  +quit

Wait for SteamCMD to report that the app is fully installed. A large first download can take a while; do not start the service while SteamCMD is still verifying or replacing files. If the command fails with an authentication or certificate error, fix the system’s time and certificate package first. Do not work around TLS errors by turning certificate checks off.

The official V3.4.0 Stable announcement is dated October 26, 2026. Steam’s dedicated-server branch table showed public, v3.4.0, and latest_experimental on build 26167630 at the October 26 check; branch assignments can change. Select the branch that matches the clients, and read the current branch before updating. Back up the world before changing branches. The isolated runtime test described in this guide used V3.3.0 Stable build 25661908; it was not repeated on V3.4.0.

After installation, confirm the Linux launcher and the shipped config exist:

test -x /srv/7dtd/server/startserver.sh
test -f /srv/7dtd/server/serverconfig.xml

The V3.3.0 test copy of startserver.sh expected a -configfile= argument, set LD_LIBRARY_PATH to the install directory, and launched 7DaysToDieServer.x86_64. It wrote timestamped output_log__*.txt files beside the installed server. Check the launcher shipped with your selected build; if either file check fails, use SteamCMD again and read its output before troubleshooting systemd.

Keep settings and saves outside the install folder#

Copy the shipped config into the data directory. SteamCMD owns the install folder and can replace shipped files during validation or an update. Keeping your active config and world data elsewhere makes those two kinds of changes easier to manage separately.

sudo -u 7dtd cp /srv/7dtd/server/serverconfig.xml /srv/7dtd/data/serverconfig.xml
sudo install -d -o 7dtd -g 7dtd /srv/7dtd/data/userdata
sudoedit /srv/7dtd/data/serverconfig.xml

In the copied XML, set the server name, choose whether it should be listed, and enable UserDataFolder with an absolute path:

<property name="ServerName" value="My Linux World" />
<property name="ServerVisibility" value="2" />
<property name="UserDataFolder" value="/srv/7dtd/data/userdata" />

The UserDataFolder line was commented in the V3.3.0 test copy, so add it as an active property inside <ServerSettings> after checking the config shipped with your selected build. The V3 server reads SandboxCode for its gameplay preset. Since V3.0, many gameplay settings in older guides were removed from serverconfig.xml; use the current V3 settings reference instead of adding old values such as GameDifficulty or DayNightLength. The ServerVisibility=2 example came from the inspected V3.3.0 config; verify the property’s behavior in your installed version before relying on public listing.

In an isolated Ubuntu 24.04 run of the public V3.3.0 build, the log reported UserGameDataDir: /srv/userdata after setting that property, and the world files appeared below that directory. That confirms the path behavior on the tested build only. Keep the account as owner so it can write saves, generated files, and logs. Include the complete data directory in your backup plan; copying only serverconfig.xml does not back up the world.

Build a systemd service that can stop cleanly#

Put the service in /etc/systemd/system/7dtd.service. WorkingDirectory mattered for the V3.3.0 launcher tested here, which expected its server libraries relative to the install folder. Check the launcher in your selected build; the unit runs as the restricted 7dtd account and points at the separate active config.

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

[Service]
User=7dtd
Group=7dtd
WorkingDirectory=/srv/7dtd/server
ExecStart=/srv/7dtd/server/startserver.sh -configfile=/srv/7dtd/data/serverconfig.xml
Restart=on-failure
RestartSec=10
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target

systemd’s service defaults send SIGTERM and apply the configured kill mode to the service control group. The timeout gives the game time to stop; if the process exceeds it, systemd can escalate to SIGKILL. Do not replace that with an immediate kill command for routine maintenance.

Enable and start the service, then check that systemd sees it as active:

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

For a vanilla V3.3.0 server in an isolated Ubuntu 24.04 container, sending SIGTERM to the game process logged ServerShutdown, SaveAndCleanupWorld, and Exited thread SaveChunks, then wrote the world files. Restarting with the same data directory returned to StartGame done and GameServer.LogOn successful. That test checked the game’s signal handler and default world startup on V3.3.0; it did not boot systemd, test V3.4.0, or simulate player progress. Check your own stop log before trusting a maintenance window.

Open the game ports and keep admin ports private#

With the default ServerPort of 26900, The Fun Pimps’ dedicated-server support FAQ lists inbound TCP 26900 and UDP 26900 through 26903. Its table says UDP 26903 is currently unused but warns that leaving it closed can block a join, so include it when applying that documented default. If you change ServerPort, adjust the related game ports from that base as well.

For a host that uses UFW, allow the documented game traffic:

sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw status

If the server is behind a home router, a host firewall rule alone does not forward traffic through the router. Make the matching router rule point to this machine’s LAN address, and test from a separate network. This guide does not claim to have tested your router, cloud firewall, or player connection.

Do not expose the admin interfaces as ordinary game ports. In the inspected V3.3.0 config, the web dashboard was disabled by default and telnet enabled; with no telnet password, the tested process listened on loopback only. Check those defaults in your selected build, and keep TCP 8080 and 8081 closed to the public internet unless you deliberately enable a secured administrative path. A firewall rule for the game does not require opening either port.

Start the service and confirm it reached the server login#

systemd can say a process is active before the game finishes initialization. Check the game log for GameServer.LogOn successful; it appeared after StartGame done in the V3.3 test. This confirms the server reached its platform logon stage, not that a remote player can join through your firewall.

sudo systemctl status 7dtd --no-pager
sudo grep -hE 'StartGame done|GameServer.LogOn successful|Error starting dedicated server' \
  /srv/7dtd/server/output_log__*.txt | tail -20

If the service is active but the log does not reach the successful line, read the preceding error before changing ports. A TLS trust error can point to missing certificates. A bad -configfile path is reported by startserver.sh. A missing world or permissions problem should be handled in the data directory as the 7dtd account, not by running the process as root.

Now test a real client on a compatible game build. Check the server name in the browser if you set it public, or use the method supported for your group’s platform. For PC with PS5 or Xbox Series X|S, do not treat a successful Linux startup as proof of compatibility. The Fun Pimps’ official cross-platform checklist calls for ServerMaxPlayerCount no higher than 8, ServerAllowCrossplay=true, EACEnabled=true, and IgnoreEOSSanctions=false. Check current game-version matching, public listing and mod requirements with the official guidance before promising console joins; this tutorial did not configure or test those conditions or console discovery.

Stop, update, and protect the world#

Use systemd for routine stops and restarts. Check the logs before updating so you know whether the server completed its shutdown:

sudo systemctl stop 7dtd
sudo grep -hE 'ServerShutdown|SaveAndCleanupWorld|Exited thread SaveChunks' \
  /srv/7dtd/server/output_log__*.txt | tail -20

Only proceed when the process has stopped and the save-cleanup lines appear. Then update the app as the service account, and start it again:

sudo -u 7dtd -H steamcmd \
  +force_install_dir /srv/7dtd/server \
  +login anonymous \
  +app_update 294420 validate \
  +quit
sudo systemctl start 7dtd

Take a separate copy of /srv/7dtd/data/userdata before changing branches, changing a mod set, or applying a game update. Save compatibility depends on the source and target builds; neither a successful install nor a clean shutdown guarantees that an older world or an overhaul will load without problems. For mods, follow the mod author’s supported game version and back up before changing the installed files. The Fun Pimps’ mod guidance says third-party mods can be unstable or unsupported and should match the game version. This guide does not cover mod installation or compatibility testing.

If maintaining a Linux machine, its updates, and its world backups is more work than your group wants, compare Game Hosting’s 7 Days to Die service. The managed panel includes scheduled restarts and three free backup slots, so routine service tasks sit beside the game settings. That does not remove the need to choose a compatible game version or mod set.

For another self-hosting route, start with the dedicated-server route comparison. If you want to change server rules, use the current server settings reference and keep a backup before you edit the live world.