{"id":370,"date":"2021-03-11T17:24:19","date_gmt":"2021-03-11T17:24:19","guid":{"rendered":"https:\/\/xgamingserver.com\/blog\/?p=370"},"modified":"2026-06-14T17:00:45","modified_gmt":"2026-06-14T17:00:45","slug":"how-to-add-install-mods-to-a-dedicated-valheim-server","status":"publish","type":"post","link":"https:\/\/xgamingserver.com\/blog\/how-to-add-install-mods-to-a-dedicated-valheim-server\/","title":{"rendered":"How to Add\/Install Mods to a Valheim Server | BepInEx|uMod| V+"},"content":{"rendered":"\n

Modding a dedicated Valheim server is where a co-op world stops being “vanilla survival” and becomes something tuned to exactly how your group plays \u2014 bigger build budgets, quality-of-life tweaks, extra biome content, or admin tooling that the base game flat-out refuses to expose on a dedicated host. The catch is that Valheim mods don’t drop into the game the way a Minecraft jar does. Almost everything runs through a community framework called BepInEx, and a dedicated server adds a second rule that trips up most first-timers: the server and every connecting player frequently have to run the same<\/em> mods at compatible versions, or nobody connects.<\/p>\n\n\n\n

This guide walks the full pipeline end to end \u2014 installing BepInEx on the server, placing plugins in BepInEx\/plugins<\/code>, the difference between server-side and client-side mods, where the configs live in BepInEx\/config<\/code>, the Thunderstore and r2modman workflow that makes matching painless, and finally how to confirm the stack actually loaded instead of silently failing. Everything here targets the current Early Access live build (the 0.21x patch family, Ashlands content), with notes where behavior is host-dependent.<\/p>\n\n\n\n

What BepInEx actually is (and why you need it)<\/h2>\n\n\n\n

BepInEx is a Unity plugin and patcher framework. It loads before<\/em> the game’s own code runs and injects mod code without modifying the original game files. That “non-destructive” behavior is why removing or renaming one folder reverts you to clean vanilla \u2014 BepInEx never touched the underlying executable in the first place. Valheim’s mod scene standardized on it years ago, and the Valheim-specific build you want is BepInExPack_Valheim<\/strong> by the author denikson<\/em>, distributed on Thunderstore.<\/p>\n\n\n\n

Individual mods you’ll see referenced \u2014 Valheim Plus, Epic Loot, Better Networking, Server Devcommands \u2014 are all plugins<\/em> that load through BepInEx. They are useless without the framework present, and the framework alone does nothing until you add plugins to it. Install order is therefore always: framework first, plugins second.<\/p>\n\n\n\n

Step 1 \u2014 Install BepInEx into the server root<\/h2>\n\n\n\n

Download BepInExPack_Valheim from Thunderstore and unpack it. Inside the archive you’ll find the framework files plus a top-level BepInEx\/<\/code> folder. You need to copy the contents<\/em> of the pack into your Valheim server root<\/strong> \u2014 the folder that contains valheim_server.exe<\/code> (or valheim.exe<\/code> on a self-host that doubles as a client). Done correctly, the server root now contains a BepInEx\/<\/code> folder, and inside it a plugins\/<\/code> subfolder.<\/p>\n\n\n\n

The folder layout you’re aiming for looks like this:<\/p>\n\n\n\n

valheim_server.exe\nstart_headless_server.bat        (Windows start script)\nBepInEx\/\n\u251c\u2500\u2500 core\/                        (the framework itself)\n\u251c\u2500\u2500 plugins\/                     (your .dll mods go HERE)\n\u251c\u2500\u2500 config\/                      (auto-generated on first launch)\n\u2514\u2500\u2500 BepInEx.cfg                  (framework settings)<\/code><\/pre>\n\n\n\n
A common mistake is dropping the BepInEx<\/code> folder one level too deep (e.g. into a winhttp<\/code> subfolder, or inside the save directory). It must sit directly beside the server executable. If you’re on a managed\/game-panel host, the file manager will usually drop you into the server root by default \u2014 that’s exactly where these files belong.<\/p>\n\n\n\n
Self-hosting vs. managed hosting<\/h3>\n\n\n\n
On a self-hosted box you have raw filesystem access, so this is a copy-paste operation. On a managed host you’ll typically upload the unpacked files through a web file manager or SFTP. The mechanics are identical; only the access method differs. If you’d rather skip the infrastructure entirely and just manage mods, our fully managed Valheim hosting plans<\/a> ship with the file access and resource headroom that modded worlds actually need (modding is RAM-hungry \u2014 more on that below). For the panel-specific walkthrough on our platform, see the XGamingServer Valheim docs<\/a>.<\/p>\n\n\n\n
Step 2 \u2014 Drop plugins into BepInEx\/plugins<\/h2>\n\n\n\n
Every Valheim mod ships as one or more .dll<\/code> files, sometimes alongside a default config or asset files. The rule is simple: each mod’s .dll<\/code> goes into BepInEx\/plugins\/<\/code>. Many authors package their mod inside a folder (e.g. BepInEx\/plugins\/EpicLoot\/EpicLoot.dll<\/code> plus asset subfolders); BepInEx scans plugins\/<\/code> recursively, so keeping a mod in its own subfolder is fine and actually keeps things tidy.<\/p>\n\n\n\n
After you’ve added plugins, start the server once. That first launch is what generates the BepInEx\/config\/<\/code> folder and writes out a default .cfg<\/code> file for each plugin that exposes settings. Don’t skip this \u2014 many people try to edit a config before it exists, get confused, and assume the mod failed.<\/p>\n\n\n\n
Step 3 \u2014 The critical part: server-side vs. client-side mods<\/h2>\n\n\n\n
This is the single most important concept in Valheim modding and the cause of nearly every “I installed mods and now nobody can join” support ticket.<\/p>\n\n\n\n
For the majority of gameplay mods<\/strong>, BepInEx and the matching plugins must be installed on both the server and every player’s client<\/strong>, at compatible versions. If a mod changes game logic, items, recipes, world generation, or anything the simulation cares about, an unmodded client (or a client running a different version) will either be rejected at connect or will desync the moment something mod-specific happens.<\/p>\n\n\n\n
The exceptions are client-only mods<\/strong> \u2014 purely cosmetic or local quality-of-life tweaks (custom UI, minimap enhancements, camera tweaks, sorting helpers) that don’t touch shared state. Those can live on a player’s client without being on the server, and vice versa. A handful of mods are explicitly server-only<\/strong> as well \u2014 they enforce or configure behavior the server owns and don’t need to exist on clients.<\/p>\n\n\n\n
Mod type<\/th>Install on server?<\/th>Install on clients?<\/th>Examples<\/th><\/tr><\/thead>
Gameplay \/ content \/ logic<\/td>Yes<\/td>Yes (all of them)<\/td>Valheim Plus, Epic Loot, new biomes\/items<\/td><\/tr>
Client cosmetic \/ local QoL<\/td>No<\/td>Optional, per player<\/td>Custom UI, minimap, camera tweaks<\/td><\/tr>
Server admin \/ enforcement<\/td>Yes<\/td>Usually no<\/td>Server Devcommands, Better Networking<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The practical takeaway: version-match aggressively<\/strong>. When you update a gameplay mod on the server, push the same version to every player before they reconnect. Mismatched versions are just as fatal as missing mods. Treat the modlist as one synchronized unit across the whole group.<\/p>\n\n\n\n
Step 4 \u2014 Configuring mods in BepInEx\/config<\/h2>\n\n\n\n
Once the server has launched at least once with a plugin installed, look in BepInEx\/config\/<\/code>. You’ll find a .cfg<\/code> file per configurable mod \u2014 these are plain text, organized into [Section]<\/code> headers with key = value<\/code> pairs and inline comments describing each option. This is where you set drop rates, build limits, networking caps, feature toggles, and so on.<\/p>\n\n\n\n
## Example shape of a BepInEx mod config (BepInEx\/config\/SomeMod.cfg)\n[General]\n\n## Enable the mod's core feature\n# Setting type: Boolean\nEnableFeature = true\n\n## Multiplier applied to a gameplay value\n# Setting type: Single\nSomeMultiplier = 1.5<\/code><\/pre>\n\n\n\n
Two things matter here. First, configs that affect shared gameplay generally need to match on server and clients too \u2014 the same matching rule applies to settings, not just the presence of the mod. Second, many mods support config syncing (the server pushes authoritative config to clients on connect) but this is mod-specific; read each mod’s Thunderstore page. After editing any config, restart the server<\/strong> so the new values load. Editing a .cfg<\/code> while the server is running does nothing until the next restart unless the mod explicitly watches for changes.<\/p>\n\n\n\n
The Thunderstore + r2modman workflow (strongly recommended)<\/h2>\n\n\n\n
You can<\/em> manage everything by hand \u2014 download each .dll<\/code>, track versions in a spreadsheet, and copy files around. For one or two mods that’s fine. For a real modpack, use a mod manager. Thunderstore<\/strong> is the package repository where Valheim mods live, and r2modman<\/strong> (and the Thunderstore Mod Manager app) is the manager that installs them with dependencies resolved automatically.<\/p>\n\n\n\n
The workflow that keeps server and clients perfectly in sync:<\/p>\n\n\n\n
  1. In r2modman, create a profile<\/strong> for your server and add every gameplay mod you want, at the versions you want.<\/li>
  2. Let r2modman pull in dependencies (most mods list BepInExPack_Valheim as a dependency, so it’s handled for you).<\/li>
  3. Use r2modman’s export profile<\/strong> feature to produce a shareable code or file. Send it to every player so they import the identical profile \u2014 instant version match.<\/li>
  4. For the server itself, locate the profile’s BepInEx<\/code> folder on disk (r2modman keeps it under its profiles directory) and upload its plugins<\/code> and config<\/code> contents to the server root, or use a host that integrates Thunderstore directly.<\/li><\/ol>\n\n\n\n
    This is the difference between a 5-minute mod update for the whole group and an evening of “who’s on the wrong version” debugging. The profile export is the killer feature \u2014 it turns the matching requirement from a chore into a one-click share.<\/p>\n\n\n\n
    Step 5 \u2014 Verifying the mods actually loaded<\/h2>\n\n\n\n
    Never assume a mod loaded just because the file is in the folder. Verify it.<\/p>\n\n\n\n