Project Zomboid Build 42 Multiplayer: Check Server Readiness

Project Zomboid Build 42 multiplayer is on Stable as Build 42.21, announced on September 28, 2026. Before your group joins, match the clients and dedicated server to the same current version, keep a Build 41 world on its compatible branch, and test required mods against the exact build. This checklist establishes the current status and a safe first session; it does not assume that every mod, host panel, or storefront is compatible. If you are selecting a paid plan, check the host’s Build 42 version and recovery controls alongside these client-readiness checks.

Confirm Build 42 multiplayer is on Stable#

Build 42.21 is the current Stable release as of September 28, 2026. The Indie Stone’s September 28 release announcement identifies 42.21 as Stable and describes multiplayer fixes, including work on zombie duplication and zombies disappearing after players leave and re-enter a chunk. The developers also say some issues remain on their radar. Stable gives your group a current public target; it is not a promise that every server, mod list, or long-running world will be trouble-free.

That matters because search results can lag behind releases. The official December 2025 multiplayer announcement described 42.13 as an Unstable stress-test build and gave temporary cautions about player count and mods. Those were specific to an earlier release. Do not use that page’s old limits as today’s Stable requirements. Read the current Project Zomboid news page again when you schedule an update, since a new patch can change the version you need.

This guide covers a Steam desktop group using a dedicated server. It does not establish cross-store, console, or cross-platform joining support. Check the exact game edition and join method for every player before you make a hosting decision.

For the routine package update after you have chosen a compatible branch, use the dedicated server update staging checklist to test a separate copy before touching the live world. If your group uses different desktop operating systems or asks about console cross-play, see the separate Project Zomboid cross-platform compatibility guide for what current official sources confirm.

Match the client and dedicated server before inviting players#

The server and every player’s client need to be on compatible versions. Build 42.21’s official notes mention a new notice for players who try to connect when their game version differs from the server. Treat that warning as evidence to compare the displayed versions, not as a prompt to keep changing branches until a join works.

Use a short release record before the first session:

Check	Record	If it does not match
Server	Exact version shown by startup output or the current host panel	Stop inviting players and confirm the selected branch and installed update
Each client	Exact version and selected beta branch	Have that player update or select the agreed branch before joining
Mod set	Workshop item IDs, versions if shown, and required dependencies	Compare the server list and client requirements; don’t remove items from a live world casually
World	The world name and the branch/build that last opened it	Preserve the original and test a copy before any transition

“Build 42” alone is too broad to be a useful version record. The already published Build 41 vs Build 42 branch guide lists the current Steam client and dedicated-server channels it checked, including public, unstable, and legacy41. Those channels are a snapshot of that inspection, not proof that a particular rental panel exposes the same choices. Ask the provider for the exact branch and version on your selected plan if you rent.

Keep a Build 41 world on its compatible branch#

Do not move a Build 41 save into Build 42 expecting the server to convert it. The Indie Stone states that Build 41 savegames are not compatible with Build 42 and directs groups that want to continue on 41 to Steam’s legacy41 beta channel. That restriction applies to the world, not only to the server executable: switching everyone to another branch does not turn the existing world into a compatible Build 42 save.

The practical choices are straightforward: keep the existing group on its compatible Build 41 setup, or start a separate Build 42 world after confirming everyone is ready for it. The official Build 42 transition notes document the incompatibility and the legacy41 selection. See the branch guide when the group still needs to choose which world to continue.

Keep the complete old world and its configuration separate from any new Build 42 files. A copied folder is a backup, not a conversion. If a host is involved, confirm which files its export includes and whether the destination can run the source branch before moving or canceling anything.

Protect a Stable world before testing Unstable#

Use a separate copy before you test an Unstable release. The official 42.21 testing post says existing 42.20.4 saves should not be affected by that update, but still recommends manually backing up an existing save before trying 42.21 Unstable. This is a narrow statement about the 42.20.4-to-42.21 test; it does not establish compatibility for every earlier build, modded world, or future update.

1. Record the current setup

   Write down the exact server and client versions, branch, world name, and mod list. Keep the record with the backup so you know what setup last opened the world.

2. Stop the server cleanly

   Ask players to leave, then stop the dedicated server through its normal control. Copying files while the server is writing can leave an incomplete archive.

3. Make and preserve a separate copy

   Use the host’s documented export or copy the complete server data set while it is stopped. Keep the original untouched and put the test copy in a separate location.

4. Test the copy on the target build

   Start only the test copy on the selected branch. Confirm the expected world loads, a client joins, and the world persists after a clean restart before you consider changing the live server.

Validate mods against the exact multiplayer build#

If your group has a candidate list already, use the Build 42 mod stack audit to record each revision, dependency, join result, feature check, and reload separately. This readiness checklist covers the broader pre-session setup.

Check each required mod individually, then test the complete set together. A generic “Build 42” label does not prove that a mod supports the current 42.21 version, multiplayer, or the server’s loading order. Read its current Workshop description and author updates for the exact build; note required dependencies and whether the mod must also be present on each player’s client.

Keep a small manifest with Workshop IDs, dependencies, and the date you last confirmed compatibility. On a disposable world, start the server, connect one client with the intended collection, and check the server log and in-game behavior. A clean start is only one test: a mod may load while a required feature or dependency is still missing. If a must-have mod has no current author statement or cannot pass the join test, leave it out of the permanent world until you can verify it.

The developers have continued multiplayer and modding work in the Build 42 updates. That is a reason to check current mod notes before each patch, not evidence that every older mod is now compatible. For purchase decisions, compare the group’s exact mod workload and required file controls in the Project Zomboid hosting buyer checklist; neither a plan description nor a player-slot count proves that your collection works.

Run a small multiplayer acceptance check#

Invite one administrator and one ordinary player before scheduling the whole group. Have both connect with the intended clients and mod set, then verify the visible server version, expected world, character entry, and one small persistent change. Stop the server cleanly, start it again, and confirm that the same world and change remain. Save the relevant log excerpt and your version/mod record.

This is a smoke check, not a load test. It can catch an obvious version mismatch, missing dependency, wrong world, or save path before friends spend an evening troubleshooting. It does not tell you how a larger group will perform after exploring a busy map. For a larger community, repeat the check with a representative group and workload instead of treating two successful joins as a capacity guarantee.

If the client gets a mismatch notice, compare exact versions and branches first. If the server stops during startup or the wrong world appears, preserve the log and the untouched copy before changing files. Avoid deleting configuration or world data just to clear an error; that can remove the evidence and the group’s progress at the same time.

Choose self-hosting or rental after the checks pass#

Self-hosting can be enough when one player can keep the server available, maintain the files, and handle updates. A rental is useful when the group needs the world online while that person’s PC is off or nobody wants to manage the host machine. Neither route makes an incompatible save compatible or guarantees a mod will work.

Before renting, ask for the exact current branch, server build, mod controls, and a complete way to export the world and configuration. Confirm those answers for the plan you would actually buy; the game’s current version does not prove a provider’s control panel supports it. If a managed option fits the group’s needs, check the current Project Zomboid hosting plans and verify these details before paying. For a broader shortlist and cost checklist, use the buyer guide above.

The next step is to agree on one branch, record the current versions, and test a separate copy before the first full session. Once those checks pass, invite the group with the same build and mod list in hand.

Quick answers

Can you do multiplayer in Build 42 Project Zomboid?

Yes. Build 42.21 is Stable as of September 28, 2026. The Indie Stone continues to patch multiplayer, so check the current release notes and keep a recoverable world copy.

Why is multiplayer not working in Project Zomboid Build 42?

Start by checking that the client and server run the same current build, then check the server log and required mods. A version warning or one incompatible dependency can prevent a join.

Can Build 41 players join a Build 42 server?

A Build 41 world is not compatible with Build 42. Match the group to one branch and treat a new Build 42 world as a separate start.

Do all Project Zomboid mods work in Build 42 multiplayer?

No universal compatibility is guaranteed. Check each mod author’s notes for the exact game build, multiplayer support and dependencies, then test the full set on a separate world.