7 Days to Die just had its biggest update since launch. V3.0 “Dead Hot Summer” went stable on June 29, 2026, landing simultaneously on Steam, Xbox Series X|S, and PlayStation 5 with crossplay enabled from day one — over 60 new points of interest, a new item Magnitude system, and 150 sandbox customization options. The game is still pulling roughly 24,000 concurrent players on Steam and peaked at more than 124,000 during its 1.0 launch window, according to Steam Charts tracking, which means public server browsers are more crowded than ever. If you want a world that survives a restart, isn’t full of strangers raiding your base, and can now include your friends on console, running your own 7 Days to Die dedicated server is the answer.

This tutorial walks through a complete, from-scratch 7 Days to Die dedicated server setup on Linux (with Windows commands alongside every step), covers the exact serverconfig.xml and serveradmin.xml settings that matter, shows how to meet V3.0’s crossplay requirements for Xbox and PS5 players, and — because this is a security-focused publication — spends real time on hardening the box so a public game port doesn’t turn into an open door to your server. Expect about 30 minutes of hands-on work across 13 steps.

Why Self-Host in V3.0 “Dead Hot Summer”

Public 7 Days to Die servers come with the usual problems: griefers raiding your base while you’re offline, admins who wipe the world without notice, and zero control over difficulty, loot, or mods. A self-hosted 7 Days to Die dedicated server fixes all three — you set the rules, you own the save file, and the world keeps running on its own hardware even when every player has logged off for the night.

V3.0 changes the calculus in one more way. Before this update, crossplay between PC and console was inconsistent; now a correctly configured dedicated server can host PlayStation 5 and Xbox Series X|S players alongside Steam players on the same map, according to the official V3.0 release notes. That’s a meaningful reason to move off a rented public slot and onto infrastructure you control — Step 12 below covers exactly what your config needs for it to work.

7 Days to Die itself has been in active development since its 2013 Kickstarter debut and left Early Access with its 1.0 release in July 2024, according to the game’s Wikipedia entry, which makes V3.0 the largest post-launch content update the game has received. That long, still-active development cycle is itself a reason to self-host: a dedicated server you control isn’t at the mercy of a hosting company’s renewal pricing or slot availability every time a major update reshapes the game, and it’s the only way to guarantee your world, your mods (or lack of them), and your rules survive from one patch to the next.

What You Need Before You Start (Prerequisites)

You don’t need to own 7 Days to Die to run its dedicated server — the server tool is a separate, free Steam application. Here’s everything to have ready before Step 1:

  • A Linux VPS, home server, or spare PC running Ubuntu 22.04 LTS or 24.04 LTS (Windows Server or Windows 10/11 also works — commands are noted throughout)
  • SteamCMD (Valve’s command-line installer — Step 3 covers installing it)
  • At least 15 GB of free SSD storage and 8 GB of RAM as a comfortable baseline (full sizing table in Step 2)
  • Root or sudo access to configure the firewall
  • Basic command-line comfort — every command in this guide is copy-pasteable
  • 7 Days to Die V3.0 installed on the client machines that will connect (Steam app 251570, or the Xbox/PlayStation store version)

Step 1: Choose Self-Hosted or Managed Hosting

Before touching a terminal, decide where this server actually lives. Self-hosting on a home PC or a cheap Linux VPS costs nothing beyond hardware and electricity, and gives you full root access to the file system, firewall, and telnet console. The tradeoff is uptime and bandwidth: if your home connection drops or your PC reboots for a Windows update, the world goes down with it.

Managed game-hosting providers remove that risk — they run the box, the network, and the DDoS protection, and usually give you a control panel instead of raw shell access. That convenience costs somewhere between $10 and $30 a month for a 4-8 player 7 Days to Die slot, scaling with RAM. This tutorial focuses on the self-hosted path because it’s the one that teaches you what’s actually happening under the hood, and because every setting covered here also applies if you later switch to a VPS you rent yourself.

Step 2: Check Hardware and Software Requirements

The Fun Pimps hasn’t published official minimum specs for the dedicated server tool, so the numbers below reflect community-tested consensus across hosting providers and the 7 Days to Die wiki community rather than a vendor spec sheet. The one hard rule everyone agrees on: 7 Days to Die’s server engine is single-thread bound. AI pathfinding, chunk loading, and blood-moon horde simulation lean on one core far more than they spread across many, so clock speed matters more than core count.

PlayersRAMCPUDisk
1-4, vanilla4-6 GBDual-core, 3.0 GHz+10-15 GB SSD
4-8, vanilla8 GBQuad-core, 3.2 GHz+15-20 GB SSD
8-16, vanilla12-16 GBQuad-core, 3.5 GHz+ (high clock)20-25 GB SSD
16+ or modded16-32 GB6+ cores, high single-thread clock25-40 GB SSD

On the software side you need a 64-bit Linux distribution (this guide uses Ubuntu) or Windows Server/10/11, plus SteamCMD. NVMe or SATA SSD storage is strongly recommended over spinning disks — world-region generation and loading are I/O-heavy, especially with large Random World Generation (RWG) maps.

Step 3: Install SteamCMD

SteamCMD is Valve’s official command-line tool for downloading dedicated server files, documented on the Valve Developer Community wiki. On Ubuntu, enable the multiverse repository first, then install the 32-bit compatibility libraries SteamCMD needs even on a 64-bit host:

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

On first run, accept the Steam license when prompted, then let SteamCMD update itself and drop to its Steam> prompt:

steamcmd

Type quit once it settles at the prompt — you’ve confirmed it works, and the next step will call it non-interactively.

Step 4: Download the Dedicated Server (App ID 294420)

This is the detail that trips up a lot of first-time hosts: the 7 Days to Die dedicated server tool is Steam app 294420, a completely separate download from the game client itself (app 251570). Unlike some survival games, you don’t need to own 7 Days to Die or log into a personal account to download it — anonymous SteamCMD login works fine for the server tool, confirmed on the Steam store listing for app 294420.

Create a dedicated directory and pull the files down. This single command line handles login, platform targeting, and the download in one shot:

mkdir -p ~/7dtd-server
steamcmd +@sSteamCmdForcePlatformType linux +force_install_dir ~/7dtd-server +login anonymous +app_update 294420 validate +quit

Expect this to pull down 10-15 GB. When it finishes, SteamCMD prints a standard success line you can grep for in scripts:

Success! App '294420' fully installed.

On Windows, the same install runs through the SteamCMD executable instead of the shell command: run steamcmd.exe +force_install_dir C:\7dtd-server +login anonymous +app_update 294420 validate +quit from Command Prompt or PowerShell.

Step 5: Learn the Server Directory Structure

Before editing anything, look at what SteamCMD just installed. The layout matters because the two config files you’ll touch most — serverconfig.xml and serveradmin.xml — sit at the install root, while saves and logs live elsewhere:

cd ~/7dtd-server
ls -la
# 7DaysToDieServer.x86_64   startserver.sh   serverconfig.xml
# serveradmin.xml           Data/  Mods/     LocalStorage/
  • 7DaysToDieServer.x86_64 — the Linux server binary (a Windows install has 7DaysToDieServer.exe and startdedicated.bat instead)
  • startserver.sh — the launch script; edit this or pass flags directly on the command line
  • serverconfig.xml — the main settings file covered in Step 6
  • serveradmin.xml — permissions, whitelist, and ban list covered in Step 8
  • Mods/ — drop mod folders here (see the mod-installation section below)
  • LocalStorage/Saves/ — where your world and player data actually live once the server has run at least once; this is the directory to back up

Step 6: Configure serverconfig.xml

Open serverconfig.xml in any text editor (nano serverconfig.xml works fine over SSH). It’s a flat XML file of <property> tags — no nesting, no surprises. The reference copy maintained in the open-source GameServerManagers config library matches what ships with app 294420 and is a reliable cross-check if your file ever looks different after an update.

Core settings

These four you should change before first launch — everything else has a sane default:

<property name="ServerName" value="My 7 Days to Die Server"/>
<property name="ServerPassword" value=""/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="ServerVisibility" value="2"/>  <!-- 2=public, 1=friends-only, 0=unlisted -->

World and difficulty settings

GameDifficulty runs 0 (easiest) through 5 (hardest); DayNightLength and DayLightLength set how many real-world minutes a full day-night cycle takes and how many of those hours are daylight. BloodMoonEnemyCount controls how many zombies spawn per player during the seventh-night horde — the setting most responsible for late-game server load.

Network and admin interfaces

TelnetEnabled, TelnetPort, and ControlPanelEnabled/ControlPanelPort control the two remote-admin surfaces the server exposes. Leave them enabled for now — Step 13 covers locking them down properly rather than leaving them wide open, which is one of the most common mistakes in self-hosted game servers generally.

SettingDefaultWhat it controls
ServerPort26900Main game connection port
ServerVisibility2Server-browser listing: 2=public, 1=friends, 0=unlisted
ServerMaxPlayerCount8Concurrent player cap
GameDifficulty20 (easiest) to 5 (hardest)
EACEnabledtrueEasyAntiCheat — must be false for DLL mods
ServerDisabledNetworkProtocolsSteamNetworkingLeave LiteNetLib active for crossplay to work
BloodMoonEnemyCount8Zombies spawned per player on horde night
MaxSpawnedZombies60Hard cap — above ~80 risks frame-rate and lag
TelnetEnabled / TelnetPorttrue / 8081Remote console — restrict to localhost/VPN

Step 7: Pick Your World — Navezgane or Random Gen

The GameWorld property decides your map. Set it to Navezgane to use the game’s fixed, hand-crafted map — the safest choice for a first server, since it’s the same layout every 7 Days to Die player has explored in singleplayer and it generates instantly. Set it to any other name and the server treats it as a Random World Generation (RWG) map, building a brand-new procedural world from WorldGenSeed and WorldGenSize:

<property name="GameWorld" value="MyRandomMap"/>
<property name="WorldGenSeed" value="shattered2026"/>
<property name="WorldGenSize" value="6144"/>  <!-- 2048-16384, larger = longer generation time -->

RWG generation happens once, on first launch, and can take anywhere from a few minutes at 4096 up to well over an hour at the maximum 16384 size on modest hardware. If you’re testing your setup, generate a small map first (4096-6144) and only commit to a large one once you know the rest of your configuration works — regenerating a 16384 map because of an unrelated typo in serverconfig.xml is a real time sink.

Step 8: Configure serveradmin.xml Permissions

serveradmin.xml is where you control who can run admin commands, who’s whitelisted, and who’s banned — separate from serverconfig.xml entirely. Permission levels run 0 to 1000: 0 is Super Admin with access to every command, 1000 is the default level every unlisted player gets automatically, and anything in between is yours to define.

LevelRoleAccess
0Super Admin (you)Every command, including ones not explicitly listed
1-99Senior adminCustom-restricted admin command set
100-999Moderator / trusted playerWhatever commands you explicitly grant at that tier
1000Default (everyone else)Only commands explicitly opened to level 1000

The important security detail here: any command not listed in the file defaults to permission level 0, meaning it’s locked to Super Admins only unless you deliberately open it up. That’s a secure-by-default design — new or obscure commands don’t accidentally become available to every player. Add yourself as Super Admin using your SteamID64 (look it up at steamid.io if you don’t have it memorized):

<adminslist>
  <admin permission_level="0" steamid="76561198012345678" name="YourName"/>
</adminslist>

<whitelist>
  <player steamid="76561198012345678"/>
</whitelist>

Whitelisting is optional but worth turning on for any server you’re not advertising publicly — combined with ServerVisibility set to 0 or 1, it keeps random internet traffic off a box that’s otherwise reachable the moment you forward a port.

Step 9: Open the Required Firewall Ports

Four ports matter, and only two of them should ever be reachable from the public internet. If you’re behind a home router, forward the same ports there in addition to the host firewall rules below.

PortProtocolPurposeExpose publicly?
26900TCP + UDPPrimary game connectionYes
26901-26903UDPGame data channelsYes
8080TCPWeb control panel / live mapNo — localhost or VPN only
8081TCPTelnet remote admin consoleNo — localhost or VPN only

On Ubuntu with UFW, open only the two ports that need to face the internet:

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

Deliberately leave 8080 and 8081 off that list. You’ll still be able to reach them from the server itself or over a VPN — see Step 13 for exactly how.

Step 10: Start the Server for the First Time

On Linux, launch through the bundled script, pointing it at your config file:

cd ~/7dtd-server
chmod +x startserver.sh 7DaysToDieServer.x86_64
./startserver.sh -configfile=serverconfig.xml

On Windows, either double-click startdedicated.bat in the install folder or run the executable directly with the same flags used under the hood:

7DaysToDieServer.exe -quit -batchmode -nographics -configfile=serverconfig.xml -dedicated

First launch takes longer than every launch after it — the server has to generate or load the world, cache assets, and open its listeners. On a fixed Navezgane map this is usually under a minute; on a fresh RWG map it can take considerably longer depending on WorldGenSize. The console keeps scrolling with loading and region-generation messages the whole time; it’s done when the log settles and stops producing new lines, at which point the server is listening on the port you configured and ready for connections.

Step 11: Connect From the Game Client and Verify

From the 7 Days to Die main menu, choose Join Game, then either browse the public server list (if ServerVisibility is 2) or connect directly by typing your server’s IP address and port in the format IP:26900. If you’re testing from the same machine the server runs on, 127.0.0.1:26900 works without touching your router at all.

If the connection hangs instead of loading straight in, it’s almost always one of two things: the firewall rule from Step 9 didn’t actually apply (re-check ufw status), or your router’s port forward is pointing at the wrong local IP. Both are covered in the troubleshooting table further down.

Step 12: Turn On Crossplay for Xbox Series X|S and PS5

This is new territory for a self-hosted 7 Days to Die dedicated server. Since V3.0, a PC server can host PlayStation 5 and Xbox Series X|S players on the same map as Steam players — but only current-generation consoles; PS4 and Xbox One are not supported, per the game’s own V3.0 release notes and corroborating hosting-provider crossplay documentation. Crossplay comes with a specific, non-negotiable checklist — miss any one item and console players simply won’t see your server.

Requirementserverconfig.xml settingRequired value
No mods installedMods/ folderEmpty
Anti-cheat activeEACEnabledtrue
Public visibilityServerVisibility2
Cross-platform networkingServerDisabledNetworkProtocolsMust not include LiteNetLib
Player capServerMaxPlayerCount8 or fewer
Map sizeWorldGenSize8192 or smaller
Explicit crossplay flagServerAllowCrossplaytrue

The good news is that a fresh install’s defaults already satisfy most of this — the stock serverconfig.xml disables SteamNetworking rather than LiteNetLib, so cross-platform connectivity is on by default. The two things you’re most likely to actively break crossplay with are dropping a mod into the Mods/ folder or pushing ServerMaxPlayerCount above 8 to fit more Steam friends in — both instantly lock console players out, even though the server keeps running fine for everyone on PC.

Step 13: Harden the Server Like a Production Service

A dedicated server is a public-facing network service the moment you forward a port to it, and it deserves the same basic hardening any internet-facing service gets. None of this is 7 Days to Die-specific wisdom — it’s standard practice this site covers across every self-hosted game server, from ARK to FiveM — but it’s the step most tutorials skip entirely.

Run as a non-root user

Never run a game server as root. Create a dedicated, unprivileged account and own the install directory with it:

sudo useradd -m -s /bin/bash 7dtd
sudo chown -R 7dtd:7dtd ~/7dtd-server
sudo -u 7dtd ./startserver.sh -configfile=serverconfig.xml

If the server process is ever compromised through a game-engine vulnerability or a malicious mod, this limits what an attacker can touch to that one account instead of the whole machine.

Keep telnet and the web dashboard off the public internet

You already left ports 8080 and 8081 out of the firewall rules in Step 9 — that’s the right call, but you still need a way to reach them yourself. Rather than opening them up, tunnel in over a mesh VPN. This site has a full Tailscale vs WireGuard comparison if you want to pick between them, but either one lets you reach localhost:8080 and localhost:8081 from your laptop without ever putting those ports on the public internet. Also set a real TelnetPassword and ControlPanelPassword instead of leaving them blank — an empty TelnetPassword does restrict telnet to the local loopback interface by design, but that protection disappears the instant you forward the port or use a VPN that bridges the network.

Run it as a systemd service

A bare terminal process dies when your SSH session drops. A systemd unit restarts automatically on crash, starts on boot, and gives you normal service management:

sudo tee /etc/systemd/system/7dtd.service << 'EOF'
[Unit]
Description=7 Days to Die Dedicated Server
After=network.target

[Service]
Type=simple
User=7dtd
WorkingDirectory=/home/7dtd/7dtd-server
ExecStart=/home/7dtd/7dtd-server/startserver.sh -configfile=serverconfig.xml
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target
EOF

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

From here, sudo systemctl restart 7dtd and journalctl -u 7dtd -f replace manually re-launching the process and hunting for a log file.

What Else Changed for Multiplayer in V3.0

Crossplay is the headline change, but two other V3.0 systems directly affect how your server behaves once players are actually inside it. The update adds more than 60 new points of interest, including the Tier 5 “Champions Coliseum,” which means a world generated before V3.0 won’t contain them — if you want the new POIs, generate a fresh RWG world or start a new Navezgane save rather than continuing an old one, according to the V3.0 patch breakdown on the 7 Days to Die community wiki.

The new item Magnitude system also changes loot economy on a shared server more than it does in singleplayer. Weapons, tools, and workstation mods can now roll boosted-stat “Magnitude” variants, marked with orange stars — on an 8-player server running LootAbundance above the default 100%, that stacks with the new variant system in ways a solo player never sees, so it’s worth testing loot settings on a small group before committing to a permanent world. V3.0 also ships 150 sandbox customization options in total, covering everything from zombie characteristics to in-game economy tuning — most of these live inside the game’s own in-session settings menu rather than serverconfig.xml, but they’re worth exploring alongside the config changes covered in this guide once your server is stable.

Installing Mods Safely (and Why EAC Blocks Them)

Mods drop into the Mods/ folder as subfolders — popular options like Darkness Falls and Undead Legacy ship as a single folder you copy in and restart the server to load. The catch is EasyAntiCheat: DLL-based mods get blocked by EAC by default, and players attempting to join get kicked on connect until you set EACEnabled to false in serverconfig.xml.

That single setting change is also why mods and crossplay are mutually exclusive on the same server, as noted in Step 12 — EAC and the mod-free requirement both have to hold simultaneously for console players to connect. Decide up front whether this server is a modded PC-only box or a vanilla crossplay box; trying to be both at once just means constantly flipping EACEnabled and locking different groups of players out each time.

Automating Backups and Updates

Your world lives in LocalStorage/Saves/. Back it up before every update and on a schedule — a simple cron job handles both:

#!/bin/bash
# backup-7dtd.sh
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=~/7dtd-backups
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/save-$TIMESTAMP.tar.gz" -C ~/7dtd-server/LocalStorage Saves
find "$BACKUP_DIR" -name "save-*.tar.gz" -mtime +7 -delete
chmod +x backup-7dtd.sh
crontab -e
# add: 0 */6 * * * /home/7dtd/backup-7dtd.sh

Updating uses the exact same SteamCMD command from Step 4 — run it again against the same install directory and it patches in place. Always run a manual backup first, and always stop the server cleanly (systemd’s stop, not a hard kill) before updating so an in-progress autosave doesn’t corrupt:

sudo systemctl stop 7dtd
~/backup-7dtd.sh
steamcmd +@sSteamCmdForcePlatformType linux +force_install_dir ~/7dtd-server +login anonymous +app_update 294420 validate +quit
sudo systemctl start 7dtd

Performance Tuning for Blood Moons and Large Bases

Blood moon hordes are where under-provisioned servers fall over. BloodMoonEnemyCount multiplies by player count, so an 8-player server at the default value of 8 can spawn dozens of zombies simultaneously converging on scattered bases. MaxSpawnedZombies is the hard ceiling — the config file’s own comment warns that pushing it much past 80 risks frame-rate and lag for every connected client, not just the server console.

If horde nights are consistently dropping your tick rate, lower BloodMoonEnemyCount before you throw more RAM at the problem — RAM headroom matters, but a CPU running flat-out on a single core will bottleneck a horde night regardless of how much memory is free. MaxSpawnedAnimals is a separate, lighter-weight cap since wildlife costs less CPU than zombie AI, and is safe to raise on servers with players spread across a large RWG map.

Your Complete, Working serverconfig.xml

Putting every setting from Steps 6 through 12 together, here’s a complete, ready-to-run configuration for a hardened, crossplay-eligible 8-player server on a fixed Navezgane map:

<?xml version="1.0"?>
<ServerSettings>
  <property name="ServerPort" value="26900"/>
  <property name="ServerVisibility" value="2"/>
  <property name="ServerName" value="My 7 Days to Die Server"/>
  <property name="ServerPassword" value=""/>
  <property name="ServerMaxPlayerCount" value="8"/>
  <property name="ServerDisabledNetworkProtocols" value="SteamNetworking"/>
  <property name="ServerAllowCrossplay" value="true"/>

  <property name="GameWorld" value="Navezgane"/>
  <property name="GameName" value="MyGame"/>
  <property name="GameDifficulty" value="2"/>
  <property name="BloodMoonEnemyCount" value="8"/>
  <property name="MaxSpawnedZombies" value="60"/>
  <property name="MaxSpawnedAnimals" value="50"/>

  <property name="EACEnabled" value="true"/>
  <property name="ControlPanelEnabled" value="true"/>
  <property name="ControlPanelPort" value="8080"/>
  <property name="ControlPanelPassword" value="CHANGE_THIS_PASSWORD"/>
  <property name="TelnetEnabled" value="true"/>
  <property name="TelnetPort" value="8081"/>
  <property name="TelnetPassword" value="CHANGE_THIS_PASSWORD"/>
</ServerSettings>

Pair that file with the 7dtd.service systemd unit from Step 13, the UFW rules from Step 9, and the cron backup from the section above, and you have a complete, self-updating, self-restarting 7 Days to Die dedicated server that survives reboots, backs itself up every six hours, and doesn’t expose anything but the game port to the internet.

Common Pitfalls

Leaving admin ports open to the world

Forwarding 8080 or 8081 on your router “just to be safe” turns your telnet console and web dashboard into a target. Neither needs to be internet-facing — use a VPN, as covered in Step 13.

Running the process as root

It’s the fastest way to get a server running and the worst habit to carry into any other self-hosted service. Create the dedicated user from Step 13 before your first real launch, not after.

Mixing mods and crossplay expectations

Adding a single mod silently locks out every console player, even with everything else configured correctly. If console friends are part of the plan, keep the Mods/ folder empty.

Generating a 16384 RWG map on modest hardware

Maximum-size Random World Generation can run well over an hour and hammer the CPU the entire time. Test your configuration on a small map first, and only generate the final large world once you’re confident nothing else needs changing.

Updating without stopping the server first

Running app_update against a live install while the server process still has files open is how saves get corrupted. Stop the service, back up, update, restart — in that order, every time.

Buying more cores instead of higher clock speed

Because the server engine is single-thread bound, a cheap 8-core budget CPU at 2.4 GHz will choke on a blood moon that a 4-core CPU at 4.0 GHz handles comfortably. Prioritize clock speed when picking hardware or a VPS plan.

Troubleshooting Guide

SymptomLikely causeFix
Server not visible in the public browserServerVisibility set to 0 or 1, or port 26900 not forwardedSet ServerVisibility to 2; confirm port forwarding and UFW rules
Friends can connect by IP but not through the browserUDP ports blocked, or NAT/router misconfigurationOpen UDP 26900-26903; verify your public IP matches what players are entering
“Kicked by EAC” on a modded serverEACEnabled still true with mods installedSet EACEnabled to false whenever the Mods/ folder is not empty
Console (Xbox/PS5) players can’t find the serverCrossplay requirements not fully metRe-check the crossplay table in Step 12 — mods, player cap, and visibility are the usual culprits
Server stutters or crashes during blood moonsMaxSpawnedZombies/BloodMoonEnemyCount too high for the CPULower both values; prioritize CPU clock speed over core count
Telnet connection refusedTelnetPassword is blank, restricting it to localhost onlySet a real TelnetPassword, or connect from the host itself / over your VPN
SteamCMD download stalls or errors outDisk full, or a rate-limited anonymous loginFree up disk space and re-run the app_update command; avoid running multiple installs in parallel
RWG world generation seems frozenWorldGenSize too large for available CPU/RAMBe patient on large maps, or regenerate at a smaller size (4096-6144) for testing
Save appears corrupted after a crashNo recent backup, or the process was force-killed mid-writeRestore from your latest cron backup; always stop the server gracefully via systemctl, not kill -9
A player’s admin commands don’t workTheir SteamID64 isn’t in serveradmin.xml, or it’s set at the wrong permission levelAdd or correct their entry in the adminslist section

Advanced Tips for Power Users

Once the base setup is stable, a few extra moves are worth the time:

  • Script telnet for automation. Telnet accepts the same admin commands you’d type in-game — a scheduled echo "say Server restarting in 5 minutes" | nc localhost 8081 style call (with a real password piped in first) can drive warning messages before a scripted restart.
  • Consider LinuxGSM instead of a raw SteamCMD install. The community LinuxGSM project wraps steps 3, 4, 10, and the update process from this guide into a single management script, if you’d rather not hand-roll your own systemd unit and backup cron. PiMyLifeUp’s Linux server walkthrough is a solid second reference if you want to cross-check any step against an independent source.
  • Separate your web dashboard from your telnet console on the VPN. If multiple admins need dashboard access but only you need telnet, put them on different VPN access-control rules rather than sharing one tunnel with full access to both.
  • Watch RAM headroom, not just usage. A server sitting at 90% memory utilization with no swap configured is one bad chunk-loading spike away from an OOM kill mid-session — leave real headroom rather than sizing RAM to exactly what’s “normally” used.
  • Keep a pre-update backup separate from your rolling six-hour backups. The cron job in this guide prunes anything older than seven days; a manual, permanently-kept backup taken right before a major version jump (like V2.6 to V3.0) gives you a clean rollback point the rotation won’t delete out from under you.

Frequently Asked Questions

What is the Steam app ID for the 7 Days to Die dedicated server?

294420. It’s a free, standalone download separate from the 7 Days to Die game client, which is app 251570.

Is the 7 Days to Die server tool free to download?

Yes. SteamCMD downloads app 294420 with an anonymous login — you don’t need to own the game or log into a personal Steam account to host a server for it.

How many players can a 7 Days to Die server support?

ServerMaxPlayerCount can technically be set well above 8, but crossplay with Xbox and PlayStation 5 caps out at 8 players by platform requirement. Vanilla PC-only servers with strong hardware can comfortably run larger player counts.

Can Xbox and PS5 players join a self-hosted PC dedicated server?

Yes, as of V3.0 “Dead Hot Summer” — but only current-generation consoles (PS4 and Xbox One are not supported), and only if the server is unmodded, EAC-enabled, publicly visible, capped at 8 players, and running a map of 8192 or smaller. See the full checklist in Step 12.

Do I need to disable EasyAntiCheat to run mods?

Yes, for DLL-based mods. Leaving EACEnabled set to true on a modded server gets players kicked on connect. Setting it to false also disqualifies the server from crossplay, so decide up front whether a given server is modded-PC or vanilla-crossplay.

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

There’s no official spec from the developer, but community testing consistently lands on 4-6 GB as a workable minimum for 1-4 players, 8 GB as a comfortable baseline for a full 8-player vanilla server, and 12 GB or more once mods or larger player counts enter the picture.

Can I run the server on Windows instead of Linux?

Yes. SteamCMD, serverconfig.xml, and serveradmin.xml all work identically on Windows — only the launch method changes, from startserver.sh on Linux to startdedicated.bat or a direct 7DaysToDieServer.exe command on Windows.

How do I safely update the server without losing my world?

Stop the server cleanly, run a manual backup of the LocalStorage/Saves folder, re-run the same SteamCMD app_update 294420 command used for the initial install, then restart. Never update while the server process is still running.

More self-hosted game-server tutorials and gaming coverage from shattered.io:

For the full archive of gaming hardware, platform, and server coverage, visit the gaming category on shattered.io.