Your server updated to Build 42, started cleanly, and the log looks completely normal. Then the first player tries to join and gets thrown straight back out to the menu. Nothing in the startup output says a mod failed, because as far as the server is concerned nothing did fail – every Workshop item you asked for downloaded, and it downloaded fast.

That gap between "downloaded" and "actually works" is the whole problem with Project Zomboid mods right now, and it got a lot worse on 29 July 2026 when Build 42 went to the stable branch. We've been unpicking it in tickets ever since. There's now a Steam Workshop browser in the panel that does most of the fiddly part for you – with one thing you still have to correct by hand. That's what this covers, along with the two lines in servertest.ini you have to keep in step, and why a mod list that worked perfectly in Build 41 can take your server down without producing a single error message.

Installing a mod from the panel

Open your Project Zomboid service and you'll find three Workshop entries in the sidebar: Steam Workshop for searching and installing, Steam Workshop (installed) for what you've installed through it, and Steam Workshop (updates) for those items with a newer version waiting. There's also a Mods entry further down. The three Steam Workshop pages are the ones this guide is about.

Search or paste a Workshop link, click Install, and the panel adds the item to WorkshopItems= in servertest.ini and a matching entry to Mods=. Uninstalling from the installed list removes both in step – that half is genuinely clean. It works one item at a time, so a collection link isn't a single click here and you'll need to work through its contents individually.

Worth knowing that those two companion pages track what the browser installed, not what's in your ini. If you've been hand-editing WorkshopItems= for the last two years, Steam Workshop (installed) will sit there empty and that's expected, not a fault.

Two things about the timing. The panel doesn't download anything itself, it only adds the ID to the list, so the mod actually arrives on the next server start when Project Zomboid works through WorkshopItems= on its own. And because nothing is on disk until that start, you can't read a mod's internal ID until you've booted at least once.

That last point is where most of the tickets start.

The Mods= line needs correcting after an install

The panel writes the Workshop item's title into Mods=. Project Zomboid loads mods by the internal ID in their mod.info file, and those two strings are almost never the same. Install Jeeve's Claims and you get this:

WorkshopItems=3674013419
Mods=\Jeeve's Claims

What the game needs is this:

WorkshopItems=3674013419
Mods=\JeevesClaims

The download half is right. The load half is a title with a space and an apostrophe in it, and Project Zomboid will not find a mod by that name. It doesn't error, it just doesn't load, which drops you straight back into the silent failure this whole guide is about.

Workshop titles are shop-window copy. That's why this bites nearly every time. "Tsar's Common Library 2.0 [Only for B41]" is the item on the Workshop; tsarslib is the ID the server wants, and there is no rule anywhere connecting the two. Brackets, version numbers, exclamation marks – none of it belongs in a mod list.

So the sequence that works is:

Stop the server.
Install everything you want from Steam Workshop.
Start the server once and let it download the items.
Open File Manager and read the real ID out of each mod's mod.info. The next section covers where to look.
Stop again, correct Mods= in Configuration Files, and start.

A couple of sharp edges worth knowing while you're in there.

Read the whole Mods= line after each install, not just the entry you added. The panel rewrites both lines from scratch every time, and it adds a backslash to every entry that was already sitting there. So your first install leaves \ModName, the second turns it into \\ModName, and Project Zomboid stops finding it. Uninstalling anything tidies the line back up again, which is exactly why it looks intermittent. Installing the same item twice will also add it twice. If you want to see precisely what the installer did, it keeps a running log at Zomboid/Server/workshop_debug.log.

And keep the two lines the same length and in the same order, one entry each, if you want to keep using the buttons. They pair the two lists up by position, and the uninstall trims the longer line back to match the shorter one, so a mismatch doesn't just confuse it – you lose entries off the end. That matters the moment you hit a Workshop item containing three mods, which needs three entries in Mods= against one in WorkshopItems=. Once the lines are different lengths, manage that server by hand from then on.

The two lines, and why there are two

Project Zomboid splits mod installation across two settings in servertest.ini, and almost every problem people bring us comes from treating them as one thing.

WorkshopItems= is the download list. It's a semicolon-separated list of Steam Workshop IDs, and it tells the server which items to fetch before it boots. The server's own comment on that line spells out the format:

# List Workshop Mod IDs for the server to download. Each must be separated by a semicolon. Example: WorkshopItems=514427485;513111049
WorkshopItems=2544353492;3674013419

Mods= is the load order. It's a semicolon-separated list of internal mod IDs, each one prefixed with a backslash, and the order you write them in is the order the game loads them:

Mods=\P4HasBeenRead;\JeevesClaims

That backslash is a Build 42 change and it's worth pausing on. A Build 41 Mods= line has no backslashes at all. None. Hand one across to a Build 42 server and it loads nothing, silently, which is exactly the failure this article keeps circling back to. If you're carrying an old list over, that's the first edit to make, before you look at anything else.

Finding the two IDs

The Workshop ID is the easy half: open the mod's Workshop page and read the ?id= number off the address bar. It's also the number the panel has already put in WorkshopItems= for you.

The mod ID takes one more step, because a single Workshop item can contain several mods. Once the server has downloaded an item it lands in steamapps/workshop/content/108600/<workshop id>/mods/, and every folder inside that mods directory is a separate mod carrying its own mod.info file. Open one and you'll see something like this:

name=Jeeve's Claims
poster=poster.png
id=JeevesClaims
versionMin=42.14
description=Unified safehouse and vehicle claiming system with multi-claim support.
author=Jeeves
modversion=1.20

The id= value is what goes in Mods=, with a backslash in front of it. Not the name= – that's the Workshop title the panel filled in for you – and not the folder name of the Workshop item either. Those are the two wrong answers. If a Workshop page bundles three mods, you need all three IDs in Mods= and still only the one Workshop ID in WorkshopItems=.

That versionMin=42.14 line is new and it's the single most useful thing in the file at the moment, because it tells you the author has actually thought about Build 42. Mods written before the split often have no versionMin at all.

Four ways to get it wrong

An ID in WorkshopItems= but missing from Mods= downloads to disk and then sits there, never loading. This is the "I installed it and nothing happened" ticket.
The reverse, an ID in Mods= with nothing matching it in WorkshopItems=, never downloads at all. The load just skips it.
A Mods= entry that's a Workshop title rather than an ID, or an ID that lost its backslash, loads nothing. Same silence.
Dependencies listed after the mods that need them will break, because Mods= really is a load order. Library mods go first.

Editing the lines by hand

Both Project Zomboid config files are exposed in the panel, so you don't need an FTP client for this.

Log in to the LOW.MS Control Panel and open your Project Zomboid service.
Stop the server first. This isn't optional politeness. A running server owns servertest.ini and writes its own copy back out, so anything you save while it's up has a habit of disappearing later, and you'll swear blind the panel never saved it.
Click Configuration Files in the sidebar. servertest.ini is listed as Main Server Settings, and servertest_SandboxVars.lua as Game settings. Mods live in the first one.
Edit WorkshopItems= and Mods=, save, then start the server.

On the next start the server downloads anything new before it finishes booting, which is why a large mod list makes the first boot after an edit noticeably slower. Give it a few minutes before assuming it's hung – a long list is slow, not stuck.

One more thing worth knowing. Neither of those two lines is wired to a control in Service Settings, which means the panel can rewrite servertest.ini from its own template without them in it. If you've changed anything in Service Settings, come back and check both lines still say what you left them saying.

If you'd rather work in a local editor, SFTP is on port 8822 and plain FTP on port 8821. The login is your account's FTP user rather than anything per-server, and you'll find it under FTP Settings on your account page. For a two-line change I'd stay in the browser. For rebuilding a forty-mod list from scratch, a real editor is worth it.

File Manager in the sidebar is the other one you'll want, because that's how you go and read a mod.info file without downloading anything. Browse to steamapps/workshop/content/108600 and you can see exactly which Workshop items are on disk and what's inside them, which is a much faster way to audit a broken list than guessing from the Workshop pages.

Why a Build 41 list breaks on Build 42 without telling you

This is the one I end up explaining in tickets most weeks, so it's worth doing properly rather than working around.

SteamCMD doesn't know or care what game build a Workshop item targets. When your server starts and works through WorkshopItems=, it asks Steam for those IDs, Steam hands them over, and the download succeeds. Every single time. There's no compatibility check anywhere in that step, so a list of Build 41 mods on a Build 42 server produces a completely clean, completely successful update. Nothing in the log looks wrong. Nothing in the download went wrong.

What changed underneath is how a mod is laid out. A Build 42 aware mod carries version-specific folders, so on disk it looks like this:

mods/P4HasBeenRead/
    mod.info
    common/
    42/
    42.13/
    42.15/
    media/

common/ holds the shared assets, the numbered folders hold Build 42 code aimed at specific builds, and media/ is the old Build 41 layout kept around for anyone still on legacy41. A mod that was never updated has only the media/ folder and no 42/ at all. It'll still download. It'll still show up in your mod list. It just contains nothing that Build 42 can load.

Then DoLuaChecksum finishes the job. Our config template ships with it on:

# Kick clients whose game files don't match the server's.
DoLuaChecksum=true

That setting compares the Lua the client has loaded against the Lua the server has loaded, and drops the connection when they disagree. So the failure surfaces at the worst possible moment – not at update, not at boot, but the instant a real player tries to join. From the owner's side it looks like the server is fine and the players are broken. It's exactly backwards.

The most common version of this on a mixed group is simpler than a broken mod: one player is still on the legacy41 branch in Steam while the server is on Build 42, or their Steam hasn't pulled the updated Workshop copy yet. Same kick, same absence of a useful error.

Or stay on Build 41

Plenty of groups have a world they'd rather finish than abandon, and that's a completely reasonable call given Build 41 saves don't load on Build 42. The legacy41 branch is still published and still maintained, and the Indie Stone were explicit that server owners could move to it ahead of the launch.

The catch worth planning around is that every single player has to switch too. In Steam that's right-click Project Zomboid, Properties, then Game Versions & Betas, then pick legacy41. One player who forgets will fail the checksum and won't get in. Just the one. We can pin the server side for you, so open a ticket and we'll sort the branch out – and there's more on the whole switch in our Build 42 server checklist.

Rebuilding a mod list for Build 42

I wouldn't try to repair a Build 41 list in place. Start it again – it sounds like more work and it's genuinely less.

Take a backup first. Use Cloud Backup in the sidebar before you touch anything, because mod changes on an existing world are not always reversible. Removing a mod that placed items or buildings in the world can leave holes in the save that adding it back doesn't fully fix.

Then work in small batches. Empty both lines, start with your library and framework mods only, boot the server, and join it yourself. Once that's clean, add three or four mods, restart, join again. Yes, it's tedious. It's still faster than bisecting a forty-mod list after the fact, which is the alternative, and which I've watched people lose an entire evening to.

For each mod you're carrying over, check the Workshop page for an update after 29 July 2026, then check versionMin in its mod.info once it's on disk. A quiet author isn't a verdict. Nor is a missing versionMin – neither one proves a mod is incompatible. Check for Build 42 folders and the author's compatibility notes, then test the mod in a small batch before deciding whether to keep it.

One safety note that's specific to this game, and it's not the sort of thing you expect to be writing in a mods guide. In April 2026 the Indie Stone identified and banned a batch of Workshop mods containing obfuscated malicious code, and they patched the underlying hole. It's a decent argument for keeping your list to mods with active authors and visible update histories rather than pulling in whatever a two-year-old collection recommends.

Once you're running

Project Zomboid checks for Workshop updates on server start, so a restart is the update. Convenient. It's also the thing most likely to break a working server, because a mod author can push a change at any hour they like and your next scheduled restart will pick it up without asking you first. If you installed through the panel, Steam Workshop (updates) is where you can see what's pending before you restart into it.

If you're running a group that plays on a schedule, take the backup before the restart rather than after it. If a restart breaks a previously fine server and you haven't changed anything, a mod update is the first suspect, and Log Viewer in the sidebar is where you'll find which one. Search the startup output for the mod ID rather than reading it top to bottom.

Players need to restart their own game client too. Steam updates Workshop subscriptions in the background, and a client that's mid-session won't have picked up a new version, which puts it straight back into a checksum mismatch.

When it still won't behave

If you've rebuilt the list and players are still bouncing, the useful next steps are in our Project Zomboid troubleshooting guide, and the rest of servertest.ini is covered in the server configuration guide. If you haven't set the server up yet at all, start with getting started and come back here once it's running.

And if you'd rather not spend your evening on it, open a ticket with your mod list and the last hundred lines from Log Viewer. We've been through a lot of these since Build 42 landed, and the mod ID that's breaking a server is usually obvious to someone who's already seen it three times this week.

How to Install Mods on Your Project Zomboid Server (Build 42)