13 September 2026

Valheim Client-Side vs Server-Side Mods

Whether a Valheim mod runs on the server, on each player's PC, or on both decides who can join and who gets kicked. How to tell the three apart, why console players changed the maths at 1.0, and how to install each kind on a LOW.MS server.

Need a Valheim server?Rent now

Someone in your group installs a mod, joins, and gets booted with a version mismatch. Someone else installs the same mod and never notices a thing. Meanwhile the friend on Xbox can't install anything at all, and is quietly wondering why they keep getting left out of these conversations. All three of those come down to one question, and it's the question most mod pages answer badly or skip entirely: is this a server-side mod, a client-side mod, or one that has to be on both?

Get it wrong and you'll spend an evening chasing a connection problem that was never a connection problem (firewall rules, port checks, the lot) when the actual fault was a plugin sitting on one side of the wire and not the other. It happens constantly.

Server-side, client-side, or both: the split that decides everything

BepInEx is the mod loader, and the thing to hold onto is that it runs in two completely separate places. There's a copy on your dedicated server. There's another copy on each player's PC. They don't talk to each other, they don't sync, and installing a mod on one has no effect whatsoever on the other. None.

So every mod falls into one of three buckets.

Server-side only. The logic lives entirely on the server. Players connect with a stock, unmodded game and get the benefit anyway, because the server is the thing making the decisions: loot tables, spawn rates, admin tooling, chest sorting, most world behaviour.

Client-side only. It changes what you personally see or do: a better minimap, a different camera, sharper UI, an equipment tooltip. The server has no idea it exists and doesn't care. Each player decides for themselves.

Both sides. New items, new creatures, new recipes: anything that adds content to the world. The server has to know the item exists so it can store it, and your client has to know so it can draw it. These are the ones that kick people.

Most of the pain people report is really just bucket three being treated like bucket one. That's the whole story, most weeks.

Working out which kind you're looking at

There's no official label, annoyingly, and no field on a Thunderstore page that settles it for you. But there are tells, and in my experience they're reliable enough to act on.

Read the description first. Authors who have thought about it say so outright, usually in the opening line. The ServersideQoL family by ArgusMagnus opens with "Serverside-only QoL mod, compatible with vanilla/console (e.g. XBox, PS, Switch) clients", which answers the question before you've finished reading the sentence. Believe them. An author who bothers to write that line has usually tested it against a vanilla client, which is more than most of us do.

Look for ServerSync. A lot of Valheim mods bundle a library called ServerSync, which pushes the server's configuration down to connected clients so that everybody ends up agreeing on the settings instead of each running their own. If a mod ships it, that mod almost certainly needs to be on both sides, and if it locks its config (most do by default) the server's copy wins. That's the entire reason the library exists.

Look for the words "version check". Some mods deliberately refuse connections from clients that don't have them installed. Azumatt-AzuExtendedPlayerInventory spells it out in its own server setup notes, "Version check: Kicks clients without the mod installed", which is about as unambiguous as these things get. That's the mod doing exactly what it advertises, so don't go looking for a server fault.

When in doubt, assume both sides. Over-installing costs a bit of wasted effort. Under-installing costs you Friday night.

Why server-side only mods matter more since 1.0

Console players can't install mods. There is no mechanism on those platforms, fiddly or otherwise, and Iron Gate have never suggested one is coming. Xbox players have been in that position since Valheim arrived there. On 9 September, with 1.0, PlayStation 5 and Switch 2 players joined them, and the crossplay roster got considerably wider. (One temporary exception: 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 covers the workaround.)

So the moment one console player joins your world, every client-side and both-sides mod on your server turns into a wall they can't get past. Server-side mods carry on working perfectly well for them, because the server is doing the work and their vanilla client never needs to know a thing about it.

That turns the three buckets into an actual decision. If you want console friends in the world, your mod list is server-side only. If you want a heavily modded world, it's PC players only. There's no clever third option, and I'd rather you knew that now than on game night with everyone already sitting in Discord.

Which bucket a mod lives in also decides what a breakage costs you, and that mattered more than usual after a version bump the size of 1.0, because most BepInEx mods stopped working until their authors caught up, and plenty still haven't. A client-side mod that dies takes one player's minimap with it. A both-sides mod that dies takes the entire group offline until somebody works out which one it was. Even with no console players anywhere near your world, a server-side-heavy list is the one that degrades gracefully. Valheim mods after the 1.0 update walks through the recovery properly.

While I'm here, let me kill something we used to say on this very site: enabling crossplay does not stop BepInEx loading. It never did. The flag moves the server onto a different matchmaking backend and leaves the mod loader completely alone. You can watch BepInEx start up and the crossplay session register in the same server log, one after the other. What actually breaks under crossplay is any mod that assumed every player arrived via Steam, because it goes looking for a Steam ID that a PlayStation player has never had. That can break in ways that look like nothing else, and it's a genuine problem and it's worth planning around. It just isn't the problem everyone repeats. There's more on the joining side in our crossplay and join codes guide.

What it looks like when it goes wrong

Different mismatches fail in different ways, and the symptom usually tells you which side to go and look at.

Players get kicked the instant they connect, often with a version message. That's a both-sides mod present on the server and missing from their game, and it's the cleanest failure you'll get, because it more or less names itself.

Players connect fine, but something they expected isn't there. Nine times out of ten that's a client-side mod they never actually installed at their end (minimap mods are the usual one, because everyone assumes the server sent it), and the server has nothing to do with it.

The server starts, runs, and behaves as though it were completely unmodded. Read game/BepInEx/LogOutput.log (the Files tab on our panel, the server root on your own machine) before assuming anything else, because that file is the only thing that will tell you whether a plugin loaded, failed outright, or got skipped for a missing dependency. A mod sitting in the right folder and quietly failing to load leaves its stack trace there and nowhere else.

And the awkward one: it worked last week and it doesn't now. Valheim updated, the mod didn't, and BepInEx is refusing to load a plugin built against a version of the game that no longer exists in that shape. Normal for a fortnight after any big patch. Worse than normal after 1.0, which also upgraded the Unity engine. Check the mod's Thunderstore page for a release from after 9 September.

Installing server-side and client-side mods on a LOW.MS server

Server side first, and BepInEx before anything else, because it's a dependency rather than a background detail. On a self-hosted box you'd download BepInExPack and unzip it over the server files. Then you'd check the loader is actually picking things up before adding a single plugin. On our panel that's the Mods tab's job: search Thunderstore from Browse, hit Install, and BepInExPack comes along as a dependency if it isn't there already. Start the server once and open the Console tab. You want the BepInEx banner and a list of plugins under it. If that banner never appears, nothing you install afterwards is going to run, and you'll spend an hour proving it the hard way.

Then the mods themselves, from the same place. Browse covers the whole of Thunderstore, not a curated shortlist, so if a mod exists it's there, and Install from URL takes a pasted Thunderstore link if you'd rather. Each row shows when the mod was last updated, which is the quickest 1.0 check you'll get. The version you install is the current Thunderstore release at that moment, and it stays there until something moves it: the Installed tab has an auto-update setting for the server (off, frameworks only, or all mods) and each mod can override it. On a world people are actively playing on I'd leave it on frameworks only. A both-sides mod updating under you on a Wednesday, while your players are still on last week's build, is the version-check kick from the top of this article arriving from the other direction.

One thing the panel won't do is take a .dll you upload. The Files tab refuses them. That's deliberate: the Mods tab is the only route that keeps dependencies and updates straight, and a hand-dropped plugin is invisible to it. Mod genuinely not on Thunderstore? Open a ticket with the link and we'll get it on the server for you.

Client side, your players handle their own, and r2modman is what I'd point them at. It keeps a separate profile per server, so nobody has to tear down their whole setup just to play somewhere else for an evening. Thunderstore's own manager works too. Manual installs into BepInEx/plugins are fine for one confident person and a genuine nightmare across a group of six.

Mod configs are ordinary text, and you can edit them yourself in the Files tab under game/BepInEx/config/, one file per mod. Change a value, save, restart. If the mod syncs its config through ServerSync, the server's copy wins and everyone picks it up on join, which is one more reason to keep both-sides mods on both sides. The step-by-step lives in our mod installation guide, and if you're still picking, best Valheim mods for 1.0 dedicated servers is a reasonable place to start.

When to open a ticket

Come to us when a mod you want isn't on Thunderstore at all, when the server's version and your players' versions have drifted apart and you can't see why, or when the log shows a plugin failing to load and the stack trace isn't telling you anything. Send the Thunderstore link and the last fifty lines of game/BepInEx/LogOutput.log from the Files tab. With those two things we can usually tell you what's wrong before we've even connected to the box.

And if you're still deciding where to put the world in the first place, our Valheim server hosting plans come with the Mods tab and Thunderstore built in, so the server side of all this is a few clicks rather than an evening.

Free toolValheim Server Settings Generator

Turn the world modifiers you want into the exact launch arguments a Valheim dedicated server expects, ready to paste into your panel.

Open tool →

Join our Discord to chat with our staff and community!

Join Discord