How to Install Mods on a RimWorld Server

The key idea: RimWorld Together servers do not run mods

If you keep picturing the server as a place where mods are installed and executed, the join errors are hard to interpret. RimWorld Together works differently. Each player runs Harmony, RimWorld Together and every other chosen mod locally; the server keeps the shared planet online and stores the rules for what a valid client must be running.

So when people say they want to install mods on a RimWorld server, what they really mean is: build the server’s allowed mod list, decide what is Required and Optional, and make every player’s client match it. Once a world exists, the server checks that at login and refuses mismatches.

This is also why a RimWorld Together server stays light even with a long modlist: it never loads a single mod. The cost of a big modlist sits on the players’ PCs instead. Every Required mod is one more thing each player must install, keep updated and load in the right place, and one more way for a single machine to drift away from the shared rules.

An illustrative ModConfig.json looks like this:

{
  "AllowAllMods": false,
  "EnforceSettings": true,
  "ModOrder": { "Hash": "...", "DataString": "..." },
  "ModConfigs": [
    {
      "Type": "Required",
      "ModName": "Harmony",
      "ModID": "brrainz.harmony",
      "Settings": { "Hash": "...", "FileName": "...", "DataString": "..." }
    },
    {
      "Type": "Optional",
      "ModName": "Some UI mod",
      "ModID": "...",
      "Settings": { ... }
    }
  ]
}

Treat that as a map, not something to type by hand. The server writes this file when the list is set up in game or through a host’s Mods page, and the hash values only make sense when the game generates them.

AllowAllMods bypasses the checks entirely, EnforceSettings makes the server compare mod settings for required mods, and ModOrder stores a hash of the enforced load order. That hash comparison is exact, not approximate.

Plan the mod list before the world exists

Do the thinking before anyone creates the planet. At minimum, everybody needs Harmony and RimWorld Together enabled. From there, decide what is part of the shared world and what is just a local convenience. Keep the first enforced list as small as you can; that is also the official wiki advice, and it makes later maintenance much easier.

A good rule: if a mod can place something into the world, change a faction, add a race, generate a site, alter buildings, or otherwise write persistent content into the save, put it in Required. If it only changes menus, tabs, tooltips or visuals on one machine, it is a candidate for Optional.

Be careful with DLCs too. The client can show the warning Optional DLCs might cause issues, continue? and let a player push on, but that is not a reliable policy for a shared server. Treat DLC choices like big content mods: agree the baseline before world creation and keep everyone aligned.

Load order matters from the start. In RimWorld, Harmony goes first, then Core, then DLCs, then libraries, then content. RimWorld Together itself loads after Harmony, Core and the DLCs it knows about, so do not force it above them. A clean early order reduces later hash mismatches and makes troubleshooting simpler.

Fresh server setup: the admin should be the first player in

On a fresh server with no world yet, the first player to join gets asked to configure the server mod list from their own enabled mods. They choose Required or Optional for each mod, answer Do you want to enforce mod configs?, and then create the world. That makes the first join the most important join of the entire server life.

1. Prepare one clean client with exactly the intended enabled mods.
2. Put them in the intended order.
3. Join as the person who will administer the server.
4. Mark only true shared content as Required.
5. Create the planet only after that list is right.

This works because the server uses that first client as the template. If a friend joins first with half a dozen personal UI mods enabled, those can end up in the server rules and lock everyone else out. If the first player creates the world with a bloated list, removing it later is harder because shared content may already be written into saves and world objects.

Only turn on enforced settings when the settings matter for shared behaviour. The upside is consistency: the server can stop people joining with different required-mod configs. The downside is that players lose local control over those config files. For mods that are mostly cosmetic or interface-only, that strictness is usually unnecessary.

If your host has a Mods page, use it as a rules editor

Some hosts provide a Mods page that manages both the Steam Workshop collection and the RimWorld Together rules. In that case, the safe order is simple: stop the server, install the chosen mods, mark each one as Required or Optional, drag rows into the intended load order, then start the server again.

Stopping the server first matters because you want one clean rules update, not a moving target while people are joining. Changing the list or order mid-session can leave clients comparing themselves against stale state, and the next refusal can look random when it is really just bad timing.

If you are managing the standalone server directly, these are the folders that matter:

Configs/
  ServerConfig.json
  ModConfig.json
  BackupConfig.json
  DifficultyConfig.json
Assets/
  Saves/
  Users/
  Maps/
  Sites/
Backups/
  Servers/
  Users/
Logs/

Configs/ModConfig.json is the rule list. The server still does not need the actual Workshop mod files locally, because it never loads them. That is why a good control panel is mostly about clean rule management, ordering and backups rather than raw hardware. If you are still choosing one, our RimWorld server hosting comparison is the practical place to start.

Get every player to match exactly

Once the rules exist, your real admin job is distribution. Share the Workshop collection and the exact load order, not just a list of names. If order is enforced, “close enough” does not count: the server stores a hash of the full order and compares that hash with the player’s current order.

That strictness exists for a reason. In RimWorld, later mods can patch or override what earlier ones defined, so two players with the same mods in a different order can end up with different versions of the same item, building or faction. In a shared world that shows up as trades, caravans or visits that behave differently on each side.

The client helps if Steam is running. Players can be offered Do you grant permission to automatically download all mods? If Steam is not running, they will see Steam must be running for mods to download automatically or Allow the mods to download and click when ready, so the manual part becomes their job.

If you enabled settings enforcement, players may get The server enforces custom configs, apply?. Accepting that replaces the local Mod_ settings files for the required mods with the server copy. The server compares settings as a hash, so even one changed option counts as a mismatch. The trade-off: players lose their local tweaks for those mods, but you get far fewer “it works on my machine” joins.

If you enforced order, players may get The server enforces custom mod order, apply?. That writes ModsConfig.xml to match the server order. Again, the trade-off is flexibility versus stability. You can tell the fix worked when the player joins without the Mod Conflicts window and the server stops logging mismatch lines for that user.

Changing mods on a live world: safe order and admin tools

Once a world exists, change the list only from an admin account. First, join once so the server creates your account. Then promote that username in the server console:

deeplist
op <username>

The current code uses the username shown in deeplist. After that, enable RimWorld dev mode in the client and use the Esc menu entry Manage mods for the server.

The safe order for a live world is:

1. Back up the server.
2. Change the list as an admin.
3. Tell players to update before they next join.
4. Test with a non-admin account.

Useful server commands:

modlist
togglemodbypass
backup
getversion

modlist shows the current Required and Optional sets. backup gives you a restore point before risky edits. Backups are stored under Backups, and when automatic backups are on, the server also creates one at each launch. That costs disk space, but it is much cheaper than trying to salvage a broken world after removing content mods.

Adding an Optional mod is usually the least risky change because it should not alter shared save data. Adding a Required mod is stricter: every player must install it before their next join, and settings or order may need to be applied too. Removing Required content mods is the dangerous one, because items, buildings, factions or planet objects created by that mod may already exist in the save. Back up first, and be ready to restore that backup if colonies or planet objects break once the mod is gone.

If a non-admin tries to send a new mod config after the world exists, the server bans that player. That is deliberate protection. Otherwise any client could redefine the shared rules for everybody else and quietly poison the save.

Why “it works for me” often means nothing

Admins are exempt from the three world-exists mod checks: conflict, config and order. That is useful for recovery, but it also makes admins bad witnesses for normal-player problems. If you can join and your friends cannot, the first question is not “what is wrong with them?” but “am I only getting in because I am exempt?”

Always verify a change with a non-admin account. That is how you prove the rules are actually correct rather than merely bypassed, and it takes a minute compared with an evening of guessing.

togglemodbypass is a diagnostic tool, not a fix. It flips AllowAllMods and saves it, which tells you whether the underlying problem is truly a mod mismatch. If a player can join only while bypass is on, your network path and account are probably fine and the real issue is still the list, settings or order.

Do not leave bypass on. It lets clients join with missing content or mismatched configs, which is how desyncs and save corruption start. If someone sees Potentially incompatible mods found … Do you wish to continue with them anyways? … Mods won’t be checked for the remainder of the session, treat that as a warning that normal protections are no longer doing their job.

Versions, DLC alignment and basic connection checks

The RimWorld Together client and server release must match. Check the client version in the top-left of the main menu and compare it with the server console command getversion. Update both together; updating only the Workshop mod on players’ PCs or only the server binary is a reliable way to create confusing login failures.

RimWorld Together currently supports RimWorld 1.6 and 1.7. That does not mean every mixed setup is wise. Keep the game version, the RimWorld Together release and the group’s DLC baseline aligned as one change set, not as separate experiments.

If you are running a server on your own PC, do not confuse a networking problem with a mod refusal. The server IP field is 0.0.0.0; local clients connect on 127.0.0.1:25555; internet players need your public IP and forwarded TCP 25555. A genuine mod problem refuses the login after connection, while a port problem stops the connection being established in the first place.

Troubleshooting refused logins in the real check order

Once a world exists, the server checks players in a fixed order after account, password and ban checks: first mod conflict, then required-mod settings if enforcement is on, then load order if one is stored. Follow that order yourself and you stop chasing the wrong symptom.

If you need a quick decision rule: first make sure the player has no extra unlisted mods, then make sure every Required mod is present, then apply enforced settings, then apply enforced order. That is the same sequence the server uses, so it is the shortest path to the real fault.

RimWorld server mods FAQ

Do RimWorld Together servers need the mods installed on the server?

No. The server is a standalone program and does not run RimWorld or load Workshop mod files. It stores a rule list in Configs/ModConfig.json and checks each joining player’s active client setup against that list.

Why does RimWorld Together say my mod list conflicts with the server?

That message appears when the first mod check fails. Usually the player is missing a Required mod or has an extra mod enabled that the server did not list as Required or Optional. The server log will show [Mod mismatch] > name for the mod it objected to.

Can players use different mods on the same RimWorld server?

Yes, but only for mods the server marks Optional. Those should be genuinely client-side changes such as UI or visual tweaks. Any mod that adds shared content should be Required so every client loads the same world data.

How do I add a mod to an existing RimWorld Together world?

Promote an account with op <username>, join as that admin, enable dev mode, then use Manage mods for the server. Back up first, especially if the mod adds or removes world content. Optional additions are usually safer than Required removals.

Do RimWorld Together and the server need the same version?

Yes. Check the client version in the top-left of the main menu and compare it with the server’s getversion output. Update the client mod and the server release together so the protocol and checks stay aligned.

More RimWorld server help

Compare RimWorld Together hosts with easy mod management and backups.