Valheim "INCOMPATIBLE_VERSION" Fix: Build ID, Branch & Mod Stack
Your Valheim server shows up in the browser. You hit join. The client throws "INCOMPATIBLE_VERSION" and disconnects. Almost every time, the world is fine and the server is fine. The two are simply on different Steam builds, different branches, or one side has a stale BepInEx stack that targets an older game version.
This page walks you through the actual diagnosis instead of guessing. The first step is always: find out what build the client thinks it is.
What the error really means
Valheim refuses to connect when the client's protocol/build does not match the server's. Steam exposes a numeric build ID per game; that number is the only authoritative way to compare what's on each side. The error itself does not show this number, so you have to look it up.
The three real causes, ranked by how often they bite:
- Branch mismatch: server is on the
public-testbranch, client is on default (or vice versa). - Steam updated the client first: common for a few hours after a patch ships, while the dedicated server build is still propagating.
- Stale BepInEx plugin: a mod compiled against the previous Valheim version blocks the protocol handshake.
Step 1: Look up the client's build ID
The customer can read this from Steam without joining the server:
- Open Steam → Library → right-click Valheim → Properties.
- Open Updates. Steam shows the installed build ID near the top of the panel.
- Open Betas. The currently selected branch is shown there. If it is anything other than None, write down the branch name.
You now have two facts: what build the client is on and what branch the client is on. Without these, every fix is a guess.
Step 2: Look up the server's build ID and branch
On Supercraft the branch is shown in the panel for the deployment. The current build can be confirmed by reading the version file on disk:
cat vlh/version
# example output
vlh/public-test/latest
If the customer is using the public-test branch and the server is on vlh/stable/latest, that is the bug. Branch names that have shipped at various points include public-test, default_old, and seasonal beta tags. The client's Betas dropdown must match the server's branch by name.
Step 3: Decide which side moves
| Client build | Server build | Action |
|---|---|---|
| Newer | Older, same branch | Trigger a server update from the panel. Steam usually catches up within hours of a patch. |
| Older | Newer | Force the client to update via Steam → right-click Valheim → Properties → Updates → Always keep this game updated. |
| Same build | Same build | Different branch. One side switches branch in Steam Betas (client) or in the panel branch picker (server). |
| Same build, same branch | Still fails | BepInEx plugin compiled for a prior version. Remove plugins one at a time. |
Step 4: When it's actually the mod stack
If both sides are confirmed identical and join still fails, the BepInEx plugin loader is the next suspect. After a Valheim patch the plugin DLLs are still on disk but the patches they apply target methods that no longer exist. The server log line to look for is in BepInEx/LogOutput.log:
[Error : Unity Log] NullReferenceException: Object reference not set to an instance of an object
Stack trace:
<ModName>.<ModName>.TryRegisterRecipes ()
<ModName>.ObjectDB_CopyOtherDB_Patch.Postfix ()
The first non-engine stack frame names the broken mod. Either remove that DLL from BepInEx/plugins/ or update it from Thunderstore to the version that targets the current Valheim build.
Things that are not the cause
- The world file. A version mismatch never corrupts the
.db/.fwlpair. Do not restore a backup as your first step. - The server password. Wrong passwords give a different error.
- Crossplay / public-1 flags. Those affect listing and matchmaking, not protocol compatibility.
- Verbose Steam handshake noise. Lines like
SteamNetworkingUtils004 before SteamAPI_Init succeededappear during normal boot and are not the problem on their own.
If you are running modded with friends
Coordinate the branch before the next patch lands. Once Steam ships an update on the default branch, modded groups commonly stay one version behind on the public-test opt-out branch (when one is offered) until every plugin updates. The decision of "who switches branch" is the only thing you have to agree on.
Quick rule: if the customer cannot tell you their client build ID, you cannot finish the diagnosis. Ask for it first; everything else is guesswork.
Returning to a server after months away
A specific variant of the version-mismatch problem: you and your friends played the server through Ashlands, paused for six or twelve months, and now want to return. The server boots, the world appears valid, but joins fail or the save file "doesn't work." Several distinct things may have drifted in your absence:
- Steam pushed multiple Valheim updates while you were gone. The server image may have auto-updated (some hosts do) or it may have stayed pinned (some don't). Your client almost certainly updated. Steps 1-3 of this article still apply — read the build IDs and align.
- The save format itself was upgraded. When you load an older
.dbon a newer Valheim version, the server quietly converts it to the new format on first save. The conversion is one-way: once the new server has written it, an older server cannot read it. Keep the original.db.oldas a "snapshot before upgrade" in case the conversion failed. - Docker / container image got pinned to a very old tag. If you run a community image like the popular Linux Server.io or lloesche container, the
:latesttag may have moved to a Valheim build newer than your image actually pulled.docker pullthe image again and rebuild the container — easy to forget after a long pause. - BepInEx and every plugin DLL is now stale. If you ran mods, every single DLL is now compiled against an old Valheim version. Update each plugin individually from Thunderstore — don't assume the modpack as a whole still works.
- Character files were untouched but the world progressed past your gear tier. Not a technical problem, but a real one: your characters are still loaded with Ashlands-era gear and skills, but if a teammate started a new save during the break, joining their fresh world means your old gear is wildly overpowered. Decide as a group whether characters carry forward or everyone makes new ones.
Safe-return checklist
- Back up
worlds_local/entirely (both.dband.fwlplus all.oldbackups) before starting the server for the first time after the break. - Note the current Steam build ID of the server.
- Note the current Steam build ID of each player's client.
- Start the server with NO mods loaded. Confirm the world loads and you can join solo.
- Save in-game (F5 →
save) and verify "World Saved" appears. - Stop the server, take another backup, label it "post-upgrade."
- Add mods back one at a time. Each new mod, restart, confirm join still works.
This sequence isolates which step breaks if a step does. Going straight from "haven't touched server in 6 months" to "everyone log in and play" almost always produces a problem you then can't pin down.
Skip the manual update dance
On Supercraft Valheim hosting the branch picker and the dedicated-server app sit behind one button, so you can swap branches per restart and never SteamCMD a server by hand again. Pair it with the BepInEx setup guide if you run mods.