Before updating Project Zomboid, stop the world cleanly and preserve a matched set of server files, persistent data, mods and launch settings. A copied save folder is useful, but it does not by itself let you roll back binaries or account database changes after the new build has written to them.
This procedure is for an existing Linux dedicated server updated manually through SteamCMD. If LinuxGSM, a container image or a panel owns updates, use that system's documented update path and the same recovery boundaries; do not introduce a second updater. At the 26 October 2026 check, the developer lists 42.21 as Stable, following its 28 September release.
Decide whether this is an update or a migration#
Record the actual version in the server startup log and the branch selected by its updater. Ask players to check their client branch and version too. The dedicated tool is Steam app 380870; the game client is 108600. Updating one does not update the other.
| Existing world | Decision before downloading |
|---|---|
| Current public Build 42 | Stay on public unless a specific change is planned |
| Build 41 campaign | Keep server and clients on legacy41; moving to B42 is a separate migration |
| Old Unstable 42.19 world | Developer notes explicitly say it is incompatible with 42.20; the 42.19 branch preserves that campaign |
| Another testing branch | Read the target release's save and mod compatibility notes first |
Do not make branch switching a side effect of routine maintenance. A branch name also does not pin one immutable patch forever. Check what Steam currently makes available before promising that the old version can be downloaded again.
Capture the instance, not just the map#
Record the service user, its home, selected -servername, working directory and complete launch command. Include any absolute -cachedir, heap overrides, environment variables and supervisor configuration. By default the user's Zomboid root contains settings, saves, account databases and logs; a custom cache root moves persistent state elsewhere. Capture every root actually used by this instance.
Announce the interruption, stop new joins and suspend restart/update schedules. Send save and then quit through the existing server console. Wait for shutdown and confirm the supervisor has not started another process. A shell returning from a wrapper is not enough if a detached server is still writing.
Create independent, dated copies outside both the installation and live data directories:
- The complete dedicated-server installation, including its Steam metadata and customised launch files.
- The entire persistent
Zomboidroot and any external data paths or mounts, retaining permissions and ownership. - Installed Workshop/manual mod content, dependencies and the configured mod/map order. Workshop content may be inside the install tree or another Steam library; follow the actual paths.
- The launcher, supervisor configuration and a short record of the old build, branch and mod versions.
Ensure enough free space for download and recovery, inspect the copied directory tree, and verify that it can be read. A filesystem snapshot must include every relevant mounted volume; a snapshot of only the operating-system disk may omit the world. Retain the stopped copy unchanged until the update has passed acceptance.
Update the existing installation on its intended branch#
Run SteamCMD as the account that owns the installation. The following is an example for a server already on the public branch, whose verified existing installation is /srv/pz/server:
steamcmd +force_install_dir /srv/pz/server +login anonymous +app_update 380870 +quit
Replace /srv/pz/server with the absolute directory containing your existing start-server.sh. Do not create a second installation accidentally and then continue launching the old one. Do not apply this public-branch example to a retained beta campaign.
For an existing Build 41 campaign intentionally kept on the developer's legacy41 branch, the corresponding branch-specific example is:
steamcmd +force_install_dir /srv/pz/server +login anonymous +app_update 380870 -beta legacy41 +quit
Choose one applicable command, not both. These commands update installation files; they neither copy your persistent data nor set your service's launch arguments.
Routine updates do not need validate added reflexively. Validation checks shipped files and can restore customised distributed files. Keep local launch modifications in a documented override where possible, then compare them after any update. Never blindly copy an old launcher over the entire new launcher: retain the new runtime/dependency setup while reapplying the specific required settings.
Keep the first start restricted#
Start once through the normal supervisor with the original service user, data root and server name. Keep regular players out while checking startup. Confirm the reported game version, selected world, loaded mods and database messages. SteamCMD completing successfully proves neither that this process uses the updated directory nor that clients can join it.
Update the test client's selected branch, confirm its actual version, and verify a representative existing account and character. Check a known construction, inventory and relevant mod feature. Save, shut down cleanly, restart, and confirm those changes persist. A working process and open port are preliminary checks; admission and world persistence need their own acceptance.
If startup now fails, inspect its first meaningful error. A documented 42.20 support case traced a failure to a relative -cachedir; preserve the intended data location using an absolute path rather than wiping saves. For a mismatch, compare actual client/server versions and which executable the supervisor launches. Do not delete app manifests or databases simply because one forum participant did so.
When you maintain this workflow on your own infrastructure, Nexardo can help organise administration of the machines. A successful infrastructure action still needs the game checks above before reopening the campaign.
Roll back the matched set if acceptance fails#
Stop the new process, disable automatic restarts and preserve its logs separately. Restore the pre-update installation together with its stopped persistent data, mod content and launch configuration; retain ownership and the original instance paths. Do not merge old and newly written world files.
The old clients must be compatible again too. If the required client build or mod version is no longer obtainable, the server backup alone cannot guarantee an immediately playable rollback. Keep the failed attempt separate for diagnosis and reopen only after the restored world and accounts pass the same checks. Never test a downgrade against the only updated save.
Sources#
- The Indie Stone: 42.21 Stable and 42.20 release, legacy41 and 42.19 compatibility.
- LinuxGSM: app ID and instance paths and SteamCMD updater implementation.
- Maintainer's separate installation and persistent-data layout.
- Developer support: version mismatch and overwritten launch settings, absolute cachedir diagnosis.
