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. Mods hook into game code by name, the names moved, and the hooks miss. That's the whole mechanism.

Iron Gate said as much themselves in the 1.0 FAQ back in July: "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 manual backup from Cloud 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.
Stop the server from the LOW.MS Control Panel – properly stopped, not restarted.
Open Mod Manager in the sidebar and uninstall your mods. Everything in the Valheim catalogue is uninstallable, so it's a click each rather than a file operation.
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 Web Console.

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 goes to Web Console live, and Log Viewer in the sidebar shows you the same stream – startup progress, world loading, players joining and leaving, the crossplay Join Code. If Valheim itself is unhappy, it complains here.

BepInEx writes its own file: BepInEx/LogOutput.log, in your server root, which you can open through File Manager. 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 is a command line, not a tick-box

This is the bit that catches people out on our panel, and it's worth getting straight before you blame the update for anything.

Crossplay is not a setting you tick in Service Settings. It's decided by which command line your server starts with. Open Commandline Manager in the sidebar and you'll find three predefined lines:

Default – no crossplay.
Default (With Crossplay) – the same line plus -crossplay.
Additional Configuration – no crossplay, but it's the only line that carries the difficulty preset and extra-arguments tokens.

That third option is where the trap lives. The preset and extra-argument tokens exist only on Additional Configuration. If you've tuned your world difficulty or passed extra arguments there and then switch over to Default (With Crossplay) to get a console friend in, those settings quietly stop being applied – no warning, no error, your raids and difficulty just revert to stock. And it runs the other way too: there's no predefined line that gives you both crossplay and the preset tokens. You pick one. If you need crossplay and custom difficulty, open a ticket and we'll build you a custom line.

With PlayStation 5 and Switch 2 joining the crossplay roster at 1.0, a lot more groups than usual will be flipping that line this month, so it's worth knowing what you're trading away.

On crossplay and mods together: they're an awkward pair and I'd keep crossplay off on a modded server. What the flag actually does is move your server off Steam's matchmaking and onto PlayFab's, which is why you hand out a Join Code instead of an IP. It doesn't touch mod loading at all. What it 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 the blanket advice to avoid the combination is sound even when the reason usually given for it isn't. 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.

That reason matters, because 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. So read the log before you assume anything. If it's ambiguous, switching to Default, restarting and re-testing is still 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, just 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. BepInExPack_Valheim is in Mod Manager. 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.

The Mod Manager catalogue is pinned, and after 1.0 that matters

One thing to understand about how our Mod Manager actually works, because it quietly changes what you should expect in the days after launch – and it catches people out.

The Valheim catalogue is a set of bundles we host ourselves, each one a snapshot of a mod at a particular version. Install Jotunn from Mod Manager and you get the version we bundled – not whatever Thunderstore published this morning. That's deliberate, and it means installs are reproducible, but it also means the catalogue lags a live game update by as long as it takes us to re-bundle.

A few practical consequences:

Entries we know have gone stale carry (Outdated) in the name. Believe the label. There are a fair number of them, because Valheim's mod scene has five years of history behind it and plenty of authors have moved on.
After 1.0, expect more stale entries than usual until we've worked through the re-bundling. An entry that looks fine and then fails in the log isn't you doing something wrong.
If a mod has shipped a 1.0-compatible release and our bundle hasn't caught up, open a ticket with the Thunderstore URL and the version you want.

That ticket route is also the answer for anything outside the catalogue entirely, because the panel doesn't accept .dll uploads from customers. Not through File Manager, not over SFTP on port 8822, not over FTP on port 8821 – it's an executable-upload block and there's no side door to find. Plain text files like .cfg and .txt are unaffected, which is why config editing stays self-serve.

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 for the first week. 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.

What we know about the save rework

This is the part I'd actually be careful about, and it's easy to miss underneath all the Deep North news. It also needs a caveat about what's actually confirmed, because there's a lot of confident writing about this that runs ahead of what Iron Gate have said.

Since patch 0.221.13 on 6 May, Iron Gate have been testing a reworked world save system on the public test branch. Worlds stop being a .db plus a .fwl file and become folders instead, with the world split into chunks so only the modified pieces get written on each save, and backups getting their own folders too. Character saves are untouched. Load a world that isn't chunked yet and the game takes a backup before converting it.

What hasn't happened is that reaching everybody. As I write this the newest live patch is still 0.221.12 from February, so live servers are on .db and .fwl today, and anything telling you to go looking for world folders is wrong until the 1.0 build actually lands. Iron Gate have said there'll be no public test branch for 1.0, and the 1.0 FAQ lists "faster saving" among the optimisations going into the release, so 9 September looks like where it arrives – but they haven't said that outright, so don't plan around it as a certainty.

Then there's the line that matters if you're modded, straight from Iron Gate's own public test patch notes: "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 manual Cloud Backup before your server takes the 1.0 update, not after.
Be wary of mods that write world data directly – world generation mods, world editors, anything rewriting zones or entity data. Those have the most surface area against a changed save format.
Don't move save files around by hand between builds. Iron Gate advised against that during the public test and I'd keep following it, particularly since a world that gets converted has effectively taken a one-way trip.
Our world upload guide describes the .db and .fwl layout, which is still correct today and will need revisiting once we've seen the new folders on a real server.

I'd hold off on any world-editing pass for a while, too. Running a community world editor against a freshly converted save on launch day is asking for precisely the untested combination Iron Gate flagged.

When to open a ticket

Anything where the answer is "someone needs to touch files on the server", basically. A mod version we haven't bundled yet, a BepInEx install that won't write a log, something Mod Manager can't shift, 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 launch week and we'll be watching the 1.0 fallout closely. If your list is stuck, we'd much rather hear about it than have you sitting on a dead server for a week.