Don’t Starve Together dedicated server on Linux: shards, ports, token

What the cluster is made of

Klei calls the whole server a cluster and each world in it a shard. A cluster with caves is two server processes started from the same binary: one with -shard Master, one with -shard Caves. The Master shard is the only one with is_master = true in its server.ini; Klei requires exactly one master per cluster.

Klei's settings guide puts the shared settings in one file and the per-shard settings in another:

• cluster.ini: cluster name, password, max_players (default 16), game mode, and the [SHARD] block with shard_enabled, bind_ip, master_port and cluster_key.
• cluster_token.txt: the token from your Klei account. The server will not run without it.
• Master/server.ini and Caves/server.ini: is_master, the shard name, and each shard's own ports.
• Caves/worldgenoverride.lua: the world-generation preset that makes the second shard a cave world.

All of it lives in a folder per cluster under ~/.klei/DoNotStarveTogether/ of the account running the shards. Klei's own examples name the cluster MyDediServer.

Ports per shard, and which ones face the internet

Each shard listens for players on its own server_port; the master shard also listens for the other shards on master_port. The defaults below are from Klei's Dedicated Server Settings Guide.

Two shards on one machine cannot share a server_port, an authentication_port or a master_server_port: Klei says each must be different for each server on the same machine, and master_port must differ from every shard's server_port. Klei also notes that LAN players only see a server whose server_port is between 10998 and 11018 inclusive.

With both shards on one box, leave bind_ip = 127.0.0.1 and set master_ip = 127.0.0.1 for the Caves shard, as Klei's guide says. Shard traffic then never leaves the loopback, and the only ports the firewall needs to pass are the two server_port values over UDP. Read the real values with grep -h server_port ~/.klei/DoNotStarveTogether/MyDediServer/*/server.ini rather than assuming the defaults.

The cluster token is a credential

The token comes from the Klei Accounts site: Games tab, Don’t Starve Together, Game Servers, then Add New Server (or Configure on an existing one) and Download Settings. The zip holds the cluster folder with cluster_token.txt already in it. Klei marks expired servers in red on that page and says to delete them.

Klei's guides don’t cover protecting the token; this is our advice: treat the file like a password, because it authenticates the server against your Klei account. Keep it readable by the server user alone: chmod 700 ~/.klei, then chmod 600 on ~/.klei/DoNotStarveTogether/MyDediServer/cluster_token.txt.

If you keep the cluster folder in git to track cluster.ini and the mod overrides, put cluster_token.txt in .gitignore before the first commit. Our advice for a token that has been pushed somewhere public: add a new server on the Game Servers page, use its token, and delete the old entry there. The same goes for cluster_key, the shard password in cluster.ini.

Install and first start

Klei's Linux guide targets Ubuntu, 32- or 64-bit. On a 64-bit system it installs the 32-bit runtime libraries libstdc++6:i386, libgcc1:i386 and libcurl4-gnutls-dev:i386; on current Ubuntu and Debian releases the GCC runtime package is called libgcc-s1, and Valve's SteamCMD page installs lib32gcc-s1 for the same reason. SteamCMD itself comes from the multiverse repository on Ubuntu, and Valve warns against running it as root.

1. Install the libraries and SteamCMD, create the steam user and fetch app 343050 into /home/steam/dst (first block below). Valve recommends setting force_install_dir before login.
2. Download the settings zip from your Klei account and unpack it into /home/steam/.klei/DoNotStarveTogether/ as the steam user, so the path ends in MyDediServer/cluster.ini.
3. Edit cluster.ini: cluster_name, cluster_password, max_players, game_mode. Lock the token as shown above.
4. Save the start script below as /home/steam/run_dst.sh and run chmod u+x on it. It updates the server, then starts Caves in the background and Master in the foreground.
5. Run it once by hand as steam and wait for both shards to report ready in the log before inviting anyone.

sudo dpkg --add-architecture i386
sudo add-apt-repository multiverse
sudo apt update
sudo apt install steamcmd libstdc++6:i386 libgcc-s1:i386 libcurl4-gnutls-dev:i386
sudo useradd -m steam
sudo -u steam /usr/games/steamcmd +force_install_dir /home/steam/dst \
  +login anonymous +app_update 343050 validate +quit

#!/bin/bash
# Two shards, one cluster: the pattern in Klei's run_dedicated_servers.sh
steamcmd=/usr/games/steamcmd
install_dir=/home/steam/dst
cluster=MyDediServer

$steamcmd +force_install_dir "$install_dir" +login anonymous \
  +app_update 343050 +quit

cd "$install_dir/bin64" || exit 1
run=(./dontstarve_dedicated_server_nullrenderer_x64 -console
     -cluster "$cluster" -monitor_parent_process $$)

"${run[@]}" -shard Caves  | sed 's/^/Caves:  /' &
"${run[@]}" -shard Master | sed 's/^/Master: /'

The script follows the shape of the run_dedicated_servers.sh that Klei's guide links. -monitor_parent_process $$ makes each shard exit when the script does. Klei's original runs app_update with validate on every start; this one leaves it out, for the reason in the mods section.

The 32-bit and the 64-bit binary

Klei's 2016 Linux guide was written for the original 32-bit binary, dontstarve_dedicated_server_nullrenderer in bin/, and its i386 package list is for that build. The run_dedicated_servers.sh the guide links to now runs dontstarve_dedicated_server_nullrenderer_x64 from bin64/, and Klei's Windows guide (last edited August 2021) runs the same _x64 binary from bin64/ with the same arguments. The script on this page follows the current one.

A cannot open shared object file error at start is a missing library; ldd on the binary lists which one. That step is our advice, not Klei's.

Mods, updates and the validate flag

Server mods are listed in mods/dedicated_server_mods_setup.lua inside the install directory. Valve's SteamCMD documentation says validate overwrites any installed file that has been changed and recommends it only for the first install or when something is broken. Run it on every start and it puts that file back to the shipped default, which is why the mod list keeps disappearing for people who copy the stock script.

Keep validate for the first install and for repairs. A plain app_update 343050 on each start is enough to pick up a new build, and the script above does that before the shards launch.

Running it as a service, and backups

A systemd unit keeps the cluster up across reboots and starts it again whenever the script exits. Enable it with systemctl daemon-reload and systemctl enable --now dst, and read the shard logs with journalctl -u dst -f.

# /etc/systemd/system/dst.service
[Unit]
Description=Don't Starve Together cluster (Master + Caves)
After=network-online.target
Wants=network-online.target

[Service]
User=steam
WorkingDirectory=/home/steam
ExecStart=/home/steam/run_dst.sh
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

• Saves: Klei's autosave runs at the end of each in-game day and max_snapshots (default 6) sets how many rollback points are kept. The cleanest off-box copy of the cluster folder is one taken with the service stopped.
• Console: with console_enabled = true (the default) the shards read Lua commands such as c_save() from the terminal they run in. Run the script by hand when you need it; under systemd there is no terminal attached.
• Updates: a systemctl restart dst runs app_update before the shards start.

Which machine to run it on

Klei's guides publish no CPU or memory figure for the dedicated server, and this page does not guess one. What is known: a caves cluster is two processes, both on one host by default, and Klei's Linux guide is written for x86 Ubuntu. That rules out our ARM lines and leaves the rest of the dedicated range. Start small, watch top with a full lobby, and move up a line if a shard pins a core.

The game server line is whole bare metal boxes on HPE enterprise hardware, configured to the spec you choose, in New York, Miami, San Francisco, Amsterdam or Bucharest. Each comes with root, one IPv4 and an unmetered port on our own network, AS19624. Pick the city nearest the players. Linux images install from the dashboard; a racked machine is live about 30 minutes after the order is approved, a build to order takes 4-24 hours. Rack servers and blades also carry an out-of-band console (iLO, iDRAC or BMC), so a bad firewall rule is undone from the console rather than through a ticket.