How to Install Mods on a Don’t Starve Together Server

Know which folder does what before adding mods

A dedicated Don’t Starve Together server is SteamCMD app 343050. The important thing for mods is that the game install and your world save are not the same place. The install folder contains the game binaries and the global mod download list. The cluster folder contains your world data, plus one folder for Master and one for Caves, and each shard has its own server_log.txt.

By default, the cluster lives at Documents/Klei/DoNotStarveTogether/<Cluster_1>/ on Windows or ~/.klei/DoNotStarveTogether/<Cluster_1>/ on Linux. If you keep that split clear in your head, most mod problems stop being mysterious.

<server install folder>/
  mods/
    dedicated_server_mods_setup.lua
  ugc_mods/

Documents/Klei/DoNotStarveTogether/<Cluster_1>/
  Master/
    modoverrides.lua
    server_log.txt
  Caves/
    modoverrides.lua
    server_log.txt

On a rented server you usually reach the same folders through the panel’s file manager. Many panels also have a mods box where you paste Workshop IDs; underneath, it writes these same files, so everything below still applies when something goes wrong.

Install and enable are separate jobs, and a mod needs both

The most common mistake is thinking “installed” means “active”. On a Don’t Starve Together server, those are two different files in two different places. The install file tells the server what to fetch. The shard file tells each process what to load when it starts.

Use this as the basic model before editing anything else.

Install: global download list

dedicated_server_mods_setup.lua sits in the install folder’s mods/ directory. It is global to that server install, so every cluster or shard using that same install reads from it. The download happens when the server starts, not when you save the file.

-- One mod by Workshop ID
ServerModSetup("350811795")

-- One Workshop collection by ID
ServerModCollectionSetup("379114180")

-- Lines starting with -- are comments

Enable: per-shard load list

modoverrides.lua lives inside each shard folder. This is the file that actually turns a downloaded mod on. A mod that is downloaded but not listed here sits on disk and does nothing.

return {
  ["workshop-350811795"] = { enabled = true },
  ["workshop-378160973"] = { enabled = true },  -- Global Positions
}

Because Master and Caves are separate processes, each shard needs its own modoverrides.lua. For most world-changing mods, you normally give both shards the same file. That is not just tidiness: players walk between the two shards, and a mod that changes items or creatures has to exist on both sides of the cave entrance.

How to tell you fixed the right stage: after editing the setup file, you should see a download line in the logs. After editing the shard files, you should see an enabling line in both shard logs.

Use the right Workshop ID format in the right file

Workshop IDs come from the mod’s Workshop URL. In dedicated_server_mods_setup.lua, use only the plain number. In modoverrides.lua, the same mod name becomes workshop- plus that number. A surprising amount of “silent nothing” comes from writing the right ID in the wrong format.

• ServerModSetup("350811795") downloads one Workshop mod.
• ["workshop-350811795"] = { enabled = true } enables that same mod on a shard.
• ServerModCollectionSetup("379114180") downloads every mod in that Workshop collection.

A collection helps only with the install side. It saves you from listing each mod in the download file, but it does not replace the per-shard enable entries in modoverrides.lua. If you add a collection and expect the mods to start working on their own, they can all download correctly and still do nothing because the shard never enabled them.

If you ever use a non-Workshop mod

Copy the mod folder into <server install folder>/mods/<folder name>/ with modinfo.lua and modmain.lua directly inside it. In that case, the folder name becomes the name used in modoverrides.lua, such as ["my_mod"] = { enabled = true }. That bypasses Workshop download issues, so failures tend to be file placement or syntax problems instead.

Write modoverrides.lua carefully, especially configuration_options

A clean modoverrides.lua is more than an on/off list. It is also where many server-side mod settings live. The important rule is that the keys and values must match the mod’s own modinfo.lua: each option key comes from the name = value, and each chosen value must be one of that option’s listed data = values.

If you use a value outside the mod’s list, the file may still load, but the mod can misbehave. That is why a server can boot cleanly yet still act wrong in play: syntax is valid, but the option is semantically wrong for that mod.

return {
  ["workshop-378160973"] = {
    enabled = true,
    configuration_options = {
      SHOWPLAYERSOPTIONS = 3,
    },
  },
}

That Global Positions example works because SHOWPLAYERSOPTIONS is the exact option name and 3 is one of that option’s valid data values. For this mod, the available data values are 3 for Always, 2 for Scoreboard, and 1 for Never.

Common syntax mistakes

• Missing comma between entries
• Using ( ) instead of { }
• Mismatched quotes
• Saving the file as modoverrides.lua.txt on Windows because hidden file extensions are turned on

If the file itself is broken, the shard log tells you directly with ERROR: Failed to load modoverrides.lua. That is a parser problem, not a Workshop problem, so changing the download file will not help.

The quickest safe shortcut

If you do not want to hand-write the syntax, set the mods up in the game’s own Host Game screen first, then copy the modoverrides.lua that the game writes for that local cluster into your server’s Master and Caves folders. This works well because the game writes correct Lua structure, and you can then edit only the parts you actually need.

Which mods belong on the server, and which should stay with each player

Not every mod belongs on the server. The key flags are in the mod’s modinfo.lua. If all_clients_require_mod is true, the mod changes the shared game enough that every player needs the same mod, and the server will make clients download it automatically from the Workshop when they join. If client_only_mod = true, the mod is just for one player’s own interface and should not be installed on the server at all.

Use this distinction to avoid loading things the server cannot meaningfully use.

This matters for troubleshooting as much as tidiness. Every server mod runs in both shard processes and uses some of their memory, so a long mod list is also why a modded server needs a bigger plan than a vanilla one. A client-only interface mod on the server adds nothing for anyone, and it sends you hunting for an effect that was never going to appear.

server_filter_tags in modinfo.lua only add searchable tags to the server listing. They do not install a mod, do not enable a mod, and do not prove a mod loaded correctly.

Update mods cleanly and restart both shards

Server mods are downloaded or updated when the server starts, and they are only downloaded again when the Workshop version changed. That means a change on the Workshop side does nothing for your running cluster until you restart both shard processes. Use c_shutdown() in each shard console to save and stop cleanly, then start them again.

The reason both shards matter is simple: each one loads its own copy of the active mod set. If Master updates and Caves does not, you no longer have one consistent modded cluster.

Why outdated mods block joins

If a mod has all_clients_require_mod, players joining your server may download the current Workshop version while your server is still running the older one. That version mismatch can stop joins until you restart. Global Positions is a good reminder that even a utility mod can be strict here, because its mod version is also used to decide whether players can join a server.

V2/UGC mods and the per-shard download change

Since the March 2021 quality-of-life update, newer V2/UGC Workshop mods download by default into <server install folder>/ugc_mods/<cluster>/<shard>/. In other words, each shard keeps its own copy. That costs extra disk use and can repeat the same download work for both processes.

You can make shards share one folder with -ugc_directory <path>, such as -ugc_directory ../ugc_mods. Sharing reduces duplicate disk writes and repeated downloads, but two shards trying to fetch the same mod at the same time can clash if they both start together.

Update pass
-only_update_server_mods

Normal shard starts after that
-skip_update_server_mods

Optional shared UGC folder
-ugc_directory ../ugc_mods

The safer pattern is to run once with -only_update_server_mods, let the server download the mods and exit, then start the shards normally with -skip_update_server_mods. That serialises the download step, which costs one extra update pass but avoids two shard processes colliding over the same Workshop content.

The validate trap

Be careful with app_update 343050 validate. Validate checks the game install against what shipped with the game, so it can reset files the game did not ship. On modded DST servers, that can wipe dedicated_server_mods_setup.lua back to the empty default and remove manually copied mods. Keep a backup copy of dedicated_server_mods_setup.lua and restore it after updates if your update routine uses validate.

When your server setup is making mod admin harder than it should be

For Workshop mods, the practical requirements are modest but non-negotiable: you need access to the install folder’s mods/ directory, access to the cluster’s Master and Caves folders, and a way to restart each shard cleanly. If your current setup hides those files or bundles both shards into one opaque start button, normal admin jobs like copying modoverrides.lua, checking logs or controlling UGC update order become awkward for no good reason.

If you are comparing setups, look for the basics that actually matter to modded clusters in our Don’t Starve Together server hosting comparison: file access, shard-level control and enough visibility to read the logs instead of guessing.

Read each shard log in order before changing more files

When a mod silently does nothing, stop editing and read the logs. Check Master/server_log.txt and Caves/server_log.txt separately. A healthy load has four good-sign lines in order, and the missing step usually points straight to the broken file.

Download server mod 350811795
modoverrides.lua enabling workshop-350811795
Loading mod: workshop-350811795 (Mod name) Version:x.y
ModIndex: Load sequence finished successfully.

• If there is no Download server mod line, the mod is missing from dedicated_server_mods_setup.lua, or that file was reset.
• If it downloaded but there is no modoverrides.lua enabling workshop-... line, the mod is missing or misspelt in that shard’s modoverrides.lua.
• If you see ERROR: Failed to load modoverrides.lua, fix the Lua syntax in that shard before doing anything else.
• If you never reach ModIndex: Load sequence finished successfully., startup did not complete cleanly; read the lines immediately above for the actual failure.

Do not chase every scary-looking line. Messages such as AnimationFile::LoadFile Failed to open anim/... can appear in healthy dedicated server logs while mods still load correctly. By themselves, they are not proof that a mod failed.

On Linux, [Workshop] ODPF failed entirely: 16 means the server’s bundled Steam client library is broken, so Workshop downloads fail before the shard can even try to enable mods. The fix is to copy steamclient.so from the SteamCMD folder into the server’s bin/lib32/ or bin64/lib64/ folder, matching your server build.

Troubleshoot the “installed but not working” case methodically

Most silent failures are not random. They are one broken stage in a short chain: download, enable, load, then finish startup. Follow that order instead of changing several files at once.

If a mod downloaded, enabled and loaded in both shard logs, but still seems absent, ask one more question: is it actually a server mod? A client_only_mod = true interface mod will never create world-side effects on the shard, so no amount of server editing will make it behave like a gameplay mod.

Make changes safely on an existing world

Adding mods is usually safer than removing them, but neither should be treated casually on an established cluster. Before changing anything, back up the whole cluster folder so you keep both Master and Caves save data together. It is the only clean way back if a mod breaks startup or the save.

Removing a mod is riskier because the world may already contain things the mod added, and your save now expects code or prefabs that no longer exist. When the shard loads saved data and the mod that created it is gone, those things can quietly disappear or cause errors as the world loads.

A safer change process

1. Stop both shards cleanly with c_shutdown().
2. Back up the cluster folder.
3. Add only a few mods at a time.
4. Restart and read both shard logs before adding the next batch.
5. Only then change or remove older mods.

Adding in batches costs extra restarts, but it saves time overall because one broken mod is easy to identify when the last change set was small. The sign that a batch is good is not just “the server started”; it is both shard logs reaching ModIndex: Load sequence finished successfully. and players joining and moving between surface and caves normally.

Don’t Starve Together server FAQ

Do players need to install the mods before joining my DST server?

For mods marked with all_clients_require_mod, players do not need to prepare them in advance; the game downloads those server-required mods automatically from the Workshop when they join. That is why keeping the server version current matters. Client-only interface mods are different and should be installed by each player locally, not on the server.

Do I need to add mods to the Caves shard as well?

Yes, for most world-changing mods you should enable them in both Master and Caves. The shards are separate processes with separate modoverrides.lua files, so enabling a mod on one does not enable it on the other. Copying the same file to both shards is the usual safe approach.

Why is my mod installed but not working?

Installed only means the server downloaded the Workshop files. A mod still needs a matching entry in each shard’s modoverrides.lua, using the workshop-ID name format. If it still does nothing, check for a syntax error, a wrong configuration value, or the possibility that the mod is actually client_only_mod = true.

How do I update mods on a Don’t Starve Together server?

Restart both shards, because server mods update when the server starts. If you want the least trouble with newer V2/UGC mods, use one update pass with -only_update_server_mods and then start the shards with -skip_update_server_mods. That avoids both shards trying to download the same mod at the same time.

Can I add mods to an existing world?

Usually yes, but back up the whole cluster first. Adding is generally safer than removing, because removing can leave saved world data pointing at content that no longer exists. Add mods in small batches so the logs make it obvious which change caused a problem.

More for Don’t Starve Together server admins

Choosing a host, sizing a server and running one yourself.