Steam Workshop collections on a server, without the mismatch

Steam Workshop integration is the reason modded servers are approachable at all — and it was designed for one person modding their own game, not for keeping thirty people in sync with a server. Most of the pain comes from that mismatch.

These four habits remove nearly all of it. They apply across DayZ, Project Zomboid, ARK, Conan Exiles, Squad, Arma and everything else that uses the Workshop.

1. Use one collection, and make it the source of truth

Do not maintain a list of mod IDs in a config file and a collection your players subscribe to. They will drift, and the drift is invisible until someone cannot connect.

Create a public Workshop collection, put everything in it, and point both the server and your players at that. On our plans you give the panel a collection ID and we resolve the contents — so adding a mod to the collection is the only action needed.

2. Pin versions before a wipe or an event

The Workshop auto-updates. That is fine on a Tuesday and catastrophic an hour before a scheduled event, because a mod author can push a breaking change with no warning and your server will happily pull it on the next restart.

Pin the versions for anything you are relying on. We hold the pinned copies server-side, so a mod updating upstream does not change what your server runs until you decide it does.

Unpin after the event, take the updates, test, move on.

3. Announce the list somewhere durable

A pinned Discord message with mod names and version numbers, updated when you change something. Not a message in general chat three weeks ago.

Half of all "I can't connect" tickets are a player with one wrong version, and the fastest route to solving it is a list they can check against without asking you.

4. Change one thing at a time

Adding six mods at once and finding the server will not boot leaves you with six suspects. Adding them one at a time, restarting between, means you already know.

This feels slow. It is much faster than the alternative.

Game-specific traps

DayZ — the mod list also has to be in the server's start-up parameters, and the -mod= order matters for some mods. Map mods need their mission folder set separately; adding Namalsk to the collection without changing the mission does nothing.

Project Zomboid — you need both the Workshop ID and the Mod ID, and they are different things. The Workshop ID is the number in the URL; the Mod ID is defined inside the mod. Getting one right and the other wrong produces a server that starts and silently ignores the mod.

ARK — mod order matters when two mods modify the same thing. Cluster servers need identical lists on every map or transfers break.

Conan Exiles — players get a load-order mismatch warning that is often ignorable and occasionally is not. Publishing the intended order helps.

Arma 3 — Workshop mods need both server-side installation and the client-side collection, and the server will reject players whose signature check fails. That is a feature, but it makes version discipline non-optional.

When a mod update breaks the server

It will happen. In order:

1. Check the console. A failed mod load almost always says so explicitly in the first thirty seconds of start-up.
2. Roll back the mod, not the server. Pinning the previous version usually gets you running again immediately.
3. If the save is damaged, restore last night's backup. Off-node, fourteen days, two clicks.
4. Tell your players what happened. People are remarkably tolerant of downtime they understand and intolerant of silence.

What we do about it

Version pinning, automatic rollback if a mod update stops the server booting, and collection sync are on every plan that supports Workshop content — not an add-on and not limited to the expensive tiers.

That is not generosity: a broken mod update is a support ticket either way, and it is cheaper for us to prevent it than to spend an hour in SFTP with you at midnight.