Before you start
You need world administration rights and its files. First confirm that the service supports the necessary processes and allocations: a DST product alone does not establish an included two-shard cluster. Preserve a backup and confirm assigned ports before starting.
Plan a cluster rather than two unrelated worlds
Master normally represents the surface and Caves the underground world. Both belong to one cluster while running as separate processes. Plan the game mode, optional PvP rules, access and world-generation settings before creating a world. Changing a generation setting does not automatically rebuild saved areas. Record the game build and mods used by the group so that a later recovery has a known reference.
Locate configuration without assuming a universal path
Storage depends on the platform and launch options. Inside the cluster directory, cluster.ini holds shared settings. Each shard has its own server.ini, such as Master/server.ini and Caves/server.ini. World and mod settings must belong to the intended shard. Preserve the existing structure and take a copy before editing. An example directory tree is not an instruction to move live data; identify the files the running service actually loads.
Create a Klei token and distinguish the secrets
Use official server management through your Klei account to generate a token. cluster_token.txt provides cluster authentication; keep it private and exclude it from shared screenshots. Do not confuse it with the internal key used for shard communication. That key must be consistent across the relevant components, but it is neither a Klei account password nor a player joining password. Different credentials should never be substituted for one another to bypass an error.
Confirm supported processes and allocated ports
Klei documents two launches sharing a cluster name with separate -shard Master and -shard Caves arguments. Each process needs game and Steam ports compatible with its allocations and distinct where required. Have the service’s supported inter-shard communication and assigned values confirmed. Do not copy another host’s ports, start an unsupported second instance or modify the host machine’s network. Process availability is a separate service question from the game’s general ability to run caves.
Introduce mods and test the cave transition
Distinguish client mods from mods that the server must load. Review each Workshop page, dependencies and compatible release. Check the mod setup and override files used by the actual DST version, then apply settings to the relevant shards. Add one mod at a time. Test joining the surface, travelling into caves, returning and character behaviour before inviting the whole group. A successful surface connection alone does not validate the underground process or all mod behaviour.
Back up and recover the complete cluster coherently
Notify players and stop writes in both processes before taking a coherent copy. Preserve Master, Caves, shared files and mod configuration together with a date and build reference. Surface files alone are not a complete cluster backup: restoring different parts from different dates can desynchronise progress and items. Keep a copy outside the server. After recovery, verify joining, cave travel and persistence before resuming the group’s session.
For your situation
| Situation | Next check |
|---|---|
| Surface works without caves | Check second-process support, its files and communication before adding mods. |
| Underground travel fails | Compare both shards’ logs, allocations and settings without disclosing secrets. |
| A cluster must be restored | Use a coordinated copy of both worlds and the shared configuration. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.