Project Zomboid Build 41 vs 42: Choose a Server Branch

For a new multiplayer world, choose the current public Stable branch, Build 42.21 as of September 29, 2026; keep a Build 41 group on legacy41 only when its existing world or essential mod setup calls for it. If you are comparing a Project Zomboid Build 41 vs 42 server, the developers’ save-compatibility warning matters: a branch change is not a world upgrade. This guide helps your group pick a branch, protect the world it already has, and ask a host the right questions before paying. It does not claim that every mod or hosting panel supports both branches.

Once your group has selected a target, validate each chosen item on that exact build with the Build 42 multiplayer mod audit; this branch guide does not certify individual mod revisions.

Once your group chooses a branch, work through the current Build 42 multiplayer readiness checks before the first session; this guide stays focused on the branch decision. For paid plans, compare the Build 42 hosting branch and backup controls against the branch your group has chosen.

Start with the world your group wants to keep#

Choose the branch around the group’s shared world, not the newest version number by itself. First write down what your players actually need to preserve and what they cannot do without. That turns “Build 41 vs 42” into a decision you can verify instead of a vote based on different assumptions.

Check with the group	What to record	Why it changes the decision
Current clients	Storefront, displayed build, and branch for each player	A server choice only works if the joining clients can match it
Existing world	Whether the save began on B41 or B42, plus a separate recoverable copy	B41 saves are incompatible with B42
Essential mods	Workshop item, Mod ID, dependencies, and author notes	A mod’s download page is not proof it works on the chosen branch or in multiplayer
Desired next session	Continue the current world, or begin a separate world	A fresh world can make a newer branch practical without risking the older save

Ask every regular player to check their own game before you decide. One person may say “42” because Steam updated their client, while another may be trying to continue a B41 world with a specific mod set. Record those as separate needs. If the group cannot agree on which world matters, pause the server change until you know which copy is the keeper.

Choose the branch for your Project Zomboid Build 41 vs 42 server#

As of September 29, 2026, the official release announcement labels Build 42.21 Stable, and anonymous SteamCMD metadata lists public, unstable, and legacy41 for both the Project Zomboid client (App ID 108600) and dedicated server (App ID 380870). Both current legacy41 records describe Build 41.78.21. The client and dedicated-server manifests are separate apps, so their build IDs are not values to compare against each other.

Branch or evidence	What it tells your group	What it does not tell you
public	The current default Stable branch; the dated 42.21 Stable announcement is the release source for this version	That a particular mod, provider panel, or old world is compatible
unstable	Steam currently lists a separate testing channel	That it is appropriate for a persistent group world or is the same as Stable
legacy41	Steam currently lists a Build 41.78.21 branch for both apps	That a provider exposes it or that a specific saved world/mod combination works

This branch check queried current Steam app metadata anonymously on September 29. It did not download game binaries, start a server, test a client join, or inspect a hosting panel. Treat it as a snapshot: check the current branch listing again when you are ready to update. A metadata listing is useful for deciding what to investigate, but it is not a compatibility certification.

Choose Stable 42.21 for a new world when the group is ready#

For a group starting fresh with no B41 world to retain, the current public Stable branch is the straightforward starting point. The official 42.21 release announcement is dated September 28, 2026. That gives you a clear version target to confirm across the clients and server before the first session.

Stable does not mean every group’s setup is automatically ready. Check that each essential mod’s maintainer supports the exact build and multiplayer, and include required dependencies. If a mod’s notes only say “Build 42” or have not been updated, ask its maintainer or test it on a separate world before making it part of the shared setup. A mod loading successfully is one check; a clean client join and the expected in-game behavior are separate checks.

Do not choose B42 because you expect it to run faster, support more players, or fix a specific issue. This branch comparison has no measured server benchmark for your player count, world age, mods, or host. If performance is the concern, keep that question separate and test the actual setup you intend to play. For the branch decision, focus on the world, client matching, and verified mod requirements.

Keep Build 41 for a deliberate compatibility reason#

Staying on B41 can make sense when your group is continuing a B41 world or depends on a mod setup whose maintainers have not confirmed the B42 build. Steam’s current legacy41 metadata describes Build 41.78.21 for both client and server app records. That is a current branch listing, not a guarantee that every future client, host, or mod will keep supporting it.

Before you commit the group to legacy41, check each essential Workshop item at its official page and maintainer notes. Confirm the target game build, multiplayer support, dependencies, and whether the required version is still available. Collections can include items with different compatibility status; reviewing only the collection title is not enough. Make a short mod manifest the whole group can compare.

Your group’s situation	Safer branch decision	Check before scheduling a session
New world; must-have mods confirm B42 multiplayer support	Current public Stable	Match the clients and server to the current public release
Existing B41 world is the priority	Keep the B41 world and use legacy41 where every component supports it	Confirm client and server branch, and retain a separate backup
A critical mod has unclear B42 status	Delay the move or test privately	Get maintainer evidence or a successful isolated test with matching clients
Players want different worlds/builds	Agree on one shared target or run separate environments	Do not point two branches at the same live world folder

The branch name alone cannot prove that your full mod list works. If even one must-have mod’s compatibility is unclear, mark the decision unresolved rather than promising the group that the old setup will behave the same after an update.

Keep the old Build 41 world separate#

Build 41 and Build 42 do not share compatible savegames according to The Indie Stone’s Build 42 Stable plans. Preserve the complete old world independently and treat a new B42 world as a separate start. Copying a directory, changing a branch, or retaining a client save does not demonstrate that the server can convert the world.

Before any change, stop the server cleanly and make a separate copy of its world and related configuration. Keep that copy out of the folder used by a B42 test. Reopen it only with the compatible B41 setup, and do not experiment on the only copy. If the group chooses Stable 42.21, create a new world after the selected branch and mods have been confirmed.

If your actual goal is to preserve or archive the B41 world while beginning on B42, treat that as its own migration-planning task. This comparison does not provide a conversion process or promise that progress can be moved between the formats.

Confirm every client and the server before inviting players#

Before opening the new server to the group, write down the branch and exact displayed build for the server and each player’s client. The goal is one compatible set, not merely “everyone has updated.” Storefront and platform matter too: the current branch metadata check above covers Steam’s PC client and dedicated server apps. It does not establish compatibility for another storefront or console.

1. Agree on the target world and branch

   Record whether the session continues a B41 world or starts a separate B42 world. Write down legacy41 or the current public branch so nobody silently chooses a different target.

2. Compare player and server versions

   Have each player and the server operator confirm the displayed build and branch from their own installation or provider. Stop if any value is unknown or inconsistent; do not troubleshoot mods until the build mismatch is resolved.

3. Verify essential mods on the chosen build

   Compare the shared manifest with the maintainers’ current compatibility notes. Resolve missing dependencies and unclear multiplayer support before using the group’s only world.

4. Join with a small test session

   Use a separate test world first, then confirm a client can connect and the essential mods behave as expected. Only schedule the persistent group world after the test matches the agreed setup.

If you see a version mismatch or a mod error, capture the exact client and server build first. “It is on Build 42” is too broad when an unstable branch, a Stable update, and a legacy installation can all differ. Keep the evidence with your mod manifest so a future update has a known baseline.

Ask a host about branch controls before paying#

A rented server only helps if the provider can run the branch your group chose and gives you a safe way to protect its data. This check did not verify Game Hosting’s panel controls or a paid Project Zomboid instance, so confirm these details directly before checkout or a switch. The Project Zomboid service page is a starting point for reviewing the plan; it is not proof that a particular branch control is available.

Ask the provider to confirm, in writing:

• Whether the exact target is current public Stable or legacy41 Build 41.78.21.
• How updates are applied and whether you can delay an update until the group and essential mods are ready.
• Whether a test world can be kept separate from the persistent world.
• Which world, configuration, and mod data can be exported, and how restore works.
• Whether the provider can confirm the running server build after the change.

If the response describes only “latest version,” ask them to identify the branch and build they mean. If the answer does not cover your existing world or backup export, do not assume those details are included. A provider’s promise about its own controls is the evidence you need; a Steam branch listing cannot substitute for it.

Use the right guide for the next step#

This page helps your group choose a branch and protect the world it plans to keep. Once you have chosen, the published SteamCMD install and branch-selection procedure covers installing the dedicated package and checking the selected files. Follow it with a separate test before inviting the group. If you still need to decide between B41 and B42, return to your world and mod checklist rather than picking the branch based on a command example.

Quick answers

Is Project Zomboid Build 42 stable now?

Yes. The Indie Stone announced Build 42.21 as Stable on September 28, 2026. Check the current Steam branch and build again before you update.

Can Build 41 clients join a Build 42 server?

Do not assume they can. Everyone joining should use a compatible client build and branch with the server; confirm the exact version before inviting the group.

Is Build 42 better than Build 41 for a server?

There is no universal answer for every group. Choose from the world you need to keep and the verified multiplayer support of your essential mods, not an assumed performance advantage.

Can I move a Build 41 save to Build 42?

The developers say Build 41 saves are incompatible with Build 42. Keep a recoverable B41 archive and treat a B42 world as separate; this guide does not promise a conversion.

Does Steam still list legacy41?

Current anonymous Steam app metadata checked on September 29, 2026 lists legacy41 for both client App ID 108600 and server App ID 380870 as Build 41.78.21. That does not prove a hosting provider exposes it.