Set Up a 7 Days to Die Server on a VPS (2026): V3.1, SteamCMD, Ports, Backups and Updates

As of August 2026, The Fun Pimps has released the V3.1.0 Henpocalypse stable version. The official announcement also specifically reminds users: when the dedicated server cannot connect, confirm that the server has selected Default Public Version, that is, the current V3.1.0 stable branch.

So a new server does not need to add latest_experimental or old Alpha branch parameters. The client and server must use compatible versions; if teammates stay on the experimental branch while the server runs the default stable branch, the most common result is a version mismatch or an inability to join.

V3.1 adjusted sandbox options such as day/night enemy and animal density and spawn rates, so old preset codes may no longer work. Back up before upgrading an existing server, and do not test directly on your only save. This article is designed for a new server; existing V2.6/V3.0 worlds should first be verified on a copy.

The official support FAQ gives a minimum starting point of four cores at 2.8GHz, 8GB of memory and 20GB of available space, and recommends four cores at 3.2GHz and 16GB of memory. It also notes that a large random map itself may take up about 15GB, and the more players there are, the higher the memory and bandwidth requirements.

Below are starting recommendations better suited for buying a VPS; they are not performance guarantees:

7 Days to Die is sensitive to single-core performance, memory and disk latency. Don't just look at the "8 cores" label; heavily oversold cheap nodes easily stutter when generating maps, loading new chunks or during horde night. Before buying, you can first read Game Server VPS Specs and Network Route Selection.

This article uses SteamCMD + systemd because when you encounter version, port or save issues, you can directly see the official files and logs. If the same machine also runs Minecraft, Rust or Project Zomboid, you can then consider Pterodactyl Game Server Panel.

The default base port is 26900. The inbound ports currently listed in the official support FAQ are:

So the minimum firewall rules are 26900/tcp and 26900:26903/udp. Don't open all high ports just for convenience, and don't expose the Web Dashboard or Telnet to the entire internet.

If you change ServerPort, the related UDP ports will also shift with the base port. This article keeps 26900 to avoid the numbers being inconsistent across the server configuration, UFW and the cloud security group.

First update the system and install the basic components:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 ufw

Create a service account that cannot log in directly with a password:

sudo adduser --system --group --home /home/sdtd --shell /bin/bash sdtd
sudo install -d -o sdtd -g sdtd /opt/steamcmd
sudo install -d -o sdtd -g sdtd /opt/7dtd-server
sudo install -d -o sdtd -g sdtd /srv/7dtd-data
sudo install -d -m 750 -o root -g sdtd /var/backups/7dtd

Do not run the game as root. A dedicated account limits service permissions and also avoids SteamCMD updates producing root-owned files, which cause the next update or save to fail.

Switch to the sdtd user and download Valve's official SteamCMD:

sudo -iu sdtd
cd /opt/steamcmd
curl -fsSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \
  -o steamcmd_linux.tar.gz
tar -xzf steamcmd_linux.tar.gz
./steamcmd.sh +quit

Confirm the entry point is executable:

test -x /opt/steamcmd/steamcmd.sh

The Steam App ID for the 7 Days to Die Dedicated Server is 294420. Anonymous login is enough to download:

/opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 validate \
  +quit

The command has no -beta parameter, so it gets the current default stable branch. After installation, check the key files:

test -x /opt/7dtd-server/startserver.sh
test -f /opt/7dtd-server/serverconfig.xml
grep -n 'buildid' /opt/7dtd-server/steamapps/appmanifest_294420.acf
du -sh /opt/7dtd-server

Exit the service account:

exit

SteamCMD updates may overwrite the sample configuration in the install directory. First copy the file that ships with the current version to the data directory:

sudo -u sdtd cp /opt/7dtd-server/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml
sudo -u sdtd cp /srv/7dtd-data/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml.initial
sudo -u sdtd nano /srv/7dtd-data/serverconfig.xml

Only modify properties that already exist in the current file; do not overwrite the whole thing with an old tutorial. At minimum check these items:

<property name="ServerName" value="My 7 Days to Die Server"/>
<property name="ServerDescription" value="Private V3.1 survival server"/>
<property name="ServerWebsiteURL" value=""/>
<property name="ServerPassword" value="REPLACE_WITH_PLAYER_PASSWORD"/>
<property name="ServerLoginConfirmationText" value=""/>
<property name="Region" value="Asia"/>
<property name="Language" value="Chinese"/>
<property name="ServerPort" value="26900"/>
<property name="ServerVisibility" value="2"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="ServerReservedSlots" value="0"/>
<property name="ServerAdminSlots" value="1"/>
<property name="EACEnabled" value="true"/>
<property name="WebDashboardEnabled" value="true"/>
<property name="WebDashboardPort" value="8080"/>
<property name="TelnetEnabled" value="false"/>

Generate a dedicated player password:

openssl rand -base64 24

Replace the result into ServerPassword. This is the public password for joining the server, not a Steam password, and it should not be reused with SSH keys, panel accounts or admin passwords.

The configuration file also has network protocol, cross-platform, player profiles and sandbox options. Keep the current V3.1 defaults for now, and change them after the vanilla server can be joined stably. In particular, for ServerDisabledNetworkProtocols, do not copy a value from an old tutorial to overwrite the current configuration.

For the first deployment, it is recommended to use the official Navezgane world:

<property name="GameWorld" value="Navezgane"/>
<property name="GameName" value="MyV31World"/>
<property name="GameDifficulty" value="2"/>
<property name="DayNightLength" value="60"/>
<property name="DayLightLength" value="18"/>

This lets you first verify the version, ports, EAC and player login, separating network issues from random map generation issues.

After confirming Navezgane works, switch to a random map during a maintenance window. The random world properties in the V3.1 configuration file should follow the current sample; the common approach is to set the random world type, a unique seed and a 6144 size. During generation, CPU, memory and disk usage all rise noticeably, so don't do it while players are online.

GameName determines the save identifier. Don't change it casually after the server goes live, otherwise the server may look like "the save is lost" when in fact it just started another game directory.

Run it in the foreground first so you can directly see world generation, EAC, port and configuration errors:

sudo -u sdtd /opt/7dtd-server/startserver.sh \
  -configfile=/srv/7dtd-data/serverconfig.xml \
  -UserDataFolder=/srv/7dtd-data

The first start may take several minutes. Don't assume the server is up just because you see a Java/Unity process; wait for the log to show the game world has finished loading and is listening on the server port.

Create a Web Dashboard user in the console:

createwebuser

Follow the prompts to create a dedicated admin account and strong password. Then enter in the console:

saveworld
shutdown

Wait for the world to save and exit normally. Don't close SSH directly, and don't use kill -9. Check the data directory:

sudo -u sdtd find /srv/7dtd-data -maxdepth 3 -type f | sort | head -n 120
sudo du -sh /srv/7dtd-data

Create the service unit:

sudo nano /etc/systemd/system/7dtd.service

Write:

[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=/srv/7dtd-data/serverconfig.xml -UserDataFolder=/srv/7dtd-data
Restart=on-failure
RestartSec=20
KillSignal=SIGINT
TimeoutStopSec=300
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Load and start:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd
sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 250 --no-pager

LimitNOFILE=65535 is used to avoid triggering Linux's low open file limit with large worlds or many players. The official support FAQ has also specifically documented the issue of nofile=1024 causing the service to fail to start.

After stopping the service, confirm the process has exited before backing up:

sudo systemctl stop 7dtd
sudo systemctl status 7dtd --no-pager

If it still hasn't exited after 300 seconds, check the logs and disk space first; don't force-kill immediately. Forced termination may corrupt chunks or player data being written.

Keep the current SSH session open, allow SSH first, then add the game ports:

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

The cloud provider security group must also add the same rules. Check listening:

sudo ss -lntup | grep -E ':26900|:26901|:26902|:26903'

Don't add public rules for 8080/tcp or 8081/tcp. Access the Web Dashboard via an SSH tunnel, and keep Telnet closed.

On your own computer, run:

ssh -L 8080:127.0.0.1:8080 [email protected]

Keep the SSH session open, then open:

http://127.0.0.1:8080

Log in with the Web user created during the first foreground start. Because UFW and the cloud security group do not open 8080, public scanners cannot directly access this management entry point.

If local port 8080 is already in use, you can change it to local 18080:

ssh -L 18080:127.0.0.1:8080 [email protected]

Then visit http://127.0.0.1:18080.

Don't treat the public password for joining the server as a permission system. Admins should use their own Steam/EOS identity, and only give permissions to those who really need them.

Add an admin in the server console or the Web Dashboard protected by the SSH tunnel:

admin add STEAM64_ID 0

Add to the whitelist:

whitelist add STEAM64_ID

View the current list:

admin list
whitelist list
ban list

The specific identity format and command help may change with versions and network platforms; before executing, first enter help admin and help whitelist in the current V3.1 console. Don't directly copy serveradmin.xml from an unfamiliar server; it may contain wrong identities, old platform IDs or unnecessary high-privilege accounts.

First have one player connect directly using the public IP:

IP: 203.0.113.20
Port: 26900
Password: serverconfig.xml 中的 ServerPassword

Replace the example IP with the VPS's real address. After direct connection succeeds, then check the server list and cross-platform joining, so it is easier to distinguish list refresh, EOS/Steam and basic network issues.

A domain can create a normal A record pointing to the VPS IPv4, but Cloudflare's normal orange-cloud HTTP proxy cannot forward 7 Days to Die game ports and should be set to DNS only.

This article explicitly uses:

-UserDataFolder=/srv/7dtd-data

So worlds, players, logs and generated maps outside the configuration are all concentrated in /srv/7dtd-data. Subdirectories may change across versions and world types; don't guess paths from tutorials alone, confirm with the actual files first:

sudo -u sdtd find /srv/7dtd-data -maxdepth 4 -type f | sort | head -n 200
sudo du -h -d 3 /srv/7dtd-data | sort -h | tail -n 40

/opt/7dtd-server are program files that can be reinstalled via SteamCMD, while /srv/7dtd-data are the worlds, players, permissions, logs and generated maps that must not be lost.

Stop the server during a maintenance window and package the entire data directory:

sudo systemctl stop 7dtd
sudo tar -C /srv -czf \
  "/var/backups/7dtd/7dtd-data-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  7dtd-data
sudo systemctl start 7dtd
sudo systemctl is-active 7dtd

Check the archive:

sudo ls -lh /var/backups/7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120

Replace the example filename with the actual archive. Keep at least one copy on another machine or object storage, and set a retention period; keeping backups only on the same VPS disk means they are lost together if the machine fails. For a complete solution, see VPS Backup and Restore Drills.

Stop the server before restoring, and keep the current directory as a temporary fallback:

sudo systemctl stop 7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120
sudo mv /srv/7dtd-data \
  "/srv/7dtd-data.before-restore-$(date -u +%Y%m%dT%H%M%SZ)"
sudo tar -C /srv -xzf \
  /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz
sudo chown -R sdtd:sdtd /srv/7dtd-data
sudo systemctl start 7dtd

Verify after restoring:

sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 300 --no-pager
sudo du -sh /srv/7dtd-data

Have a test player join and check characters, inventory, bases, land claims, quests, map exploration and admin permissions. Don't delete 7dtd-data.before-restore-* before acceptance is complete; it is the fallback point for this drill.

Stop the server and back up before updating, then only update the default stable branch. Create the script:

sudo nano /usr/local/sbin/update-7dtd-server

Write:

#!/usr/bin/env bash
set -euo pipefail

backup_dir=/var/backups/7dtd
stamp=$(date -u +%Y%m%dT%H%M%SZ)
was_active=0

install -d -m 750 -o root -g sdtd "$backup_dir"

if systemctl is-active --quiet 7dtd; then
  was_active=1
  systemctl stop 7dtd
fi

restart_service() {
  if [ "$was_active" -eq 1 ]; then
    systemctl start 7dtd
  fi
}
trap restart_service EXIT

tar -C /srv -czf \
  "$backup_dir/7dtd-before-update-$stamp.tar.gz" \
  7dtd-data

sudo -u sdtd /opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 \
  +quit

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

Set permissions and run manually:

sudo chown root:root /usr/local/sbin/update-7dtd-server
sudo chmod 750 /usr/local/sbin/update-7dtd-server
sudo /usr/local/sbin/update-7dtd-server
sudo systemctl is-active 7dtd
sudo journalctl -u 7dtd -n 250 --no-pager

The script has no -beta latest_experimental, so it will not actively switch to the experimental branch. After a successful update, confirm the version, world loading and player joining in the logs; don't end maintenance just because SteamCMD returned success.

A vanilla private server can check for updates daily in a fixed window; modded servers and public servers are better off with manual maintenance, to avoid the server updating first while clients or mods haven't caught up.

Create a oneshot service:

sudo nano /etc/systemd/system/7dtd-update.service

[Unit]
Description=Update 7 Days to Die Dedicated Server

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/update-7dtd-server

Create a timer:

sudo nano /etc/systemd/system/7dtd-update.timer

[Unit]
Description=7 Days to Die daily maintenance window

[Timer]
OnCalendar=*-*-* 05:40:00
RandomizedDelaySec=10m
Persistent=true

[Install]
WantedBy=timers.target

Load and view:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd-update.timer
systemctl list-timers 7dtd-update.timer

When a large stable release comes out, the world is being converted, or mod compatibility is unclear, disable the timer first:

sudo systemctl disable --now 7dtd-update.timer

The official V3.1 announcement states that old saves can usually be upgraded, but also recommends backing up; the new day/night density and spawn options may also invalidate old sandbox preset codes. The safe process is:

1. Stop the old service and back up the entire user data directory.
2. Record the old server build, mod list and serverconfig.xml.
3. Copy the save to a separate directory; don't touch the only production world.
4. Disable third-party mods first, and load the copy with the current stable version.
5. Check custom sandbox presets, players, bases, chunks and quests.
6. Only after the copy passes acceptance, schedule the production switch.

Don't "fix" a version mismatch by deleting the save. If the server and client branches differ, unify the versions first; chunk corruption, invalid presets and mod conflicts need logs and backups to diagnose.

For stopping, full data archiving and restore checks on similar open-world servers, you can also refer to the Project Zomboid Dedicated Server Backup Process to build a fixed maintenance habit.

Get the vanilla V3.1 server running stably first, then add mods. Add only a few at a time, and record the source, version and configuration. A mod page saying "supports V3" does not mean it is already compatible with V3.1.

EACEnabled=true suits vanilla servers and servers that need anti-cheat. Some mods require disabling EAC, but this changes the security boundary. Only change it when the mod documentation explicitly requires it and all players understand the risk, and don't treat "disabling EAC" as a universal fix for any startup error.

Before updating mods, complete:

• Back up world and player data.
• Save the current mod files and version list.
• Test startup and joining on a copy of the world.
• Check the logs for XML, Harmony, EAC and network errors.
• Keep the previous version of files for quick rollback.

Record data during random map generation, horde night and multi-player scattered exploration:

free -h
df -h /opt/7dtd-server /srv/7dtd-data /var/backups/7dtd
uptime
ps -eo pid,%cpu,%mem,rss,etime,cmd | grep '[7]DaysToDieServer'
sudo journalctl -u 7dtd --since "30 minutes ago" --no-pager

Common phenomena:

• Memory and CPU stay high for a long time during map generation: wait for generation to finish first, don't restart frequently.
• Single core maxed out on horde night: reduce player count, enemy density, or switch to a VPS with stronger single-core performance.
• Stuttering when players explore separately: check disk latency, memory and new chunk loading.
• Saves getting bigger and bigger: leave space for local backups, off-site sync and restore extraction.
• Noticeable latency at evening peak: compare UDP packet loss and data center routes, don't just add memory.

• SteamCMD installed App ID 294420, without using experimental branch parameters.
• Both client and server are on the current V3.1 default public stable branch.
• The service uses a dedicated sdtd user and does not run as root.
• The configuration comes from the current version's bundled serverconfig.xml, without overwriting the whole thing with an old template.
• systemctl is-active 7dtd returns active.
• LimitNOFILE=65535 is in effect in systemd.
• 26900 TCP and 26900–26903 UDP are open in UFW and the security group.
• The Web Dashboard is only accessed via SSH tunnel, and Telnet is not exposed to the public internet.
• Players can join via public IP:26900, and server list issues are investigated separately.
• Admins use personal identities, and the highest-privilege account is not shared.
• /srv/7dtd-data has been fully backed up to another machine or object storage.
• A restore drill has been done and characters, bases, chunks and permissions checked.
• Before major version and mod updates, the server is stopped, backed up and a rollback copy kept.

• The Fun Pimps: V3.1.0 Henpocalypse stable release announcement
• The Fun Pimps: Support FAQ and dedicated server ports
• Valve Developer Community: 7 Days to Die Dedicated Server
• Valve Developer Community: SteamCMD

The place where a 7 Days to Die server really goes wrong is not SteamCMD, but the version branch, ports, random maps and backups. First get V3.1, 26900 TCP and 26900–26903 UDP working with the vanilla Navezgane world, then add random maps and mods, and troubleshooting will be much simpler.

For long-term operation, treat /srv/7dtd-data as the core asset: shut down normally before updates, back up completely, and actually restore once. That way, even if you encounter sandbox preset changes, mod conflicts or chunk corruption, you can return to a world confirmed to work, instead of gambling on your only save.