# Don't Starve Together Server Hosting - everything RE:NODE has published

> A Don't Starve Together server on RE:NODE: plans, how the panel runs it, and every tutorial RE:NODE has published about it.

Generated from https://www.renode.space/game-servers/dont-starve-together, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers/dont-starve-together.

Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant.

## What it is

Don't Starve Together clusters for a long survival run.

- Genres: Action, Adventure, Indie, RPG
- Developer: Klei Entertainment
- Released: 21 Apr, 2016
- Steam: https://store.steampowered.com/app/322330/

### You supply one thing yourself

Don't Starve Together is only sold with a credential its publisher issues to a person, so you need to own the game yourself and provide it after checkout. We cannot create it for you and we never share one between customers. Your server is built immediately; the game installation waits until you paste it into the Setup tab, then runs itself.

### What comes with every Don't Starve Together server

- Configured before you see it: The install runs, the configuration is written and the server starts. No first-boot checklist, and nothing left on a default password shared with every other Don't Starve Together server on the internet.
- The real console: Live output, command input and the server's own logs - not a filtered summary. Web-server noise is folded behind a counter you can switch off.
- Files and SFTP: A full file manager with an editor, plus SFTP credentials. Upload mods, edit configs, pull a world down to your machine.
- 2-2 backup slots: Taken on demand or on a schedule, restored with a button. Deleting a server takes its backups with it, on purpose.
- 2 ports allocated: Add and remove ports yourself from the Network tab, including the query and RCON ports where the game wants them.
- People on the same server: Invite friends or staff with granular permissions - console only, files only, no billing - through subusers, roles and teams.

### Which Don't Starve Together plan do you need?

Memory is what decides whether a server holds together, so start there. The Starter tier gives 1 GB and 0.8 vCPU, which suits a private group. The Advanced tier at 3 GB is where most public servers sit, and Premium at 6 GB exists for the servers that stay full.

Storage matters more than people expect once mods and backups are involved - plans here run from 10 GB to 40 GB of NVMe. Moving up or down a tier later does not rebuild your world; it changes the limits on the container you already have.

If you are not sure, take the middle tier. It is cheaper to move up after a busy weekend than to spend one explaining lag to your players.

More game servers: https://www.renode.space/ai/game-servers.md

### General questions

### Getting started

**How quickly is my server ready?**

Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours.

**Do I need to configure anything before it works?**

No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards.

**Which games need a key from me?**

Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in.

**Can I try before buying?**

There is no free tier. The entry plans start at $1.50 a month precisely so that trying something costs about as much as a coffee.

**Can Claude or ChatGPT set my project up?**

Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all.

### Running the server

**Do I get full file access?**

Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only.

**Can I install mods and plugins?**

Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run.

**Can other people help me run it?**

Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere.

**What happens if my server runs out of memory?**

New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops.

**Is the CPU limit a hard limit?**

Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it.

### Backups and safety

**Are backups included?**

Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket.

**Where are backups stored?**

Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing.

**What happens to my backups if I cancel?**

Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you.

### Billing

**How do I pay?**

PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid.

**Can I pay in Georgian lari?**

The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount.

**What happens when my subscription is due?**

An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one.

**Can I upgrade or downgrade later?**

Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are.

**Do you offer refunds?**

There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy.

### Support and the honest bits

**How do I get help?**

Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions.

**Where are the servers?**

Germany, on hardware we run. That is one location: if you need players in another region on a low ping, say so before buying rather than after.

**Is there an uptime guarantee?**

We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first.

**Who actually runs this?**

A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter.

## Plans and prices

Read from the live catalogue at 2026-10-15 02:50 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers/dont-starve-together or in the panel shop at https://panel.renode.space before quoting one.

- You supply: Klei cluster token - Sign in with your Klei account, add a server, and copy the cluster token it gives you. It is free. Klei refuses any token it did not issue, so this cannot be generated for you. (https://accounts.klei.com/account/game/servers?game=DontStarveTogether)

| Plan | Price / month | Memory | CPU | NVMe disk | Databases | Backups | Ports |
|---|---|---|---|---|---|---|---|
| Starter | $5 | 1 GB | 0.8 vCPU | 10 GB | 1 | 2 | 2 |
| Standard | $7 | 2 GB | 1 vCPU | 15 GB | 1 | 2 | 2 |
| Advanced | $10 | 3 GB | 1.5 vCPU | 20 GB | 1 | 2 | 2 |
| Pro | $13 | 4 GB | 2 vCPU | 30 GB | 1 | 2 | 2 |
| Premium | $17 | 6 GB | 2.5 vCPU | 40 GB | 1 | 2 | 2 |


## Panel how-to

From the panel guides at https://www.renode.space/guides.

### Ordering a server

Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console.

- Takes: About a minute
- Pay with: Card, PayPal or bank transfer
- Billed for: 1, 3, 6, 12 or 24 months
- Prices in: US dollars or Georgian lari

Open the shop and find what you want to run:

1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases.
2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer.

Compare the plans and pick one:

3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access.
4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world.

Choose how long, then pay:

5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises.
6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes.

Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day.

1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button.
2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it.

After you pay:

- The server appears under My Servers and installs itself. Open it to watch the install in the console.
- Your orders, invoices and subscriptions are under Finances in the side menu.
- Stuck at any step? Open Support in the side menu and raise a ticket.

### The console

Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it.

- Start, stop, restart and kill, with the current state always visible.
- Command history with the arrow keys, and tab completion for common commands.
- Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints.
- Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable.

### Files and SFTP

A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine.

- Drag files in, or upload a folder. Archives can be unpacked in place.
- Edit any text file with syntax highlighting and save without downloading it.
- PDFs and images preview in the panel rather than downloading first.
- SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode.

### Backups

Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away.

- Slots on every plan - two on the entry tiers, more further up.
- Take one on demand, or on a schedule you set.
- Download any backup to your own machine.

> Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel.

### Subusers, roles and teams

Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately.

- A role holds permissions - what may be done.
- A team holds people.
- A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once.
- Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people.
- Access can be time-boxed, and expiry stops working immediately rather than overnight.

### Scheduled tasks

Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action.

- Send a console command - a warning to players, a save, a world flush.
- Take a backup.
- Power actions: start, stop, restart.

### Games that need a key from you

A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers.

> Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation.

## Tutorials

2 posts, newest first. Each one follows in full after the list.

- [Don't Starve Together mods, admins, rollbacks](https://www.renode.space/blog/dont-starve-together-mods-and-admin) (2026-10-07): Install DST mods on a dedicated cluster with dedicated_server_mods_setup.lua and modoverrides.lua, set admins, run console commands and roll back a world safely.
- [Don't Starve Together server: caves and mods](https://www.renode.space/blog/dont-starve-together-server-guide) (2026-09-21): Set up a DST dedicated cluster properly: the Klei token, cluster.ini and server.ini, the Master and Caves shards, ports, admins, rollbacks and workshop mods.

---

### Don't Starve Together mods, admins, rollbacks

Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/dont-starve-together-mods-and-admin

Mods on a Don't Starve Together dedicated server take two files: `mods/dedicated_server_mods_setup.lua` in the server install tells it which workshop items to download, and `modoverrides.lua` in each shard folder decides which of them are enabled and with what settings. Admins are Klei user IDs, one per line, in `adminlist.txt` in the cluster folder. Everything else - kicks, bans, saves, rollbacks, spawning items - is Lua typed into a shard's console, and a handful of those commands behave differently on a server console than they do in game. This post covers the mod files in depth, how to get every mod's configuration right without guessing, the admin setup, a full command reference, and how to roll back without leaving your Forest and Caves on different days.

For the cluster itself - the token, `cluster.ini`, `server.ini`, ports and shards - start with the [Don't Starve Together server guide](https://www.renode.space/blog/dont-starve-together-server-guide). This post assumes a cluster that starts.

#### How mods reach a dedicated server

A DST server never loads mods from players. It downloads them itself, from the Steam Workshop, when a shard starts. The flow is:

1. The shard reads `dedicated_server_mods_setup.lua` and downloads or updates every workshop item listed there.
2. It reads its own `modoverrides.lua` and enables the mods marked `enabled = true`, with the configuration given.
3. When a player joins, the server tells their client which mods are required, and the client downloads those from the Workshop automatically.

```diagram
title: How a mod gets from the Workshop to a DST player
setup = mods_setup.lua | what to download
workshop = Steam Workshop | mod files
shard = Each shard | modoverrides.lua
client = Player's game | auto-download
setup -> workshop : ServerModSetup ids
workshop -> shard : downloaded on start
shard -> client : required mod list
workshop -> client : same versions
```

The consequence of this design is that the cluster must be online - `offline_cluster = false` - for workshop mods to work at all, and every shard downloads what it needs at start-up, so a long mod list means a slower start.

Where the downloaded files end up depends on the mod's workshop format. Older mods are unpacked into the install's `mods` folder as `workshop-<id>` directories. Newer ones are stored in a `ugc_mods` folder, separated by cluster and shard, unless the server is started with `-ugc_directory` pointing somewhere else. You rarely need to touch either; it is useful to know when you are checking whether a download actually happened.

#### dedicated_server_mods_setup.lua

This file lives in the server's install directory, not the cluster folder - `mods/dedicated_server_mods_setup.lua` next to the game binaries. It is the download list, and only the download list:

mods/dedicated_server_mods_setup.lua:

```lua
-- Individual workshop items, by id
ServerModSetup("1234567890")
ServerModSetup("2345678901")

-- Or a whole workshop collection
ServerModCollectionSetup("3456789012")
```

The ID is the number at the end of the mod's Workshop URL, after `?id=`. A collection ID works the same way and pulls every item in the collection - convenient for a large list, but it means anyone who can edit the collection can change what your server downloads. Use a collection you own.

Three things catch people here:

- **This file is in the install, so a reinstall or validate can reset it.** Keep a copy in the cluster folder or in your notes and restore it after updates.
- **Listing a mod here does not enable it.** It only downloads it. A mod in this file and not in `modoverrides.lua` is downloaded on every start and never used.
- **Mods are updated on every start.** When an author publishes, your next restart picks it up. There is no version pinning, which is why a game update or a mod update can break a cluster that ran fine yesterday.

#### modoverrides.lua, per shard

Each shard has its own `modoverrides.lua` in its folder in the cluster - `Master/modoverrides.lua` and `Caves/modoverrides.lua`. It is a Lua table keyed by `workshop-` plus the ID:

Master/modoverrides.lua:

```lua
return {
  ["workshop-1234567890"] = {
    enabled = true,
    configuration_options = {
      stack_size = 99,
      show_in_inventory = true,
    },
  },
  ["workshop-2345678901"] = { enabled = true },
}
```

The rule that decides whether a cluster works: **every mod that affects the world must be enabled with identical options in both shards.** When a player goes down a sinkhole they move between server processes. If a mod is on in the Forest and off in the Caves, items and creatures from that mod do not exist on the far side, and the result ranges from vanished items to a crashing shard. Keep one file and copy it to both folders after every change.

The configuration keys are not documented anywhere except in the mod itself. Every mod has a `modinfo.lua`, and its `configuration_options` table lists each option's internal `name`, its allowed `data` values and its `default`. Values in `modoverrides.lua` must be one of those `data` values exactly - a number where the mod expects a string, or a value that is not in its list, is silently ignored and the default is used.

> [!TIP]
> The quickest way to get a correct `modoverrides.lua` is to let the game write it. Create a world on your own PC with the same mods, set every option in the in-game mod menu, then copy `modoverrides.lua` from that world's cluster folder under `Documents/Klei/DoNotStarveTogether/` up to both shard folders on the server.

#### Which mods belong on a server

Every DST mod declares in its `modinfo.lua` where it runs, and it is worth reading before you add anything:

| Flag in `modinfo.lua` | Meaning for a server |
| --- | --- |
| `client_only_mod = true` | Not for servers at all. Each player installs it themselves |
| `all_clients_require_mod = true` | Runs on server and every client. Auto-downloaded on join |
| `all_clients_require_mod = false` | Runs on the server only. Players need nothing |
| `dst_compatible = true` | Written for DST rather than single-player Don't Starve |

Client-only mods - minimap HUDs, placement grids, interface tweaks - do nothing on a server. Do not add them to the server's list; tell players which ones you recommend instead.

Server-only mods are the cheapest kind for a group: they change rules, drops or spawns without anyone downloading anything. Mods that require all clients are where the download size, version churn and compatibility problems live. A cluster with forty all-clients mods has forty things that can break on the next game update, and a new player's first join downloads all of them.

A good discipline is to keep a short list, test any addition on a copy of the world, and add mods between play sessions rather than during them. [Keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) covers the wider habit, and the general mechanics of workshop content on servers are in [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers).

Mods that are not on the Workshop - your own, or a private fork - are placed as a folder in the server's `mods` directory and enabled in `modoverrides.lua` by that folder name instead of a `workshop-` key. Players then need a copy by hand, because the auto-download only works for Workshop items.

#### Admins and how to find Klei IDs

Admins are listed in `adminlist.txt` in the cluster folder, beside `cluster.ini`:

adminlist.txt:

```text
KU_aB3dEf7h
KU_9zQ2mNp1
```

The entries are Klei user IDs, which start with `KU_` and are the same on every platform the account plays on. They are not Steam IDs or player names. To find one, have the player join and run this in the shard console:

```lua
c_listallplayers()
```

It prints every connected player with their ID. Players can also find their own on their Klei account page. The file is read when the shard starts, so restart after editing it.

An admin in game gets two things. The player list (held `Tab`) shows kick and ban buttons beside each name. And the in-game console - opened with the backtick key - can send commands to the server: it starts in local mode, and you switch it to remote with `Ctrl` before typing. A command run in local mode affects only your own client, which is why "I typed `c_save()` and nothing happened" is so common.

`whitelist.txt` uses the same IDs and works with `whitelist_slots` in `cluster.ini` to reserve slots. `blocklist.txt` is the ban list and the server writes to it when you ban someone.

#### Console command reference

Commands are Lua, typed into the console of the shard you mean - the Forest commands go to the Master, the Caves commands to the Caves.

| Command | What it does |
| --- | --- |
| `c_save()` | Save this shard now |
| `c_shutdown()` | Save and stop. `c_shutdown(false)` stops without saving |
| `c_reset()` | Reload this shard from its last save |
| `c_rollback(n)` | Roll back `n` snapshots |
| `c_regenerateshard()` | Delete and regenerate this shard only |
| `c_regenerateworld()` | Delete and regenerate the whole world |
| `c_announce("text")` | Message to every player |
| `c_listallplayers()` | Connected players with their Klei IDs |
| `TheNet:Kick("KU_...")` | Kick by ID |
| `TheNet:Ban("KU_...")` | Ban by ID and write the block list |
| `c_despawn(player)` | Send a player back to character select |
| `c_godmode(player)` | Toggle invincibility |
| `c_spawn("prefab", n)` | Spawn `n` of a prefab |
| `c_give("prefab", n)` | Give items |
| `c_countprefabs("prefab")` | Count how many exist in this shard |
| `c_gonext("prefab")` | Teleport to the next instance of a prefab |
| `TheWorld:PushEvent("ms_nextcycle")` | Skip to the next day segment |

The gotcha is who a command targets. In game, commands without a player argument act on you - or on whatever you have selected. On the server's own console there is no "you", and many of these fall back to the first player in the player list. So `c_give("goldnugget", 10)` typed into the panel console gives gold to whoever happens to be first, not to the person who asked.

Target players explicitly instead:

```lua
-- Look up a player by name
local p = UserToPlayer("Wendy_main")
c_godmode(p)
c_despawn(p)

-- Give items to one specific player
p.components.inventory:GiveItem(SpawnPrefab("goldnugget"))

-- The connected players, in join order
for i, v in ipairs(AllPlayers) do print(i, v.name, v.userid) end
```

`c_countprefabs` is the admin tool people overlook. A cluster that has started to lag usually has too much of something - dropped items, planted trees, spawned creatures - and `c_countprefabs("log")` or `c_countprefabs("evergreen")` tells you how many there are in seconds.

> [!WARNING]
> `c_regenerateworld()` and `c_regenerateshard()` run with no confirmation and delete the world. They sit in the same tab-completion list as `c_reset()` and `c_rollback()`. Take a backup before using any of the four, and type them carefully.

#### Rollbacks and snapshots

DST keeps snapshots: save points taken by the autosaver, up to `max_snapshots` from `cluster.ini` (6 by default). `c_rollback(1)` goes back one, `c_rollback(3)` three. Players are disconnected and reconnected to the restored state.

The trouble is that a cluster is two worlds. If you roll back the Forest and not the Caves, players who were underground keep their newer state while the surface goes backwards, and the two day counters disagree. Roll back in both shards by the same number, close together, and check both day counters before letting people back in. If you are unsure, the sure way is a full restore of the whole cluster folder from a backup, with both shards stopped.

Snapshots also live on the same disk as the save. They cover "we made a bad decision an hour ago", not "the server was deleted". For that you want a real backup off the machine - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the argument for it. On RE:NODE, backup slots are included on every Don't Starve Together plan, stored off the machine, restored with a button; the Schedules tab can send `c_announce("Saving for backup")` and `c_save()` as console commands, then take a backup a minute later, on a cron expression.

Players can also start a vote to roll back or regenerate the world if `vote_enabled = true`. On a public server, decide whether you want that power in players' hands.

#### Updates and when mods break

Game updates are the main source of DST mod trouble. Klei patches change the internals mods hook into, and each patch breaks a share of mods until their authors catch up. Because the server re-downloads mods on every start, a broken mod update also reaches you without warning.

A short routine:

1. Before a game update, take a backup of the whole cluster folder.
2. After updating, start the Master and read its log as the mods load. A failing mod prints its name and a Lua error.
3. Disable the failing mod in both `modoverrides.lua` files, restart, and check the world.
4. Re-enable it when the author has published a fix.

A mod that added items or creatures cannot always be removed from an existing world cleanly; the shard may drop its objects or refuse to load. Back up before removing, and see [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) for the general recovery drill.

#### Troubleshooting

**Mods are listed in setup but not active.** They are not in `modoverrides.lua`, or the key lacks the `workshop-` prefix.

**A mod works in the Forest and crashes the Caves.** The two `modoverrides.lua` files differ. Copy one over the other.

**Mod settings are ignored.** An option name or value does not match the mod's `modinfo.lua` exactly. Generate the file from the game instead.

**Players fail to join after a mod update.** Their client has an older copy. Restarting the game usually triggers the Workshop update.

**`c_give` gave items to the wrong person.** The server console targets the first player when none is given. Use `UserToPlayer("name")`.

**Admin commands from the in-game console do nothing.** The console is in local mode. Switch to remote, and check the ID is in `adminlist.txt` and the shard restarted.

#### FAQ

##### Do players have to install the server's mods before joining?

No. Mods marked as required by all clients are downloaded automatically when a player joins. Client-only mods are each player's choice and are never required.

##### Can the Forest and Caves have different mods?

Only mods that do not touch shared things, such as some server-side tweaks. Anything that adds items, creatures or recipes must be identical in both shards, or players moving between them hit missing objects.

##### Where do I find a mod's configuration options?

In its `modinfo.lua`, under `configuration_options`. Easier: set the options in a local world in the game and copy the generated `modoverrides.lua` to the server.

##### Does c_rollback affect both shards?

Treat it as affecting the shard you run it on, and roll back both by the same number. Check the day counter in both worlds afterwards.

##### How do I make someone admin without restarting?

The admin list is read at start, so the reliable method is to add their Klei ID to `adminlist.txt` and restart at a quiet moment.

Don't Starve Together plans on RE:NODE come with two port allocations for Master and Caves, an unfiltered console where every `c_` command and mod load error is visible, and the cluster folder open over SFTP or the file manager for `modoverrides.lua`. Backup slots are on every plan, and the Schedules tab can save and back up each night.

[See Don't Starve Together plans](https://www.renode.space/game-servers/dont-starve-together)

---

### Don't Starve Together server: caves and mods

Published 2026-09-21 by RE:NODE Team. https://www.renode.space/blog/dont-starve-together-server-guide

A Don't Starve Together dedicated server is not one program. It is a cluster: a folder of shared configuration plus one server process per world. Almost everybody wants two - the Forest as the Master shard and the Caves as a secondary shard - and that is the single fact that makes DST hosting different from every other game on this blog. Two processes, two ports, two sets of mods, one save. Add a free Klei cluster token, which nobody can generate for you, and you have the whole shape of it. This guide goes through every file, every setting, and the mistakes that leave people staring at a server that starts and never appears.

#### What a cluster is: shards, Master and Caves

A shard is one server process running one world. A cluster is a set of shards that share a name, a password, an admin list and a save. Exactly one shard is the Master; the rest connect to it. By convention the Master runs the Forest and one secondary shard runs the Caves, which is why the folders are usually called `Master` and `Caves`.

When a player climbs down a sinkhole, they are not loading a new area of the same world. They are disconnecting from one server process and connecting to another, with their character handed across the shard link. That explains a lot of DST's behaviour:

- Caves have their own day counter, their own season state and their own world settings.
- The Caves shard runs all the time, whether anybody is down there or not.
- If the Caves process is dead, the sinkholes say caves are unavailable and the Forest carries on perfectly happily.
- A rollback is per-shard unless you roll both back together, which is how people end up with a Forest on day 210 and Caves on day 195.

```diagram
title: A cluster is two server processes sharing one save
players = Players | one address, two worlds
master = Master shard | Forest, UDP 10999
caves = Caves shard | Caves, UDP 10998
save = Cluster save | session folder
players -> master : join
master <-> caves : UDP 10889
master -> save : autosave
caves -> save : autosave
```

You can run a Forest-only cluster and it works fine; the Caves shard is optional. It is also where most of the late game is, so treat it as standard and size for two processes from the start.

#### Requirements and resource usage

Each shard is a separate, largely single-threaded process. Two shards therefore want two cores rather than one fast one, which is the opposite of the advice for most survival games.

| Setup | RAM | CPU | Notes |
| --- | --- | --- | --- |
| Forest only, 1-4 players | 1 GB | 0.75-1 core | One process, small world |
| Forest and Caves, up to 6 | 2 GB | 1-1.5 cores | The normal case |
| Forest and Caves, 8-10, some mods | 3-4 GB | 2 cores | Both shards busy at once |
| Long world, 500+ days, heavy mods | 4-6 GB | 2+ cores | Entity count grows with everything built |

- **Memory** is split between the shards, roughly evenly on a mature world. A Forest shard alone is comfortable in 512-700 MB early on and climbs as the map is explored and built on.
- **CPU** is spent on entity simulation, and DST worlds accumulate entities relentlessly - every dropped item, every planted tree, every boat. A world in its third summer costs meaningfully more than a fresh one.
- **Disk** is small. The install is a few gigabytes, and the save data is megabytes, not gigabytes.
- **Network** is modest and scales with `tick_rate` and player count.

`pause_when_empty = true` is the setting that makes small plans viable: with nobody connected the simulation stops and both shards idle at almost nothing.

#### Installing, the Klei token and the folder layout

The dedicated server is a free anonymous SteamCMD download, app id `343050`. You do not need to own the game on the account you install it with.

```bash
$ steamcmd +force_install_dir /home/dst/server +login anonymous \
    +app_update 343050 validate +quit
```

The binaries are `bin64/dontstarve_dedicated_server_nullrenderer_x64` and the 32-bit `bin/dontstarve_dedicated_server_nullrenderer`. They expect to be run from their own directory.

Configuration does not live with the install. It lives in a cluster folder under the user's Klei directory:

```text
~/.klei/DoNotStarveTogether/MyDediServer/
  cluster.ini              settings shared by every shard
  cluster_token.txt        your Klei token, nothing else in the file
  adminlist.txt            one Klei user id per line
  whitelist.txt
  blocklist.txt
  Master/
    server.ini
    worldgenoverride.lua
    modoverrides.lua
    save/
  Caves/
    server.ini
    worldgenoverride.lua
    modoverrides.lua
    save/
```

The token is the part you cannot skip. Sign in at the Klei accounts site, open the Don't Starve Together server section, add a server, and copy the token it issues. Paste it into `cluster_token.txt` as the only content of the file - no quotes, no trailing text. It is free, it is tied to your Klei account, and Klei will reject any token it did not issue, which is why no host can create one for you. Running two live clusters on the same token will knock one of them offline, so generate one per server.

RE:NODE asks for this before the install runs: the Don't Starve Together line is one of the few that needs a credential of your own, the server itself is created as soon as payment clears, and the installation waits on the Setup tab until you paste the token in.

Then start both shards. On your own machine that is two commands, usually two services:

```bash
$ cd /home/dst/server/bin64
$ ./dontstarve_dedicated_server_nullrenderer_x64 \
    -console -cluster MyDediServer -shard Master
$ ./dontstarve_dedicated_server_nullrenderer_x64 \
    -console -cluster MyDediServer -shard Caves
```

Useful flags: `-console` enables console input, `-cluster` picks the cluster folder, `-shard` picks the shard folder inside it, `-persistent_storage_root` moves the whole Klei directory somewhere else, and `-monitor_parent_process` makes a shard exit when its supervisor does, which stops orphaned Caves processes.

The Caves shard needs to be told to generate a cave world rather than another forest. That is a `worldgenoverride.lua` in the `Caves` folder:

Caves/worldgenoverride.lua:

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

The Master equivalent uses `preset = "SURVIVAL_TOGETHER"`. Get this wrong and you will have a cluster with two forests and no caves, which cannot be fixed without regenerating the Caves world.

#### cluster.ini, setting by setting

One file, four or five sections, shared by every shard in the cluster.

cluster.ini:

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

[NETWORK]
cluster_name = The Long Winter
cluster_description = Cooperative, mods on, no griefing
cluster_password = hollow-stalagmite
cluster_intention = cooperative
lan_only_cluster = false
offline_cluster = false
tick_rate = 15
whitelist_slots = 0
autosaver_enabled = true

[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 = 10889
cluster_key = a-long-random-string

[STEAM]
steam_group_only = false
steam_group_id = 0
steam_group_admins = false
```

| Setting | Default | What it does |
| --- | --- | --- |
| `game_mode` | `survival` | `survival`, `endless` or `wilderness` |
| `max_players` | `6` | Total across the cluster, not per shard |
| `pvp` | `false` | Player damage |
| `pause_when_empty` | `false` | Stops the simulation with nobody online |
| `vote_enabled` | `true` | In-game kick and rollback votes |
| `cluster_intention` | - | `cooperative`, `social`, `competitive` or `madness` |
| `cluster_password` | - | Blank means anyone can join |
| `offline_cluster` | `false` | No Klei services, no browser listing, no mods |
| `lan_only_cluster` | `false` | Local network only |
| `tick_rate` | `15` | Server updates per second |
| `whitelist_slots` | `0` | Slots reserved for whitelisted players |
| `autosaver_enabled` | `true` | Save at every dusk |
| `console_enabled` | `true` | Allows the in-game and server console |
| `max_snapshots` | `6` | How many rollback points are kept |
| `shard_enabled` | `false` | Must be `true` for a two-shard cluster |
| `master_port` | `10889` | The shard-to-shard link, not a player port |
| `cluster_key` | - | Shared secret between shards, any string |

Four of these are worth a sentence each.

**`shard_enabled`.** If this is `false`, the Caves shard will start, fail to find a Master and sit there. It is the most common reason a Caves process runs and the sinkholes still say caves are unavailable.

**`cluster_key` and `master_port`.** The shards authenticate to each other with the key and talk over `master_port` on `master_ip`. When both shards are on the same machine, leave those at `127.0.0.1` and `10889`; that traffic never needs to leave the box and should not be exposed.

**`tick_rate`.** Fifteen is the default and is fine for a cooperative group. Raising it to 30 makes combat feel crisper and roughly doubles both the CPU cost per player and the bandwidth. On a small plan that trade usually is not worth it.

**`offline_cluster`.** Setting this to `true` disconnects the cluster from Klei entirely - no token needed, no server browser entry, and no workshop mods. It is for a LAN party, not for a server you want people to find.

#### server.ini and the ports each shard needs

Each shard folder has its own `server.ini`, and the values must differ between shards:

Master/server.ini:

```ini
[NETWORK]
server_port = 10999

[SHARD]
is_master = true

[STEAM]
master_server_port = 27018
authentication_port = 8768

[ACCOUNT]
encode_user_path = true
```

Caves/server.ini:

```ini
[NETWORK]
server_port = 10998

[SHARD]
is_master = false
name = Caves
id = 2

[STEAM]
master_server_port = 27019
authentication_port = 8769

[ACCOUNT]
encode_user_path = true
```

| Port | Protocol | Purpose |
| --- | --- | --- |
| `10999` | UDP | Master shard, the port players connect to |
| `10998` | UDP | Caves shard |
| `27018` / `27019` | UDP | Steam master server, one per shard |
| `8768` / `8769` | UDP | Steam authentication, one per shard |
| `10889` | UDP | Shard link, loopback only |

Everything DST uses is UDP. A shard needs its own `server_port`, its own `master_server_port` and its own `authentication_port`, all distinct from every other shard's - sharing any of the three is why one shard starts and the other quietly does not. If you want LAN discovery to work, keep `server_port` in the 10998-11018 range; for internet play any free port is fine. The reasons query-style ports exist at all are in [game server ports explained](https://www.renode.space/blog/game-server-ports-explained).

`is_master` is what makes a shard the Master. Two shards with `is_master = true` in the same cluster is a cluster that will not link. `id` must be unique per shard, and `name` is the label the game shows for that world.

On a panel you do not edit these by hand as often as you think - the ports are allocated for you. RE:NODE's Don't Starve Together plans come with two allocations, and further ports are added and removed on the Network tab if you want a third shard.

Players find the server through the in-game browser, filtered by name. Direct connection also works: open the console in game with the backtick key and run `c_connect("203.0.113.10", 10999, "hollow-stalagmite")`. That is the reliable route when the browser is slow, and the only route if the listing has not refreshed yet.

#### Admins, whitelist and the block list

Three plain text files in the cluster folder, one Klei user id per line. Klei ids look like `KU_aB3dEf7h` and are stable per account.

adminlist.txt:

```text
KU_aB3dEf7h
KU_9zQ2mNp1
```

`whitelist.txt` works with `whitelist_slots`: if you set `whitelist_slots = 2` on a six-player server, four slots are open to anyone and two are held for the listed players even when the server looks full. `blocklist.txt` is the ban list and is written by the server when you ban someone in game.

The reliable way to get a player's id is to have them join once and run `c_listallplayers()` in the console, which prints every connected player with their id. Players can also read their own from the Klei account page. The files are read at shard start, so add ids and restart, or promote in game and let the server write the file itself.

#### Console commands, rollbacks and snapshots

DST's console is Lua. Commands are typed into the shard's console - the panel console box, or the in-game console opened with the backtick key if you are an admin. In game, the console has a local and a remote mode; the remote one sends the command to the server, and you toggle between them with control and backtick. Running a server command in local mode is the reason nothing appeared to happen.

| Command | What it does |
| --- | --- |
| `c_save()` | Writes a save immediately |
| `c_shutdown()` | Saves and stops the shard |
| `c_shutdown(false)` | Stops without saving |
| `c_rollback(1)` | Rolls this shard back one snapshot |
| `c_regenerateworld()` | Deletes this world and generates a new one |
| `c_reset()` | Reloads the shard from its last save |
| `c_announce("text")` | Server message to everyone |
| `c_listallplayers()` | Every connected player with their Klei id |
| `TheNet:Kick("KU_aB3dEf7h")` | Kicks |
| `TheNet:Ban("KU_aB3dEf7h")` | Bans and writes the block list |
| `c_spawn("deerclops")` | Spawns a prefab at the cursor |
| `c_give("goldnugget", 10)` | Gives items to the selected player |
| `c_freecrafting()` | Toggles free crafting for the selected player |

> [!WARNING]
> `c_regenerateworld()` does exactly what it says and there is no confirmation. It is one character away from `c_rollback()` in muscle memory and it has ended a great many worlds. Take a backup before you touch either.

Snapshots are DST's own rollback points, capped by `max_snapshots` and kept in the shard's `save` folder. `c_rollback(2)` goes back two of them. Two things about this catch people out. Snapshots are per shard, so rolling the Forest back without the Caves leaves the two worlds on different days - roll both, in quick succession. And snapshots live on the same disk as the save, so they are protection against a bad decision, not against a lost server.

Real backups belong somewhere else. On RE:NODE every Don't Starve Together plan includes backup slots, stored off the machine they protect and restored with a button, and the Schedules tab will take one on a cron expression - a nightly copy plus one before you install a mod is the sensible pattern. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) explains why the restore half is the half that matters, and [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) has more patterns worth copying.

#### Mods on a dedicated cluster

Workshop mods on a dedicated server are a two-step job, and skipping either step is the reason most people's mods do not load.

**Step one: tell the server to download them.** In the game install directory, `mods/dedicated_server_mods_setup.lua` lists what SteamCMD should fetch on start:

mods/dedicated_server_mods_setup.lua:

```lua
ServerModSetup("1595631294")
ServerModSetup("375850593")
ServerModCollectionSetup("1234567890")
```

The numbers are workshop file ids, taken from the end of the mod's workshop URL. `ServerModCollectionSetup` takes a collection id and pulls everything in it, which is much easier to maintain for a large list.

**Step two: enable them per shard.** `modoverrides.lua` in each shard folder decides which downloaded mods are actually on, and carries their configuration:

Master/modoverrides.lua:

```lua
return {
  ["workshop-1595631294"] = {
    enabled = true,
    configuration_options = {
      ["language"] = "en",
    },
  },
  ["workshop-375850593"] = {
    enabled = true,
  },
}
```

The key is the literal string `workshop-` followed by the id. Anything that changes the world needs the same entry in both `Master/modoverrides.lua` and `Caves/modoverrides.lua`, with identical settings - a mod enabled on one shard and not the other produces missing prefabs and crashes when a player moves between them. The simplest discipline is to keep one file and copy it to both folders.

Clients are made to download matching mods automatically when they join, which is why a modded cluster needs `offline_cluster = false`. Mods update on the workshop whenever their authors publish, and a DST update will break a proportion of them, so back the cluster up before a game patch and do not be surprised when the first start after one fails. The general mechanics of workshop content on servers are in [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers), and the recovery drill is in [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks).

#### Troubleshooting

**"Your server will not start without a token."** `cluster_token.txt` is missing, empty, in the wrong folder, or contains something besides the token. It belongs in the cluster folder, not in a shard folder.

**The server runs but is not in the browser.** Check `offline_cluster` and `lan_only_cluster` are both `false`, that the token is valid, and that no other live cluster is using the same token. Test with `c_connect` from the in-game console: if a direct connection works, the server is fine and only the listing is missing.

**Caves are unavailable in game.** Either the Caves process is not running, or the link is broken. Check `shard_enabled = true` in `cluster.ini`, `is_master = false` in `Caves/server.ini`, that both shards have the same `cluster_key`, and that the two shards have different `server_port`, `master_server_port` and `authentication_port` values.

**One shard starts and the other exits immediately.** Almost always a port collision between the two `server.ini` files, or two shards with the same `id`.

**Mods do not load.** Confirm the id appears in both `dedicated_server_mods_setup.lua` and each `modoverrides.lua`, that the `workshop-` prefix is present in the overrides, and that the cluster is not offline. The shard log prints each mod it loads by name.

**The world is on the wrong day after a rollback.** You rolled one shard. Roll the other back the same number of snapshots, then restart both.

**Both shards restart repeatedly.** Look for the memory limit first. A cluster sized for one shard will be stopped at its limit once Caves are generated, and a crash loop is usually resource exhaustion rather than a config error - [why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) walks through telling them apart.

#### FAQ

##### Do I need my own Klei token?

Yes, and it has to be yours. It is free from your Klei account page and takes a minute, but Klei rejects any token it did not issue to that account, so no host can supply one. Generate a separate token for each cluster you run.

##### Can I run Don't Starve Together without caves?

Yes. A Forest-only cluster is one shard and one port, and it works completely. You lose the caves content, which is most of the mid and late game, and adding caves later means generating a new cave world rather than revealing one.

##### How many players can a DST server hold?

`max_players` defaults to 6 and can be raised. The practical ceiling is the CPU cost of a mature world and the amount of griefing you are prepared to police; most groups settle between 6 and 10. The limit counts the whole cluster, not each shard.

##### Where does the save actually live?

In `save` inside each shard folder, under the cluster directory. The Forest and the Caves keep separate save data, which is why rollbacks are per shard. Back up the whole cluster folder, not one shard.

##### Why do my mods work on the Forest but crash the Caves?

Because `modoverrides.lua` is per shard and the two files have drifted apart. Any mod that affects the world must be enabled with identical configuration in both, or a player moving between shards hits prefabs that only exist on one side.

##### Is it safe to raise the tick rate?

It is safe, but it costs. Going from 15 to 30 roughly doubles the per-player CPU and bandwidth, and on a small plan that shows up as lag with a full server rather than smoother combat. Try it with your usual group and change it back if the server graph climbs.

Don't Starve Together clusters on RE:NODE start from 1 GB with two port allocations, so Master and Caves both have somewhere to live, and more ports are added on the Network tab. Paste your Klei token on the Setup tab and the install runs; backup slots are on every plan and the console is unfiltered, so you can read a shard's mod list as it loads.

[See Don't Starve Together plans](https://www.renode.space/game-servers/dont-starve-together)

## Rules for the assistant

- Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead.
- Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository.
- An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port.
- On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker.
- Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak.
- Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository.
- Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current.
- For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one.
- If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.
