Project Zomboid Dedicated Server Update: Stage It Safely

A Project Zomboid dedicated server update should reach the live world only after the same-branch patch passes your checks on a separate copy. Record the exact build, preserve the closed server data, and test a matching client, required mods, a save-and-restart cycle, and your return path before promotion. This is a reader-run checklist: I did not update a server or test a client, mod stack, save, or rollback for this guide. If a check is unknown or fails, leave the live instance on its current build.

If you have not yet confirmed that your group can join the chosen Build 42 server, use the Build 42 multiplayer readiness checklist first. This update procedure assumes you already have a compatible, working branch and begins with its current build record.

Confirm the installed and target server build#

Write down the full server build, branch, storefront, and target release before you schedule maintenance. The official Project Zomboid news page currently labels Build 42.21 as both Stable and Unstable; the September 28 release post describes 42.21 moving from Unstable to Stable. Recheck the current news page and the 42.21 Stable announcement when you plan a later update. A current label is not a promise that the next patch is harmless to your world.

Record before changing anything	Why it matters
Full server version and selected branch	“Build 42” does not identify a specific patch or channel
Dedicated-server package source	Steam and GOG do not necessarily expose incremental updates at the same time
Client storefront and version for each tester	The test client must match the server target
World name and last known build	A world should not be opened by an older or different branch as a rollback experiment
Planned target and release-note date	Lets you distinguish a same-branch patch from a branch switch

The official FAQ notes that some fast incremental patches may reach GOG later than Steam. If a group uses more than one storefront, compare the exact build each player can install rather than assuming everyone sees the same update. For a branch decision or package-level SteamCMD background, use the Build 41 versus Build 42 guide and the SteamCMD install reference. This checklist starts after your group has already chosen its branch.

Keep game-package and Workshop changes separate#

Treat the dedicated-server package and Workshop revisions as two maintenance jobs. A game patch changes the server program; a mod update changes content that may have its own build support, dependencies, or multiplayer behavior. Combining both in one restart can make a failure difficult to trace.

Before the window, export or write down the Workshop item IDs, required dependencies, and the revision or update date shown for each essential item. Record any server-side mod IDs and map order as well. If a mod is a requirement for the existing world, do not remove it just to make the updated server start. Check the author’s notes for the target build and multiplayer support, then stage a mod change separately using the Build 42 server-stack audit.

Keep a maintenance note with two separate entries:

Change	Record
Game package	Current and target branch/build, package source, update date
Workshop content	Item IDs, dependencies, displayed revisions, and any planned change

If the server must download a mod revision to start, note that as a dependency of the package test rather than silently updating the whole collection. A successful download is not evidence that a mod works on the new build. Leave all nonessential mod changes for another window so a failed test has fewer possible causes.

Capture a consistent pre-update return point#

A copied folder is a precaution, not a proven recovery. Stop the server cleanly before copying so the world database and player files are not changing while you capture them. Include the multiplayer world, player data, server configuration, and the mod manifest for the exact server name and installation you are updating.

1. Agree on the maintenance window

   Tell players when the server will stop and ask them not to join during the update. Record the world name and last successful save so you can compare the same starting point later.

2. Stop the server cleanly

   Use the shutdown method documented for your current server installation. Wait for its normal save and exit rather than killing the process while it is writing.

3. Copy the complete recovery set

   Copy the server data and configuration to a separate location outside the live install. Keep the original package version and branch noted beside the copy; do not rely on a client-side save as the server backup.

4. Check the copy before continuing

   Confirm the expected world, player data, settings, and mod list are present. If you cannot identify the complete server data set, stop here and ask the server host or consult the exact installation documentation.

The official Build 42 transition notes state that Build 41 saves are not compatible with Build 42; copying a world does not convert it. Keep a branch change out of this same-branch procedure.

Update a disposable copy on the chosen branch#

Run the first update against a separate copy of the server installation and world, using the same branch and package source as the live setup. Keep the original stopped and untouched. If the installation uses SteamCMD, follow its existing app and branch configuration; the published SteamCMD install reference explains the package-selection context. Do not paste a beta-switch example from an old guide into a same-branch patch, and do not assume a generic update command selects the branch you intended.

1. Duplicate the existing server setup

   Create a staging instance with its own server-data path and ports, then restore the pre-update copy there. Keep the live server stopped so the two instances cannot write to the same world.

2. Confirm the staging branch before updating

   Compare the staging branch and current build with the record from the live instance. If the update screen or command would switch channels, cancel and correct the selection first.

3. Apply the package update to staging

   Use the package source’s documented update action for that existing branch. Watch the installer output for the completed build and any failed validation or missing files.

4. Start staging without opening the live world

   Confirm the staging process reports its ready state and points to the staging data directory. If it reads the live world path or reports a different branch, stop before a client joins.

A hosting panel can use provider-specific names for reinstall, update, branch, and startup settings. Read the instructions for the exact service and plan, and record the selected values before applying them. A panel button that says “update” does not prove which build it installs, whether it changes branches, or whether it updates Workshop items too. Never test a new package by letting it open the only copy of a long-running world.

Check startup, a matching-client join, and persistence#

Use a compatible client on the same target branch and exact build shown by staging. First verify the server reaches its normal ready state. Then have one authorized tester join, confirm any required mods load, perform a small representative in-game action, and leave normally so the world can save. Restart staging and join again to check that the expected state persists.

Acceptance check	Pass evidence to record	Defer if
Startup	Expected server build and normal ready message	Startup loops, reports a different build, or stops on a mod error
Client join	One authorized client joins the staging address	Client reports a version mismatch or cannot complete the join
Required mod behavior	Each essential feature used in the test behaves as expected	The mod is unsupported, errors, or was not checked
Persistence	The test action remains after a clean save, stop, and restart	The action disappears or the world fails to reload
Return path	A separate restore test opens the untouched pre-update copy on its recorded compatible branch	Restore is untested, data is incomplete, or the old package cannot use it

A version label alone is not a successful test. The official 42.21 Unstable announcement recommended a manual backup before testing that release and described a limited compatibility note for 42.20.4 saves. That statement applies to the versions named there; it does not guarantee that another patch, mod set, or storefront combination will preserve your world.

Do not combine this acceptance pass with Workshop updates unless that dependency itself is what you are testing. Keep the test note: branch/build, client storefront/build, mod revisions, startup result, join result, persistence result, and return-path result. If you cannot run a compatible client, mark the join unknown rather than calling the update ready.

Choose whether to promote or postpone#

Promote only when every required row is a pass and you have an actual return path for the old server and its data. Leave the live instance unchanged if any result is unknown, a client cannot join, a required mod fails, or the test copy does not reload after restart.

Result	Decision
Staging package starts on the intended branch; client joins; required content works; save persists; return copy restores	Schedule promotion and repeat the recorded package update on the live instance
Startup works but the compatible-client join was not attempted	Defer; the update has not passed multiplayer acceptance
Workshop content changed at the same time	Isolate the two changes and repeat the test with a frozen mod manifest
Recovery copy is incomplete or has not been restored	Defer; a copy is not proof that you can return
A branch change is required	Stop and follow the branch-choice and compatibility process; do not treat this as a same-branch patch

Keep executable rollback and world restoration separate. Reinstalling older server files does not make a save written by a newer build compatible with them. If the staging build has already written to its world, restore a separate pre-update copy before testing older binaries; do not attempt a downgrade on the only live save. The evidence here is a reader-run decision process, not a tested recovery outcome.

Keep the next maintenance window reproducible#

Save the result with the server’s exact name, package source, branch, build before and after, date, client storefront/build, mod revisions, and links to the release notes you checked. Keep that note beside the backup location, but do not store passwords, tokens, or player identifiers in it. A future patch can change the target or the compatibility warning, so recheck official news before you schedule it.

For a later maintenance window, compare the new release against the same acceptance list rather than assuming the previous patch proved the next one. A branch change belongs in the branch-selection guide; a client that is already out of step belongs in the version-mismatch guide when available. Mod revisions need their own isolated test. That separation helps you identify what changed without implying that a particular build, mod set, host panel, or rollback path has already passed.

Quick answers

Do clients and dedicated servers update at the same time?

Do not assume they do. Check the exact patch available from each storefront and compare the full client and server builds before inviting the group.

Can a same-branch patch affect saves?

The branch name is not a save-compatibility guarantee. Keep a separate copy and check the release notes and your own acceptance results before promotion.

Should every Workshop item update in the same window?

Keep game-package and Workshop changes separate when possible. That makes it easier to identify which change caused a failed test.