It's the most reliable way a healthy Build 42 server dies: everyone plays Tuesday night, a mod author ships an update on Wednesday morning, and by Wednesday evening nobody can join. No crash, no error on the server side — the server is running fine. It's just running last week's version of a mod that every player's client has already updated past.
This isn't a bug in your setup. It's how Project Zomboid's Workshop integration works, and once you understand the mechanism, the fix — and the way to stop it recurring — is straightforward.
Why a mod update locks everyone out
Three facts collide:
- The server downloads Workshop mods at startup, and only at startup. When a B42 server boots, it checks each ID in
WorkshopItems=and pulls the current version. Then it never looks again until the next boot. - Players' clients update mods automatically, almost immediately. Steam pushes Workshop updates to subscribers in the background — your players get the new version the moment they restart their game, whether they wanted it or not.
- The game refuses version mismatches. A client with mod version B connecting to a server with version A is rejected — usually as a kick during loading, or a join that hangs and drops.
So the window between "author clicks publish" and "someone restarts the server" is a window in which the server drifts out of date, one player at a time, as each of them restarts their game. There is no version pinning on the Steam Workshop for Project Zomboid — you can't hold a mod at last week's version by ticking a box, and neither can your players.
The fix: restart the server (properly)
A restart makes the server re-check every Workshop item and download whatever changed. That's the whole fix for the common case:
- Warn anyone still connected:
servermsg Restarting for mod updates in 5 minutesfrom the console. - Save and stop cleanly —
save, thenquitat the server console (or the stop/restart button on a hosting panel, which does the clean-shutdown sequence for you). Killing the process instead is how worlds corrupt. - Start it again and watch the boot log — you'll see the Workshop items being verified and the updated mod re-downloading.
Players reconnect, versions match, everyone plays.
When a restart doesn't fix it
Sometimes the update itself is the problem — the author shipped a bug, or the new version broke a dependency. The tells: the server boots but spams Lua errors, or players get in and things misbehave (missing textures, broken UI, errors popping).
- Check the mod's Workshop comments first. If the update is broken you will not be the first to notice — the comment section fills up within hours.
- Read the errors before guessing. errorMagnifier surfaces Lua errors properly instead of the silent red blobs, which usually names the failing mod directly. Decoding boot-time errors is covered in the mod load-order guide.
- Removing a mod mid-save is a last resort. Pulling a mod out of
Mods=on an existing world means items and structures from that mod vanish from the save. Take a backup first, tell your players what will disappear, and if the mod is load-bearing (a map mod, a big overhaul), consider waiting for a hotfix instead — broken popular mods usually get one within a day or two.
Making it stop happening at 9pm
You can't stop mods updating. You can control when your server catches up:
- A nightly scheduled restart moves the problem to 4am. If the server restarts every night at a dead hour, it picks up whatever updated that day before anyone tries to play. This is the single highest-value habit for a modded server — it also clears the Java heap creep that long-running B42 servers accumulate.
- Warn before restarting. A
servermsga few minutes ahead is the difference between "scheduled maintenance" and "the server just kicked me mid-loot-run". Panel schedulers can chain the warning and the restart for you. - Keep the mod list deliberate. Every mod is a subscription to its author's release schedule. Ten well-maintained mods break far less often than sixty scraped from a "top 100" video — and when something does break, ten is a diagnosable list. Our verified B42 server mod list is a good starting shape.
- Back up before mod-list changes. Adding and removing mods is when saves get hurt. A backup that exists is the entire difference between an annoying evening and a dead world.
For the self-hosting crowd: the Steam Web API exposes each Workshop item's time_updated, so a cron job can poll your mod list, compare against what the server booted with, and trigger the warn-then-restart sequence automatically. That's exactly the mechanism managed panels automate — if you're self-hosted, it's an afternoon of scripting; the polling endpoint is IPublishedFileService/GetDetails (or ISteamRemoteStorage/GetPublishedFileDetails) and the restart side is the same servermsg → save → restart chain as above.
Frequently Asked Questions
Can I stop a Workshop mod from updating?
Not through Steam — the Workshop has no version pinning for Project Zomboid. The workaround is copying the mod's files out of the Workshop folder into the server's local mods/ directory so it loads as a local mod, frozen at that version — but then your players still auto-update, and you've recreated the same mismatch in the other direction. For most servers, catching up promptly beats freezing.
Do mods update while the server is running? The server only downloads at boot, so a running server never changes mid-session. The danger window opens when clients update and the server hasn't restarted yet.
Will players lose progress from a mod-update restart?
Not if the shutdown is clean — save then quit (or a panel's restart button) writes the world before stopping. Progress loss comes from killed processes, not restarts.
How do I find out which mod updated? Each Workshop page has a "Change Notes" tab with timestamps — sort your subscriptions by recently updated, or check the boot log: the re-downloaded item is logged during Workshop verification at startup.
On our Project Zomboid hosting, the restart chain above is a built-in schedule — nightly restart with an in-game warning first — so mod updates get picked up at 4am, not discovered at 9pm. Mods themselves install from a Workshop search in the dashboard, no ini editing.