Valheim modded server after a game patch: patch day

When Valheim patches and your server runs mods, the safe routine is: do not update the server, back it up and lock that backup, check every mod's page for an update or a "still works" note, test the new game build with the updated mods on a copy of the world, and only then update the server and roll the new profile out to the group in one go. Most patches are playable again within a day or two; a big one that changes the Unity version can take a week before the content mods catch up. The thing that turns a patch into a lost world is not the waiting, it is somebody updating half the stack in a hurry and then playing on it.

This post is one patch day on a real-shaped group server - six players, a dozen mods, one content mod - from the moment Steam downloads the update to the evening everyone is playing again.

Why a game patch breaks a modded server#

Three separate things happen when Iron Gate releases an update, and it helps to keep them apart.

The game updates itself on every player's PC. Steam pushes the patch as soon as it is out. You can set the game to update only when launched, but r2modman starts Valheim through Steam, so launching the modded profile downloads the patch anyway. There is no supported way to keep a group's clients on the old build for long.

The dedicated server does not. It is a separate Steam app, 896660, and it updates only when something runs SteamCMD against it. An old server and a new client cannot talk: the player gets "Incompatible version". Not every small patch changes what the server and client check, so some hotfixes connect fine across builds - the error, or its absence, tells you which kind you have.

The mods may or may not survive. BepInEx mods work by patching the game's own code while it runs. If the patch renamed or changed a method a mod patches, that mod fails - sometimes with a clear error in BepInEx/LogOutput.log, sometimes silently, sometimes with a crash during start-up. Small QoL mods often survive a minor patch untouched. Libraries such as Jotunn and big content mods like Epic Loot are the most likely to need an update, because they touch the most game code.

The consequence: for a while after a patch, players have the new game, the server has the old game, and the mods are somewhere in between. Your job is to get all three onto the same page in one step instead of three.

Before patch day: what should already be in place#

The routine is much calmer if four things were set up long before any patch.

1. A pinned profile file. The group's mod set as an exported .r2z, with a name that carries a date or number, pinned in your group channel. If you only have a profile code, it may have expired by the time you need it. r2modman profiles for groups covers building and pinning one.
2. No automatic updates on the server. If the server pulls a new game build every time it starts, a scheduled restart on patch night updates the game under your mods without asking. On your own machine, that means the SteamCMD line is not in the start script. On a panel host, check what the start-up does - many run SteamCMD on every start, some have a variable to switch it off - and check that no schedule restarts it overnight during the hold.
3. A recent backup of the whole server. World files and the BepInEx folder together, not just the world.
4. One owner. The same person who owns the profile owns patch day. Everyone else waits for their message.

Hour zero: hold the server#

The patch is out. Steam on your PC is downloading it. What to do in the first hour:

1. Do not update the server. Leave it on the old build. If it was going to update on start, stop it now.
2. Take a backup and lock it. This is the copy of the world before anyone plays on a new game build with old mods. Name it something you will recognise, such as pre-patch-0.2xx, and lock it so nightly rotation cannot push it out.
3. Tell the group. One message: the server is held until mods catch up, do not press "Update all" in r2modman, do not install mods manually, you will post when it is ready.
4. Note the new game version. It is in the patch notes and on the game's main menu. You need it to read mod pages.

That is all for now. Players who want to play during the hold can start the game unmodded on a local single-player world. They cannot join the server: it is on the old version, and they are on the new one.

Valheim patched today. Server is on hold until the mods update.Do NOT press "Update all" in r2modman. Do NOT add mods.I will post a new profile file when it is ready. Probably 1-3 days.

On RE:NODE a backup can be taken and locked from the panel in a few seconds, and locked backups are kept out of rotation, so step 2 is not something to skip because it is fiddly. A locked backup is still deleted if the server itself is deleted, so download a copy if you want it to outlive the server.

Checking every mod page#

Now go through the profile one package at a time. For each, open its Thunderstore page and look at three things: the latest version and its date, the changelog, and any note from the author about the new game version. Many authors also have a Discord or a GitHub issues page where "does this work on the new patch" is answered within hours.

Work from the bottom of the dependency tree up:

1. BepInExPack Valheim. Usually unchanged. It needs a new release mainly when the game changes its Unity version, which happens on large updates.
2. Libraries - Jotunn, HookGenPatcher and anything else other mods depend on. These usually update first, because everything waits on them.
3. Content mods. These take longest. Watch for an update or an explicit "works on the new patch" note.
4. QoL mods. Often still work. A missing update is not proof of breakage.

Keep a small table as you go; it turns "is it ready yet" from a feeling into a list.

The table above is an example, not a report on any particular patch. Your real table depends on the patch and the mods.

A mod marked deprecated on Thunderstore, or one whose author has said they have stopped, needs a decision rather than patience. What to do when a mod update breaks covers replacing or dropping one.

If you want warning before the patch lands, Iron Gate tests big updates on a public test branch first, and many mod authors test there too. Running a copy of your server on that branch is covered in the public test branch server.

Testing on a copy#

Once the table says every mod you need is updated or claimed to work, test before touching the server. The cheapest test is on the profile owner's own PC, with copies of everything:

1. Copy the profile. In r2modman, export the current profile as a file, then import it as a new profile with a test name, for example Longship-test. Never test on the profile the group is using.
2. Update the test profile. Update only the packages your table says to update - not "Update all", which would pull in versions you have not read about.
3. Copy the world. Download the world's .db and .fwl from the server backup and place them in your local worlds_local folder: %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local\ on Windows. Rename the pair if a world of that name already exists locally, keeping both files with the same name.
4. Start modded and load the copy. Launch the test profile, start the copied world, and load into it with a character you do not mind risking - mods can and do eat inventories when they fail.
5. Run the checks. Walk to the main base. Open chests. Craft at every station, including anything the content mods add. Check that modded items are still in chests and still have their properties. Plant something. Sleep through a night. Then quit cleanly and look at the log.

# In the test profile's folder after quitting$ grep -E 'Error|Exception' BepInEx/LogOutput.log | sort | uniq -c | sort -rn | head

A handful of warnings is normal in most modded logs. A repeated exception naming one of your mods, or anything during start-up, is not. BepInEx log troubleshooting explains how to read those lines and how to bisect a set to find the culprit.

This local test does not prove the dedicated server will start - a server runs on Linux with no screen, and some failures only appear there. If you have a spare server or can run a second copy on your own machine, start the updated mod set against a copy of the world there as well. It takes half an hour and catches the remaining surprises.

The staged rollout#

The test passed. Now the real server, in a strict order so that a failure at any step leaves you somewhere you can roll back from. The game update in step 4, on a Linux server you run yourself, is one SteamCMD line:

$ steamcmd +force_install_dir /home/valheim/server +login anonymous \    +app_update 896660 validate +quit

validate does not touch BepInEx/, doorstop_libs or start_server_bepinex.sh, because they are not part of the game's files. On a panel host, use whatever the host does to update - often a restart with updating enabled, sometimes a reinstall button. Be careful with reinstall buttons: find out what the host's reinstall deletes before using one on a modded server.

1. Announce a time. "Server down for twenty minutes from 19:00." Nobody joins while it happens.
2. Stop the server cleanly and wait for the world save line in the log.
3. Take a second backup. The first one was before the patch; this one captures anything played since, if your server stayed up on the old build.
4. Update the game files with the command above, or your host's update method.
5. Update BepInExPack if your table said so, by uploading the new pack's contents over the server root.
6. Replace the mods. Delete the server's BepInEx/plugins and BepInEx/patchers, and upload the test profile's folders in their place. Remove client-only mods again. For BepInEx/config, keep the server's files unless the changelog says the config format changed - the server's copy has your server-only settings in it.
7. Start and read the log. Every mod listed with the new version number, Chainloader startup complete, then the world loading. A modded start can take a couple of minutes.
8. The owner joins first, on the test profile, and repeats the quick checks from the test.
9. Export and post the new profile. Export the test profile as a file with a new name - Longship-2026-10b - and post it. Everyone imports it before their next session.

If step 7 or 8 fails, stop the server and restore the backup from step 3. You lose nothing, the server is back on a known state, and you can investigate without the group waiting on a broken world.

When one mod is not ready#

Patches rarely leave every mod broken. Usually it is one or two holding up the group, and you have three options.

Wait. For a content mod the world depends on, this is almost always right. Two or three days without playing costs less than the items and builds that mod holds.

Drop a client-side or QoL mod temporarily. If AzuCraftyBoxes is the only mod not ready and the group can live without crafting from chests for a week, remove it from the profile and the server, export, roll out, and add it back when it updates. QoL mods rarely store anything in the world, so this is low risk - but check the mod page in case it does.

Drop a content mod. This is the expensive one. Items and build pieces a content mod added will not load without it, and items in player inventories can be lost when the character is saved without them. Some of it may come back if the mod is reinstalled before the world and characters are saved again, but do not count on it. If you go this way, take a locked backup first and accept that the world may not return to exactly how it was.

The honest version: if the content mod is abandoned, the long-term answer may be a new world on a mod set that is maintained. Mod conflicts and dependencies covers finding replacements that do the same job.

A worked patch timeline#

Here is how one patch played out for a group of six, with the example set from the modded server walkthrough. The details will differ for yours; the shape usually does not.

Total downtime about two days, which is typical for a mid-sized patch with one content mod. A patch that changes the Unity version is slower; a hotfix is often resolved within hours.

Troubleshooting after the patch#

"Incompatible version" after the rollout. Someone has not updated their game, or the server's update did not apply. The server log prints the game version at start; compare it with the main menu version on the player's PC.

Kicked on connect with a mod name in the message. That player is on the old profile, or pressed "Update all" and is ahead of the server. Have them import the new file. Mod version mismatch kicks explains each message.

The server starts but mods do not load. It is running the vanilla start, often after a host-side update or reinstall reset the start command. Check that BepInEx is still switched on and that BepInEx/LogOutput.log was rewritten at the last start.

The server crashes during start-up. One plugin is failing. Read the last lines of LogOutput.log, move the named mod out of plugins, and try again. On RE:NODE three crash restarts in an hour put a warning on the server page and open a ticket, so a loop gets noticed, but stop the server yourself rather than letting it cycle.

Items have lost their enchantments or vanished. A content mod failed to load on the server or a client during a session. Stop the server, restore the pre-rollout backup, and fix the mod set before anyone plays again - every save on a broken set makes the loss permanent.

New biome content is missing from the world. That is not a mod problem: new content only generates in zones nobody has explored. Old worlds and new biomes explains what a patch can and cannot add to a world you have already explored, and Valheim server crashes on start covers start-up failures that are not mod-related.

FAQ#

Can I keep the server on the old version until the mods are ready?

Yes, and that is the point of the hold. What you cannot do is keep your friends' game on the old version, so nobody can play on the server during the hold. Holding the server protects the world; it does not keep the group playing.

Should I turn off mods and play vanilla until they update?

Only if your mods are all QoL and store nothing in the world. With content mods, a vanilla session loads a world full of things the game does not recognise and saves it again, which is how items get lost. Wait instead.

How do I know a mod works if the author has not updated it?

You do not until you test it. Check the comments, Discord or issue tracker for reports on the new version, then run it in the test profile on a copy of the world. A clean log and a working feature are as close to proof as you get.

Do I need to update BepInExPack after every patch?

No. It needs an update mainly when the game moves to a new Unity version, which happens with large updates. Its Thunderstore page and changelog say when a new release is needed.

How long should I keep the pre-patch backup?

Until the group has played for a week on the new set without problems. Some breakage only appears when someone opens a chest they have not touched since before the patch.

Is it safe to schedule automatic updates on a modded server?

Not for game updates. A scheduled backup and a scheduled restart are both good ideas, as long as the restart does not also pull a new game build. On a modded server, game updates should be something a person decides to do.