Don't Starve Together dedicated servers: clusters and shards

Make one cluster folder, put cluster.ini and cluster_token.txt in it, add a Master folder and a Caves folder with a server.ini each, and start the dedicated server twice: once with -shard Master and once with -shard Caves. The forest and the caves run as two separate processes, and they find each other through the [SHARD] section of cluster.ini.

If you only want to play on someone else's world, installing the game and joining a server is the guide you need.

The cluster folder

A two-shard cluster looks like this:

MyDediServer/
├── cluster.ini
├── cluster_token.txt
├── Master/
│   ├── server.ini
│   ├── worldgenoverride.lua
│   └── modoverrides.lua
└── Caves/
    ├── server.ini
    ├── worldgenoverride.lua
    └── modoverrides.lua

The server builds each shard's path from four launch options joined in order: -persistent_storage_root, -conf_dir (which defaults to DoNotStarveTogether), -cluster and -shard. Klei's own Linux start script expects the cluster at ~/.klei/DoNotStarveTogether/MyDediServer. The admin, whitelist and block lists (adminlist.txt, whitelist.txt, blocklist.txt) sit next to cluster.ini.

The cluster token

The token ties the server to your Klei account. Sign in to Klei's accounts site, open the servers page for Don't Starve Together, add a server with a name, and copy the token it shows into cluster_token.txt. You can also generate one in the game client's console with TheNet:GenerateClusterToken(), which writes cluster_token.txt into the client's DoNotStarveTogether folder. Treat the file like a password.

cluster.ini: what both shards share

[GAMEPLAY]
game_mode = survival
max_players = 6
pvp = false
pause_when_empty = true

[NETWORK]
cluster_name = Your server name
cluster_description = One line about it
cluster_password =
cluster_intention = cooperative

[MISC]
console_enabled = true
max_snapshots = 6

[SHARD]
shard_enabled = true
bind_ip = 127.0.0.1
master_ip = 127.0.0.1
master_port = 10888
cluster_key = pick-a-long-random-string

The [SHARD] block is what makes this a cluster. shard_enabled has to be true for more than one shard. bind_ip is the address the master listens on for other shards, and master_ip is where the Caves shard looks for it; with both shards on one machine, both are 127.0.0.1. master_port is the UDP port for that link (10888 unless you change it), and it must not match any shard's server_port on the same machine. cluster_key is the password the shards use with each other. The game modes are survival, endless and wilderness.

Each shard's server.ini

For the Master shard:

[NETWORK]
server_port = 11000

[SHARD]
is_master = true

[STEAM]
master_server_port = 27018
authentication_port = 8768

For the Caves shard:

[NETWORK]
server_port = 11001

[SHARD]
is_master = false
name = Caves

[STEAM]
master_server_port = 27019
authentication_port = 8769

Exactly one shard is the master. Every process on the machine needs its own server_port, master_server_port and authentication_port, which is why each number steps up by one for the Caves. A second cluster on the same box needs a fresh set again, and running several servers on one machine is mostly this kind of bookkeeping.

Ports

Players connect to each shard's server_port over UDP, so forward both. A player who goes down a sinkhole is handed to the Caves process and has to reach its port. If you want players on the same LAN to see the server in their list, keep server_port between 10998 and 11018. The master_port link stays on 127.0.0.1 while both shards share a machine and needs no forwarding. The port forwarding guide covers the router side.

Starting both processes

Install the server with SteamCMD using app ID 343050; the SteamCMD walkthrough explains the commands. Then, from the install's bin64 folder, start each shard:

./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster MyDediServer -shard Master
./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster MyDediServer -shard Caves

Klei's script starts both from one shell and adds -monitor_parent_process so the shards stop along with it. The order is not critical, because the Caves shard keeps retrying until the master is listening. For anything longer-lived than a test, put each shard under a service manager so it keeps running after you close the terminal.

Mods: download once, enable per shard

The server fetches mods itself. List them in mods/dedicated_server_mods_setup.lua inside the server install, one line per Workshop item or collection:

ServerModSetup("123456789")
ServerModCollectionSetup("987654321")

That only downloads them. To switch a mod on, add it to modoverrides.lua in each shard folder, with a workshop- prefix in front of the ID:

return {
  ["workshop-123456789"] = { enabled = true, configuration_options = {} },
}

Keep the two modoverrides.lua files identical unless a mod's page tells you otherwise. One trap is easy to miss: a SteamCMD update with validate checks the install against Steam's copy and puts back the stock dedicated_server_mods_setup.lua. Keep your version outside the install and copy it back after each update.

World settings

Each shard reads its world settings from worldgenoverride.lua or leveldataoverride.lua. The first is written by hand, as a preset plus a list of overrides:

return {
  override_enabled = true,
  preset = "DST_CAVE",
  overrides = {},
}

DST_CAVE goes in the Caves shard, and the forest uses a surface preset such as SURVIVAL_TOGETHER. The Caves shard becomes caves only because its file says so. The easier route to a customised world is to host it once from the game client with the settings you want, then copy the leveldataoverride.lua files it generates into the matching shard folders. Use one method per shard. World generation options are read when the world is generated, so changing them afterwards does nothing to a world that already exists.

Rollbacks and backups

The server saves when each in-game night ends, and c_save() forces a save in between. max_snapshots in cluster.ini sets how many saves are kept (6 by default); c_rollback() goes back one save and c_rollback(3) goes back three. c_shutdown() saves before stopping, while c_shutdown(false) stops without saving, which is what you want when the last few minutes were the problem.

Those snapshots live inside the cluster folder, so they will not survive a lost disk. For a real backup, stop both shards (or save first) and copy the whole cluster folder, so the Master and Caves saves come from the same moment. The guide to game server backups covers how often, and where to keep the copies.

When the caves will not connect

Work through these in order.

• shard_enabled = true is set in cluster.ini.
• Exactly one server.ini says is_master = true.
• Both shards use the same cluster_key. On one machine, set it once in cluster.ini; across two machines, each machine's cluster.ini needs the same value.
• master_port differs from both server_port values.
• On one machine, bind_ip and master_ip are both 127.0.0.1. Across two machines, the master binds to 0.0.0.0, the Caves shard's master_ip is the master's address, and master_port is open between them.
• Players reach the surface but drop at a sinkhole: the Caves server_port is not forwarded.
• Two forests instead of a forest and caves: the Caves shard has no cave preset.
• Both shards run the same build. After an update, restart them together.

Each shard writes its own server_log.txt inside its folder. Read both, because the Caves log shows whether that shard ever reached the master.