Valheim mods on a dedicated server with BepInEx

Valheim has no mod API. Every mod you have ever seen for it is a .NET assembly injected into the game process by BepInEx, and installing them on a dedicated server means unpacking one archive into the server's root folder, dropping .dll files into BepInEx/plugins, and starting the server through a different script than the one you have been using. That last part is where most people stall: the server comes up, the world loads, players connect, and not a single mod is running, because nothing told the process to load them. This post is the whole chain, from the injector to the patch that breaks everything three weeks later. The rest of the server - ports, launch arguments, admin lists, saves - is in the Valheim dedicated server guide.

What BepInEx is, and what it is not#

BepInEx is a plugin loader for Unity games. It hooks the runtime before the game's own code starts, loads assemblies from a plugins folder, and gives them a patching library (Harmony) to rewrite the game's methods in memory. Nothing is modified on disk. Remove the BepInEx folder and you have a vanilla server again, which is the single most useful property it has when you are debugging.

The Valheim-specific distribution is BepInExPack Valheim, published on Thunderstore. Take that one rather than upstream BepInEx: it is pinned to the Unity and Mono versions Valheim ships, it includes the unstripped runtime libraries the game's build strips out, and it includes the start scripts. Upstream BepInEx will load and then fail in ways that look like a broken mod.

Three things BepInEx is not. It is not a server-side-only system: the server and every client run their own copy, and they have to agree. It is not version-tolerant: a mod compiled against last month's Valheim will throw on the first method it cannot find. And it is not supported by Iron Gate, so every problem in this post is a community problem with a community answer.

Installing the pack on a server#

Download BepInExPack Valheim from Thunderstore and open the archive. Inside is a folder called BepInExPack_Valheim, and it is the contents of that folder that go into the server root, next to valheim_server.x86_64. Copying the wrapper folder itself is the first classic mistake; you end up with BepInExPack_Valheim/BepInEx/ and nothing loads.

After a correct install the server root looks like this:

valheim_server.x86_64start_server.sh                  the original, unmodifiedstart_server_bepinex.sh          the one you now usedoorstop_libs/                   libdoorstop_x64.sounstripped_corlib/BepInEx/    core/                        BepInEx itself    plugins/                     your mods go here    patchers/                    a few mods need this    config/                      generated on first run

On Windows the injector is winhttp.dll in the server root plus doorstop_config.ini, and you carry on launching valheim_server.exe as normal. On Linux the injection is done with environment variables, which is what start_server_bepinex.sh sets before handing off to the real binary:

export DOORSTOP_ENABLE=TRUEexport DOORSTOP_INVOKE_DLL_PATH=./BepInEx/core/BepInEx.Preloader.dllexport DOORSTOP_CORLIB_OVERRIDE_PATH=./unstripped_corlibexport LD_LIBRARY_PATH="./doorstop_libs:$LD_LIBRARY_PATH"export LD_PRELOAD="libdoorstop_x64.so:$LD_PRELOAD"./valheim_server.x86_64 -nographics -batchmode -name "Crew" -port 2456 \    -world "Midgard" -password "herring-barrel-42"

That block is worth understanding rather than copying, because on a managed host you often cannot replace the start script. What you can usually do is set environment variables, and the five lines above are the whole mechanism. If your panel exposes environment variables on the Startup tab, BepInEx can be switched on there without touching the command. If it does not, ask - it is a one-line change on the host's side and a common request.

Confirm it worked by reading the console at startup. Before any Valheim output you should see a BepInEx banner and then one line per plugin:

[Message:   BepInEx] BepInEx 5.4.2202 - valheim_server[Info   :   BepInEx] Loading [ServerDevcommands 1.70][Info   :   BepInEx] Loading [DiscordConnector 3.1.0]

No banner means the process started without the injector, and every other symptom you are chasing is downstream of that. The same output is written to BepInEx/LogOutput.log, which is the file to download when something fails after the console has scrolled past - logs worth keeping makes the general case for grabbing it before restarting.

Server-side, client-side, and both#

This is the distinction that decides whether your server works, and mod pages are not always clear about it.

The reason the third row exists is that Valheim's multiplayer is not authoritative. The server stores the world and relays state, but the client that owns a zone simulates it, so a rule change has to exist on both sides or the two disagree about what just happened. A recipe added only on the server does not appear in anyone's crafting menu; a creature added only on a client spawns for that player and immediately vanishes when the server does not recognise it.

A short list of mods that are safe to name because they are stable, widely used and unambiguous about which side they belong on:

• Jotunn and HookGenPatcher - libraries, not mods. A great many content mods depend on Jotunn; HookGenPatcher goes in BepInEx/patchers, not plugins, and putting it in the wrong folder produces a dependency error that reads as if Jotunn is missing.
• ServerSync - a library that lets a mod push its configuration from the server to every client and refuse clients whose version does not match. If a mod depends on it, its settings are server-authoritative and editing them on a client does nothing.
• Server Devcommands - the answer to "why does devcommands not work on my dedicated server". It runs on the server and gives listed admins the cheat and debug command set that vanilla restricts to single player.
• Discord Connector - server-side only. Posts joins, deaths and server start and stop to a webhook. Nothing for players to install.
• ServerCharacters - moves character data from the player's machine to the server, which stops people arriving with items from a creative world. Needs installing on both sides.
• ValheimPlus (the maintained community fork) - one large configuration mod covering build, stamina, carry weight and dozens of other values. Both sides, and the config file is BepInEx/config/valheim_plus.cfg rather than the usual per-mod name.
• Epic Loot and Plant Everything - content and rules mods, both sides, both well behaved.

Everything else: read the author's page. The line "install on the server as well" or "clients only" is always there, and getting it wrong is the difference between a working evening and an hour of reinstalling.

Configuration files and keeping them in one place#

The first start with a new mod generates BepInEx/config/<mod GUID>.cfg. Nothing useful exists before that, so the install sequence is: upload the .dll, start the server, stop the server, edit the config, start again.

Config files are plain INI with comments and default values written in, which makes them readable but also means they are rewritten on start. A key the mod no longer recognises is dropped, and a key you added by hand into the wrong section is silently ignored. Keep your own copy of the edits outside the server rather than treating the live file as your record.

For mods built on ServerSync you will see a section marked as synchronised with the server. Those values are pushed to clients on connect, and a player editing them locally has no effect - which is the point. Anything not marked that way is per-machine, and a group can end up with three different ideas of the carry-weight limit without realising.

BepInEx/config/BepInEx.cfg holds the loader's own settings. The two worth knowing are the logging level, which you turn up while debugging and back down after, and HideManagerGameObject, which several mods require to be true and will tell you about in their own install instructions.

Keeping every player on the same list#

The failure everybody hits once: the server runs eleven mods, one player installed ten, and they are kicked on connect with an incompatible-version message or, worse, they connect and the world behaves oddly for everybody near them.

Three approaches, in order of how well they work:

1. A mod manager profile. r2modman, Thunderstore Mod Manager and Gale all let you build a profile and export it as a code or a file. Send one code to the group; each person imports it and gets identical mods at identical versions. This is by far the least painful method and it is what most servers settle on.
2. A zip of `BepInEx/plugins` and `BepInEx/config`. Crude, works, and puts you in the business of re-sending it every time you change a mod.
3. Version enforcement in the mods themselves. Mods using ServerSync will refuse a mismatched client with a clear message. That is a safety net, not a distribution method.

Whichever you pick, write the mod list and versions down somewhere the group can read - a pinned Discord message is fine. The list is the thing you will need at three in the morning after a patch, and "whatever was installed in March" is not a list. Keeping a modded server clean goes further into the hygiene side of this.

Resource cost and start-up time#

Mods cost memory and start-up time, not usually frame rate. The Valheim dedicated server guide puts a vanilla server for a full group at 4 GB; a content-heavy modded server wants 6 to 8 GB, and the growth comes from prefabs and asset bundles loaded once at start rather than from anything that scales with players.

Start-up time is the surprise. A vanilla Valheim server is ready in well under a minute. A server with thirty mods, several of them registering new items and creatures through Jotunn, can take two or three minutes before it accepts a connection, most of it spent in the preloader. Two consequences: do not assume a slow start is a hang, and be aware that automatic crash detection can misread it. On RE:NODE the watcher looks for a server that went offline or whose uptime went backwards, and three restarts in an hour raises a warning and opens a ticket - a modded server stuck in a start-crash-start loop will trip that, which is the system working, but it is worth knowing before it happens. Why your game server keeps restarting covers the loop itself.

If memory climbs steadily on a modded server and never comes back down, check which mods add persistent world objects before you buy a bigger plan. Plant and build mods increase the number of stored objects in the world permanently, and that shows up as both memory and save-file size. CPU vs RAM for game servers has the method for telling which limit you are actually hitting.

The day a patch lands#

Every Valheim update breaks mods. Not some updates - every one that touches the assemblies, which is nearly all of them. The sequence that keeps a server alive:

1. Turn off automatic updates on a modded server, or at least know where the switch is. An update that lands while people are playing takes the server offline until you act.
2. Back up the whole `BepInEx` folder and the world before touching anything. A copy of plugins and config at a known-good version is worth more than any amount of care afterwards. Backups that actually restore is the argument for testing that copy rather than trusting it.
3. Wait for the mods, not the game. Update BepInExPack first if it has moved - it does after a Unity change - then each mod, then the server.
4. Start with the mods disabled if you are in a hurry. Move plugins aside, run vanilla, and let people play while you catch up. A world is not harmed by running without mods for an evening, though items added by a content mod will not exist while it is gone, so stop short of that if anyone has a chest full of modded gear.

The order matters because a game update with old mods in place gives you a wall of exceptions with no useful first line. What to do when a mod update breaks is the general version of this procedure.

Troubleshooting#

No BepInEx banner in the console. The server started without the injector. On Linux that means the environment variables were not set; on Windows, that winhttp.dll is missing from the root.

`libdoorstop_x64.so: cannot open shared object file`. doorstop_libs is not where the script expects it, usually because the wrapper folder from the archive was copied instead of its contents.

`Could not load [Mod] because it requires [Jotunn]`. A dependency is missing, or HookGenPatcher is in plugins instead of patchers. Mod pages list dependencies; install them all.

Two copies of the same plugin. A duplicate GUID error, caused by both a loose .dll and a folder containing the same .dll in plugins. Pick one layout - a folder per mod is easier to manage - and clear the other.

Clients connect and are immediately disconnected. Version mismatch enforced by a mod. The server log names the mod and the two versions; that line is the answer.

`MissingMethodException` or `TypeLoadException` after an update. A mod compiled against the previous game version. Nothing to fix locally; wait for the author.

Mods load but nothing changes in game. Either the mod is client-side and you installed it only on the server, or its config has it disabled by default. Check BepInEx/config for the generated file before assuming it failed.

The world is fine but a modded item disappeared. The mod that created it is no longer loading. Valheim removes objects it cannot resolve when the zone is next loaded, and the loss is permanent once the world is saved. Stop the server before investigating a mod that has gone missing.

FAQ#

Can I add mods to a world that already exists?

Yes, and interface, quality-of-life and rules mods are safe to add mid-world. Content mods that add buildable pieces or creatures are also fine to add. Removing one later is the risky direction, because everything it placed in the world stops resolving.

Do all players need the same mods?

They need the same mods in the "both sides" category, at matching versions. Client-only mods are a personal choice and server-only mods are invisible to players. In practice a group shares one profile because sorting out which is which for twelve mods is more work than just sharing the list.

Does BepInEx work with crossplay?

The server runs fine with both. The limitation is on the player side: Xbox and Microsoft Store players cannot load mods, so any mod that needs a client copy locks them out. Server-side-only mods are invisible to them and cause no trouble.

Where do mod settings live on a server?

BepInEx/config, one file per mod, generated on the first start after the mod is installed. Settings marked as synchronised with the server are pushed to clients on connect; the rest are per-machine.

Why does devcommands still not work after installing mods?

Because it is disabled on dedicated servers by the game, not by a missing mod. Server Devcommands is the mod that re-enables it, and it grants the commands to accounts listed in adminlist.txt rather than to everybody.

How many mods is too many?

There is no hard limit; the practical ceiling is start-up time and your patience on patch day. Thirty mods is a normal large list and adds minutes to every start. Every mod is also one more thing that can stop being maintained, so a list you can read in one screen ages much better than one you cannot.