How to Set Up a Don’t Starve Together Dedicated Server

What a dedicated server is, and why caves mean two shards

A Don’t Starve Together dedicated server is not the same thing as clicking Host Game in the client. Host Game uses the game client itself to run the world and creates save folders such as Cluster_1, Cluster_2 and so on. A dedicated server uses a separate server install and its own cluster folder, so you can keep the world online without one player acting as host.

That distinction matters because a lot of first-setup mistakes come from editing the wrong files. If you unpack or build a dedicated server in MyDediServer, but later change settings inside Cluster_1, the server will ignore them. The client and the dedicated server can exist on the same PC, but they should not share the same working folder.

Caves add one more layer: DST treats a forest plus caves world as a cluster of shards. The Master shard is the overworld. The Caves shard is the caves world. They are two separate server processes, each with its own save data and listening ports, but they authenticate to each other using the same cluster_key and talk over the master_port. That is why a caves server is not “one world with a checkbox”; it is two coordinated services.

Running caves also means more ongoing work than a single forest shard. You are keeping a second world simulation in memory, a second process on the CPU, a second set of saves on disk, and another network endpoint open. The trade-off for players is obvious: caves travel works properly, but the setup has more places to go wrong. Also note that dedicated servers are for the PC version tied to a Klei account, not the console versions.

Use this as your mental model before you touch any files: one cluster folder, two shard folders, one token, one cluster_key, two running processes.

The first-setup order that avoids false starts

The order is the important part. Most frustrating starts come from doing the right steps in the wrong sequence, then trying to repair a half-generated world afterwards. For a first boot, keep it unmodded and do not add admins yet. Get the base server listed and joinable first.

Why this order works: the token solves identity first, the file layout makes sure each process reads the right settings, cluster.ini defines the cluster-wide behaviour, per-shard files handle the fact that two processes cannot bind to the same ports, and only then do you let the game generate worlds. If you generate first and fix later, existing saves can keep loading the old state from disk.

Get the cluster token before anything else

The token is the server’s credential with Klei’s account service. Without it, the server can launch an executable, consume CPU and memory and even start creating files, but it still cannot authenticate the cluster correctly. That is why token problems are so often mistaken for “the server runs but never shows up”. Keep the token private; it identifies that server instance.

Method A: Klei Accounts and Download Settings

1. Sign in to the Klei account that is bound to your Steam copy of the game.
2. Open GAMES, scroll to Don’t Starve Together, then open Game Servers.
3. Click ADD NEW SERVER or CONFIGURE on an existing valid server entry.
4. Use Download Settings.
5. Extract the downloaded folder so that MyDediServer sits inside Documents\Klei\DoNotStarveTogether\.

This route is the least error-prone because the download already includes cluster_token.txt and the starter file layout. If you see old or expired entries there, clean them up before you confuse yourself with the wrong token.

Method B: generate it in the game client

If you already have the game client open, you can generate the token there and then copy it into your dedicated cluster folder. Open the developer console with tilde on a standard keyboard, or ù on Azerty, and run:

TheNet:GenerateClusterToken()

The game writes the token to Documents/Klei/DoNotStarveTogether/cluster_token.txt. Copy that file, or its single line, into MyDediServer\cluster_token.txt. The command-line -token option exists, but for a first setup the file is simpler because you can see exactly what the server is reading.

A healthy startup usually logs that it retrieved the token from cluster_token.txt and later shows [200] Account Communication Success. A bad token tends to produce account errors such as E_INVALID_TOKEN. If you get that, do not keep changing world files; replace the token first.

Install the dedicated server and put the files in the right place

You can install the dedicated server through Steam Tools or with steamcmd using app 343050. The important point is that you are installing the dedicated server package, not launching from the normal game client. Current official scripts use the x64 server executable under bin64.

By default, the configuration root is under your Klei documents folder. The usual Windows dedicated path after extracting the official settings zip is Documents\Klei\DoNotStarveTogether\MyDediServer\. On Linux, the equivalent default root is under ~/.klei. If you do use different paths later, that is what -persistent_storage_root, -conf_dir and -cluster are for, but beginners are better off staying with the defaults first.

Your first-boot file set should be small and clear:

• cluster_token.txt
• cluster.ini
• Master\server.ini
• Caves\server.ini
• Caves\worldgenoverride.lua
• Optionally the Windows start script StartDSTServers.bat

If any of those core files are missing, the server may still try to start, but not as the forest-plus-caves cluster you intended. The Download Settings zip is useful precisely because it reduces typing errors and puts the token in the right place from the start.

Set up cluster.ini before you launch anything

Think of cluster.ini as the cluster-wide rule file. It tells the server what the cluster is called, how players join it, and whether it is actually meant to behave as a multi-shard world. For a beginner, the biggest trap is that shard_enabled defaults to false. If you never turn that on, the server will happily behave like a single-level world and caves will not link.

The other defaults worth knowing are pause_when_empty = false, max_players = 16, tick_rate = 15 and master_port = 10888. Leaving tick_rate at 15 is usually the right call. A higher tick rate means the server sends updates more often, which results in more network traffic, so it is best left at 15 unless you are on a LAN. It is not a fix for bad listing, missing caves or account failures.

pause_when_empty is the setting many beginners do want to change. With the default false, the world keeps simulating when nobody is connected. Setting it to true does not make the live server faster for connected players, but it does stop time progression while empty and reduces the amount of idle world simulation. You can tell it is working because the world clock and day count no longer advance during empty periods.

Here is a clean first cluster.ini for a private friends server with caves enabled:

[GAMEPLAY]
game_mode = survival
max_players = 16
pvp = false
pause_when_empty = true
vote_enabled = true

[NETWORK]
cluster_name = YOUR SERVER NAME
cluster_description = YOUR SERVER DESCRIPTION
cluster_password = YOUR SERVER PASSWORD
cluster_intention = cooperative
autosaver_enabled = true

[MISC]
console_enabled = true

[SHARD]
shard_enabled = true
bind_ip = 127.0.0.1
master_ip = 127.0.0.1
master_port = 10888
cluster_key = REPLACE_WITH_A_PRIVATE_KEY

The cluster_key is the internal password the non-master shard uses to authenticate to the master. It is not the same as the player join password. If the keys do not match across the cluster, Caves cannot attach. On one machine, 127.0.0.1 is correct for the shard link because both processes are talking locally.

Configure Master and Caves correctly

Each shard needs its own server.ini. This is where beginners often end up with “only Master runs” or “the caves process starts and vanishes”. The reason is simple: each process needs its own network sockets. If both shards try to bind the same player port or the same Steam ports on one machine, one of them loses. That failure is not about world settings; it is an operating system networking conflict.

Start by making sure exactly one shard has is_master = true. That is the forest shard. The Caves shard must have is_master = false and its own name. Use different server_port, authentication_port and master_server_port values for each shard on the same machine.

Master/server.ini

[NETWORK]
server_port = 10998
[SHARD]
is_master = true
name = Master
id = 1
[STEAM]
master_server_port = 27016
authentication_port = 8766
[ACCOUNT]
encode_user_path = true

Caves/server.ini

[NETWORK]
server_port = 10999
[SHARD]
is_master = false
name = Caves
id = 2
[STEAM]
master_server_port = 12346
authentication_port = 10166
[ACCOUNT]
encode_user_path = true

The documented example puts Master on 10998 and Caves on 10999. That avoids colliding with the default shard player port while keeping both inside the range that lets players on the same LAN see the server in their listing. Also make sure your master_port in cluster.ini does not collide with either shard’s player port on the same machine.

The last piece is caves world generation. A Caves shard folder without the right world preset is still a world, just not the caves world you meant to create. Set Caves\worldgenoverride.lua before the first launch:

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

This file only affects world generation. Once a save exists under the shard’s save data, the server loads that existing world from disk instead of generating a new one. So if you started once with the wrong preset, fixing worldgenoverride.lua afterwards does not rewrite the existing world.

Start both shards and confirm the server is live

When the files are correct, start both shard processes with the same cluster name. On Windows, the official pattern updates the dedicated server first, then launches Master and Caves from the bin64 folder. The key point is not the batch file itself; it is that both commands use the same -cluster value and different -shard values.

c:\steamcmd\steamcmd.exe +login anonymous +app_update 343050 validate +quit

start dontstarve_dedicated_server_nullrenderer_x64 -console -cluster MyDediServer -shard Master
start dontstarve_dedicated_server_nullrenderer_x64 -console -cluster MyDediServer -shard Caves

The older generic two-command pattern is the same idea:

dontstarve_dedicated_server_nullrenderer -cluster MyClusterName -shard Master
dontstarve_dedicated_server_nullrenderer -cluster MyClusterName -shard Caves

On Linux, the official x64 script pattern also adds -monitor_parent_process $$ so the shards close if the parent script dies:

./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster "$cluster_name" -monitor_parent_process $$ -shard Caves
./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster "$cluster_name" -monitor_parent_process $$ -shard Master

What success looks like:

• Both shard windows or logs stay open instead of exiting straight away.
• The log shows the token was retrieved from cluster_token.txt.
• You later see [200] Account Communication Success.
• The server appears in Browse Games under the cluster_name.

If it does not appear immediately in the list, reset filters and search by name. A passworded server still appears; it just asks for the password when joining. If you only see it under LAN, review offline_cluster and lan_only_cluster. If players on the same LAN cannot see it in the listing, check that the shard player port is inside 10998 to 11018.

The rented-host shortcut

If you rent a managed DST server, the panel usually does the file writing for you. The first job is still the same: paste the Klei token into the panel’s server token field so it can write cluster_token.txt. Then set the visible server name, password and player count in the panel, enable caves if the host supports shard controls, and start the service.

This route reduces the operating system side of the setup. You are not dealing with Steam installation paths, start scripts or Windows security prompts on your own PC. In exchange, you should still verify what the panel actually wrote. Open the file manager and find the folder containing cluster.ini; that is your cluster folder. You should be able to see cluster_token.txt, Master, and if caves are enabled, Caves.

That file check matters because panels can hide the details that explain a failure. If the service says “running” but Browse Games never shows the server, the same rules still apply: bad token, shard_enabled left false, only one shard active, duplicated ports, or a broken caves preset. The panel is a convenience layer, not a different kind of server.

Troubleshooting a server that will not start or does not appear

When diagnosis is simple, fix one layer at a time: identity first, then shard link, then ports, then visibility. Do not change six settings at once or you will never know what actually solved it.

A quick rule of thumb: if the error mentions account communication, stay away from world files and fix the token. If Master runs but Caves does not link, stay away from Browse Games filters and fix shard settings and ports. If both shards are healthy but nobody can find the server, check visibility settings and the browser filters.

Once it is online: admins first, then mods and backups, then decide how you want to run it

Once the unmodded server is visible and joinable, then add your admins. Put one KU_XXXXXXXX per line into adminlist.txt in the cluster folder, using the player’s Klei UserId from the Acct Info button on the main menu, not their Steam ID. Restart after editing. If you want the command side explained properly, use our Don’t Starve Together console commands guide.

After that, move on to extras one at a time. Mods belong later because failed or crashing mods can stop a dedicated server initialising, which muddies first-boot diagnosis. When you are ready, use our guide to installing mods on a DST server. Before you copy an old world in or start experimenting, back up and transfer your DST world properly so you do not overwrite the token or your working shard settings.

If you are deciding between self-hosting on a PC and renting, focus on control and access rather than marketing. A good setup makes it easy to reach the token field, the actual cluster files, and the status of both shards. If a panel hides the files entirely, or makes it hard to tell whether Caves is running as a second shard, troubleshooting gets slower than it needs to be. For a broader view of what to look for, see our Don’t Starve Together server hosting comparison.

Don’t Starve Together server FAQ

How do I set up a Don’t Starve Together dedicated server?

Do it in order: generate the cluster token, install the dedicated server files, create a dedicated cluster folder such as MyDediServer, fill in cluster.ini, configure Master and Caves separately, then start both shard processes. For a first boot, keep it unmodded and confirm it appears in Browse Games before you add anything else.

How do I get a Don’t Starve Together server token?

You can download it through the Klei account page under GAMES, Don’t Starve Together, Game Servers, then ADD NEW SERVER or CONFIGURE and Download Settings. Or generate it in the game client with TheNet:GenerateClusterToken() and copy the resulting cluster_token.txt into the active dedicated cluster folder.

Why does my Don’t Starve Together server not show up?

The most common reasons are a bad token, no visible cluster_name, offline or LAN-only settings, or only one shard actually running in a caves setup. Confirm the logs show the token being read and [200] Account Communication Success, then reset Browse Games filters and search by name.

Do I need two processes for Don’t Starve Together caves?

Yes. The overworld and caves are separate shards, so a forest plus caves server needs a Master process and a Caves process. They must share the same cluster folder and cluster_key, but each needs different ports on the same machine.

What files does a Don’t Starve Together dedicated server need?

For a basic forest plus caves setup, the essential files are cluster_token.txt, cluster.ini, Master/server.ini, Caves/server.ini and Caves/worldgenoverride.lua. If you are on Windows, a StartDSTServers.bat file is also useful so you always launch both shards the same way.

More Don’t Starve Together server help

Once the server is joinable, add admins, install mods or back up the world, or compare hosts that make the token and both shards easy to reach.