Valheim Mods After the 1.0 Update

Your server has taken the 1.0 update, and now it either won't start at all or it starts and nobody can get in. Before you go anywhere near a support ticket, here's the thing worth knowing: a version bump this size breaks essentially every BepInEx mod until the authors catch up, and that's not a fault with your server. It's the expected outcome of a game going from 0.221 to 1.0 in one jump, with an engine upgrade on top. Mods hook into game code by name, the names moved, and the hooks miss. That's the whole mechanism. If you have not settled on a host yet, you can run a managed Valheim server with us.

Iron Gate said as much themselves in the 1.0 FAQ before launch: "Since we don't have any official mod support, we cannot guarantee that any mods will be functional when 1.0 releases." Take them at their word.

The good news is that a mod failure and a server failure look nothing alike once you know where to look, and getting back online is usually a five minute job rather than a support queue.

Get back online first, diagnose second

Resist the urge to work out which mod did it while your players are sitting in the join screen. Prove the server itself is healthy first, then go hunting. It's a different job and it's much faster.

Take a backup before changing anything. Some mods persist world data, so removing them can affect a save; a labelled restore point costs thirty seconds and gives you a safe way back. On a LOW.MS server that's Create backup on the Backups tab, and I'd lock it so it can't rotate away.
Stop the server, properly stopped, not restarted.
Empty BepInEx/plugins/. On a self-hosted box that's moving the .dll files out of the folder. On our panel it's the Installed list on the Mods tab: uninstall each mod, and if you've got a long list, note it down first (or build a profile of it on the Profiles tab) so you can reinstall the lot later. The panel stops the server for you if it's still running.
Leave BepInEx itself installed for this first pass. With an empty BepInEx/plugins/ folder there's nothing being patched into the game, and vanilla clients connect the same as they always did.
Start the server and watch the log (the Console tab, on our panel).

If it comes up clean and players connect, you've got a mod problem, and the rest of this article is for you.

If it still won't boot on an empty plugins folder, don't jump straight to "the server is broken". BepInEx is a dependency, not a neutral bystander: the pack is built against a particular game build, and an update the size of 1.0 can leave it stale enough to stop the server starting on its own. Uninstall BepInEx too and try once more. If plain vanilla still won't come up, that's a genuine server problem and a different article: the Valheim troubleshooting guide is where to go next.

Where the log lines actually land

There are two logs. Mixing them up is the single most common reason people misdiagnose this.

The Valheim server's own output is what the dedicated server prints as it runs: startup progress, world loading, players joining and leaving, the crossplay Join Code. On a self-hosted box that's the console window (or -logfile if you set one). On our panel it's the Console tab, live. If Valheim itself is unhappy, it complains here. BepInEx's startup banner and the list of plugins it picked up show up here too, which is the quickest yes-or-no on whether the loader ran at all.

BepInEx writes its own file: BepInEx/LogOutput.log, inside the BepInEx folder next to the server executable. On our panel open the Files tab and go to game/BepInEx/LogOutput.log. This is the one that tells you whether a mod loaded, failed, or got skipped. It's verbose and most of it is noise, but the failures are hard to miss once you scroll to the end.

A healthy boot looks like this near the top of the file:

[Message:   BepInEx] BepInEx 5.4.23.3 - Valheim
[Info   :   BepInEx] 4 plugins to load
[Info   :   BepInEx] Loading [SomeMod 1.4.2]
[Message:   BepInEx] Chainloader startup complete
[Info   : Unity Log] isModded: True

That isModded: True line is normal and always there when BepInEx is installed, even with no plugins at all. It's an internal flag, it doesn't change the version check your players' clients run against the server, and it isn't the reason anyone can't connect. People see it and panic. Don't.

The rule of thumb I use is this. If the console shows the world loading and the server reporting itself ready, the server is fine, and whatever else is wrong lives in the BepInEx log. If the console never gets as far as loading the world, stop reading the BepInEx log. It isn't the story.

What a broken mod looks like

A mod that hasn't been rebuilt for 1.0 fails in a handful of recognisable ways. Exact versions and method names will obviously differ from mine, and BepInEx has changed its wording between major versions, but on the 5.x pack Valheim uses these are the shapes to look for.

A missing dependency, usually because a library mod like Jotunn is absent or on the wrong version. Note that BepInEx prints the dependency's internal ID rather than its friendly name, and always says "dependencies" even when only one is missing:

[Error  :   BepInEx] Could not load [SomeMod 1.4.2] because it has missing dependencies: com.jotunn.jotunn

If a second mod depended on that one, you'll get a knock-on warning underneath it, and that mod is innocent. Fix the first failure and the cascade usually clears:

[Warning:   BepInEx] Skipping [AnotherMod 2.0.1] because it has a dependency that was not loaded. See previous errors for details.

Now the important one. The classic version-bump failure is not a load error: the mod loads perfectly well, and then falls over when it tries to patch a game method that has moved or changed shape. It shows up as a pair, and the first line names the exact method that went missing:

[Warning:  HarmonyX] AccessTools.DeclaredMethod: Could not find method for type Player and name Awake and parameters ()
[Error  : Unity Log] ArgumentException: Undefined target method for patch method ...

Sometimes the same underlying problem surfaces wrapped up as a Harmony exception instead:

[Error  : Unity Log] HarmonyLib.HarmonyException: Patching exception in method static System.Void Player::Awake()

None of those are fixable from your end. Remove the mod, wait for the author. That's the whole remedy.

The one thing worth doing before you give up on a mod is reading which type and method it named. If four mods all fail on the same class, they're all waiting on the same game change, and they'll likely all come back within days of each other.

Crossplay and mods, since we're here

Crossplay is on a lot more servers than it used to be. 1.0 brought PlayStation 5 and Switch 2 into the roster alongside Xbox and Game Pass, and a lot of groups switched it on the same week they took the update. So it's worth being precise about what it does before you blame it for anything.

On a dedicated server crossplay is the -crossplay startup argument, and all it does is move the server off Steam's matchmaking and onto Iron Gate's PlayFab backend, which is why console players get a Join Code instead of an IP. On our panel it's the Crossplay tick in the General group on the Manage tab; tick, save, restart. (One temporary catch: Iron Gate couldn't get the 1.0.12 hotfix onto Switch 2, so for now Switch 2 players can't play with anyone on 1.0.12. The troubleshooting guide has the workaround and its cost.)

What it does not do is touch mod loading. The version you'll read on most hosting blogs is that crossplay stops BepInEx loading entirely and leaves you with no log. It doesn't. BepInEx/LogOutput.log is still written on a crossplay server, and it'll usually show your plugins loading cleanly and then something failing later when a player actually connects. What crossplay breaks is mods that assumed everyone arriving would be a Steam user: anything keying off a SteamID64 for admin or permitted lists, anything leaning on Steam networking. Jotunn had exactly that bug in early 2025, a black screen on join and an error on the server, fixed in a point release. Plenty of mods still carry the assumption, which is why I'd keep crossplay off on a heavily modded server even though the reason usually given for it is wrong. And console players can't install mods at all, which Iron Gate confirmed for 1.0, so anything client-side is out the moment one joins.

So read the log before you assume anything. If it's ambiguous, untick Crossplay, restart and re-test: it's the fastest way to separate a crossplay-specific fault from a mod that's simply broken by 1.0. And if it does turn out to be crossplay-specific, leaving crossplay off is a perfectly good fix to sit on until the author ships an update.

Putting mods back, one at a time

Once vanilla boots, add mods back in a deliberate order, not by restoring your whole list at once and hoping.

BepInEx first. On our panel that's BepInExPack_Valheim under Frameworks on the Mods tab, and it's a dependency of nearly everything so it usually comes back on its own when you install the first mod. Start the server, confirm BepInEx/LogOutput.log gets written, stop again. That log file appearing is the only proof BepInEx is actually loading; if it doesn't appear, nothing downstream is going to work and there's no point adding mods on top.
Libraries next: Jotunn, HookGenPatcher, anything else your mods list as a dependency. These gate everything downstream, so if a library hasn't been rebuilt for 1.0, half your list is going nowhere regardless of what you do to it.
Then your actual mods, in small batches. Two or three at a time, restart, read the log.

If a batch breaks the boot, the culprit is in that batch, and you halve it. Tedious. But you'll have a real answer in twenty minutes rather than a fortnight of "it's broken again".

Your players need to match whatever you land on. Client-side mods are theirs to manage in r2modman, and mismatched lists between server and client are the number one cause of "I can't connect" after a mod change. The mod installation guide covers the client side properly.

Which version you're actually running, and after 1.0 that matters

On a self-hosted server the version of a mod is whatever .dll you last copied in, and it stays that way until you copy in another one. On our panel the Mods tab installs the current Thunderstore release at the moment you click, and each row on the Installed list shows the version you've got and whether a newer one exists. Two settings decide what happens next, and in launch week they matter more than usual:

The server-wide auto-update setting has three positions: off, frameworks only, or all mods, and it applies on the next start rather than the moment you save it. On a world people are actually playing I'd leave it at frameworks only. BepInEx and the libraries stay current, gameplay mods only move when you say so.
Each mod has its own override (follow the server, Always, or Never), and a Change version... option on its row for when the newest release broke something and you want last week's back. Set that mod to Never afterwards or the next start pulls it forward again.

The pattern I'd use right now: Update all once, read the log, and if a mod's fresh 1.0 build is worse than its old one, pin it back. Your players have to follow whatever you land on, so tell them which versions before you restart.

Anything that isn't on Thunderstore at all goes through a ticket, because the Files tab won't take a .dll from you. Plain text files like .cfg and .txt are unaffected, which is why config editing stays self-serve under game/BepInEx/config/.

Waiting it out is a legitimate plan

Some authors turn a 1.0 build around in hours. Some take weeks. Some never come back at all, and their mod joins the outdated pile permanently, which is a normal feature of a five year old modding scene rather than a crisis.

My honest advice is to run vanilla until the mods you care about have a release from after 9 September. There's a whole new biome to get through, your group has plenty to be doing without a modlist, and the mods that do survive will be steadier for having had a few rounds of patches to settle against. Check the Thunderstore pages for the handful you genuinely can't live without. Treat the rest as a nice-to-have that'll come back when it comes back. Our top Valheim mods list is a reasonable watchlist to keep an eye on.

The save format changed too, and mods notice

This is the part I'd actually be careful about, and it's easy to miss underneath all the Deep North news.

1.0 shipped the reworked save system Iron Gate had been testing on the public test branch since May. The patch notes call it a "New save system" that "Splits world data across chunks". On disk a world stops being a .db plus a .fwl and becomes a folder named after the world, full of .chunk files and a few _main files, and Valheim's own backups are folders now as well. Character saves are untouched. An older world gets converted the first time a 1.0 server loads it, and the game keeps the original pair as .db.old and .fwl.old plus a dated _backup_ copy before it does.

The same patch notes also say "Unity engine upgraded". For what it's worth, a pre-1.0 BepInEx log on one of our servers reports Unity 6000.0.61 and a 1.0 server logs 6000.0.75f1. So it isn't only game methods that moved under your mods. The engine did as well, which is why so much broke on the day.

Then there's the line that matters if you're modded, from Iron Gate's own public test patch notes back in May: "For users who are running Valheim with mods, please note that this system has not been tested with mods. While we don't believe there should be any issues relating to this, modding the game is always done at your own risk."

That's not cause for panic. It is a warning, though, and it's worth taking at face value.

Take a backup before you change your mod list, with the server stopped. On our panel that's the Backups tab, and lock the one from before the change.
Be wary of mods that write world data directly: world generation mods, world editors, anything rewriting zones or entity data. Those need a build made for the folder format, and an old one won't understand the chunks.
Don't move save files around by hand. If you restore or download a world, the whole folder is the unit now, never a pair of files. Our world upload guide covers both the new folders and older .db and .fwl uploads.

I'd hold off on any world-editing pass until the tool you want has a release from after 9 September, too. Running an old world editor against a freshly converted save is asking for precisely the untested combination Iron Gate flagged.

When to open a ticket

Anything where the answer is "someone needs to look at the box", basically. A mod that isn't on Thunderstore, a BepInEx install that won't write a log, something the Mods tab can't uninstall cleanly, or a server that still won't boot with an empty plugins folder. Send us the Thunderstore URLs and the last fifty lines of LogOutput.log. With those two things we can usually tell you what's wrong before we've even connected to the box. We've hosted Valheim since the game's launch week back in 2021, and we've been reading 1.0 server logs since 9 September. If your list is stuck, we'd much rather hear about it than have you sitting on a dead server for a week.