Project Zomboid Build 42 Goes Stable Tomorrow: What to Do With Your Server First

Build 42.20 goes to the stable public branch tomorrow, Wednesday 29 July. The Indie Stone put it plainly in their announcement: "Project Zomboid version 42.20 will be coming direct to the stable public branch Wednesday, the 29th of July." Direct to stable, not to unstable first.

If you run a Zomboid server with a world you care about, read the next section before you do anything else.

Your LOW.MS server is not going to update itself

This is the bit that matters most and it's the bit nobody else will tell you, so let's get it out of the way early.

Project Zomboid servers on our platform don't auto-update. There's no update-on-start step in our template for PZ, unlike some of the other games we run. I checked a customer server this morning that has a daily scheduled restart and it's still sitting happily on an April build. It has restarted about sixty times since then and never once pulled a new version.

So nothing happens to your server at midnight. You will not wake up on Wednesday to a fresh world and a lot of angry Discord messages.

The risk is different, and it's this: the update happens when someone clicks the button. Steam Update, or a reinstall, or asking us to update you. That's the moment your Build 41 world stops being loadable. If that happens before you've taken a backup, you're in a much worse position than if you'd just left it alone.

Which means you have time. Not loads of it, but enough to make a decision rather than have one made for you.

What actually happens to a Build 41 world

Straight from the announcement: "Build 41 savegames clearly will not be compatible with Build 42."

Worth being precise about what that means, because "you lose your world" is doing a lot of work in most of the coverage I've read. Your files don't get deleted. The save folder sits there exactly as it was. What happens is that B42 can't read a B41 world, so the server shrugs and generates a new one. Your old world is still on disk, it's just not something the new build knows how to open.

That distinction matters because it's the difference between "gone" and "recoverable". Roll the server back to Build 41 and the world loads again. But only if you haven't let anything overwrite it in the meantime, which is why the backup comes first.

Same story if you've been playing on unstable, by the way: "Due to additional content being added, existing saves on Unstable 42.19 will not be compatible with 42.20." A 42.19 run is in the same boat as a B41 one.

Back up before you touch anything

Do this tonight, whichever option you pick. It takes a couple of minutes.

Cloud Backup in the LOW.MS Control Panel is the quickest route, and Backup Manager handles local backup files if you'd rather keep one on the box. If you want a copy off the server entirely, pull it over SFTP on port 8822.

The things worth having a copy of:

• Zomboid/Saves/Multiplayer/<servername>/ is the world itself. Unless you renamed it, <servername> is servertest.
• Zomboid/Server/ holds your .ini and your sandbox settings.
• Zomboid/db/servertest.db is your player and account database. People forget this one and then wonder why everyone lost their admin rights.

B42 does ship a BackupsOnVersionChange option in the server config, which sounds like exactly what you want here. I wouldn't lean on it. The patch notes during the unstable cycle mention dedicated server backups being incomplete compared to B41, and that got worked on over several releases. Treat it as a second line of defence behind a backup you took yourself.

Three options, pick one tonight

Take Build 42 and start fresh. Back up, update, accept the new world. The map is roughly twice the size it was, with reworked versions of Riverside, West Point, Rosewood and Muldraugh, and basements underneath a lot of it. Around 400 procedural ones plus a set of hand-built ones. Here's the thing that should push you one way or the other: none of that appears in an existing world. New map, new basements, fresh start only. If your group has been eyeing B42 anyway, this is the natural moment.

Stay on Build 41. Pin the server to the legacy41 branch and get every single player to do the same in Steam. One person on the wrong branch is one person who can't connect. Worth knowing that the devs updated legacy41 on 21 July, a week before the switch, while the public branch hasn't moved since April. They built the escape hatch on purpose and they've kept it current. This is a supported path, not a hack.

Finish your 42.19 run. If you've got a group mid-campaign on unstable, pin to 42.19 and play it out. Treat it as a wind-down rather than a home, because you're on a branch that isn't going anywhere new.

If you're genuinely torn, the question I'd ask is whether your current world is worth more to your group than the new map is. There's no wrong answer, but there is a wrong time to decide, and that's after you've clicked update.

The branch names, and one trap

Two things to flag on that table.

public changes meaning overnight. Anyone who thinks of it as "the safe one" is about to get a surprise, because it's the same branch name pointing at a completely different build.

And be careful with outdatedunstable. An earlier Indie Stone blog named it as the place to go for 42.19 saves, then a later post changed that to the 42.19 branch. Both branches exist right now and they are not the same build. If you want to keep a 42.19 world, it's 42.19 you want. I've seen the old name repeated in a few places already this week.

Switching branch on a LOW.MS server

Your server's version is set through a version field that feeds SteamCMD a branch name, so switching means setting it to legacy41 or 42.19 rather than leaving it on the default. If you're not sure where that lives on your service, open a ticket and we'll pin it for you. Honestly, for something this consequential I'd rather you asked us than guessed.

Players switch on their own machines: right-click Project Zomboid in Steam, Properties, then the Betas section, and pick the matching branch. Everyone has to match. There's no partial credit here.

One thing I'd specifically avoid: don't assume the "Switch to Unstable" style buttons take a backup of your save on the way through. Take your own.

Mods: assume you're starting from zero

Plan for your entire mod list being broken and be pleasantly surprised if some of it isn't. The Indie Stone's line when B42 multiplayer landed was "Much has changed under the hood. Please be patient with the modding community while they update to make their mods compatible." There's a whole migration guide for authors because the identifier and registry system changed underneath them.

Now here's the part that catches people out, and it's genuinely nasty.

Workshop IDs don't care about game versions. SteamCMD will happily download every single one of your B41 mods onto a B42 server. The update succeeds. Nothing errors, nothing warns you, the console looks fine. The failures show up later, at world load and when players try to join.

And if you're running with Lua checksum validation on, which is our template default, a mismatch between what the server has and what the client has means clients get kicked. So a half-updated mod collection doesn't degrade gracefully, it locks your whole playerbase out at once.

My advice: strip the mod list back to nothing for the first boot on B42. Get vanilla running, confirm people can connect, then add mods back a few at a time and restart between batches. It's slower and it's much less painful than bisecting a broken collection while twelve people wait.

While you're in there, your sandbox settings changed

If you've got a carefully tuned sandbox config, don't just paste it into B42 and assume it carried over. The sandbox file format moved on, and the loot settings in particular were reworked rather than tweaked.

The old per-category loot settings used a small numbered scale. B42 replaces them with renamed keys that take a decimal multiplier instead. Copy an old value across and it either gets ignored or does something wildly different from what you meant, with no error either way. Zombie count, the zombie lore block and the water and power shutoff timers all survived unchanged, so it's not everything, but the loot section needs redoing from scratch.

We'll do a proper write-up on the new sandbox settings once 42.20 has actually landed and we've had a look at the real file rather than the unstable one.

Tonight's checklist

• Take a backup. World folder, server configs, player database.
• Decide: B42 fresh, stay on B41, or finish your 42.19 run.
• If you're staying put, pin the server and tell your players which branch to select. Do this before Wednesday.
• If you're going to B42, clear the mod list first and rebuild it after.
• Budget a bit more disk. The install is roughly a third bigger and worlds will grow faster on a map this size.

If any of this is unclear for your specific setup, open a ticket. We'd much rather spend ten minutes pinning a branch for you tonight than an hour trying to recover a world on Thursday. Our Project Zomboid hosting plans are all on hardware that'll handle B42's extra weight fine, but the thing that saves your world this week is a backup, not a bigger server.

Related reading while you're deciding: our getting started guide, the server configuration guide and where your saves live.