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 — 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 mods at compatible versions, or nobody connects.
This guide walks the full pipeline end to end — installing BepInEx on the server, placing plugins in BepInEx/plugins, the difference between server-side and client-side mods, where the configs live in BepInEx/config, 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.
What BepInEx actually is (and why you need it)
BepInEx is a Unity plugin and patcher framework. It loads before 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 — 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 by the author denikson, distributed on Thunderstore.
Individual mods you’ll see referenced — Valheim Plus, Epic Loot, Better Networking, Server Devcommands — are all plugins 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.
Step 1 — Install BepInEx into the server root
Download BepInExPack_Valheim from Thunderstore and unpack it. Inside the archive you’ll find the framework files plus a top-level BepInEx/ folder. You need to copy the contents of the pack into your Valheim server root — the folder that contains valheim_server.exe (or valheim.exe on a self-host that doubles as a client). Done correctly, the server root now contains a BepInEx/ folder, and inside it a plugins/ subfolder.
The folder layout you’re aiming for looks like this:
valheim_server.exe
start_headless_server.bat (Windows start script)
BepInEx/
├── core/ (the framework itself)
├── plugins/ (your .dll mods go HERE)
├── config/ (auto-generated on first launch)
└── BepInEx.cfg (framework settings)A common mistake is dropping the BepInEx folder one level too deep (e.g. into a winhttp 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 — that’s exactly where these files belong.
Self-hosting vs. managed hosting
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 ship with the file access and resource headroom that modded worlds actually need (modding is RAM-hungry — more on that below). For the panel-specific walkthrough on our platform, see the XGamingServer Valheim docs.
Step 2 — Drop plugins into BepInEx/plugins
Every Valheim mod ships as one or more .dll files, sometimes alongside a default config or asset files. The rule is simple: each mod’s .dll goes into BepInEx/plugins/. Many authors package their mod inside a folder (e.g. BepInEx/plugins/EpicLoot/EpicLoot.dll plus asset subfolders); BepInEx scans plugins/ recursively, so keeping a mod in its own subfolder is fine and actually keeps things tidy.
After you’ve added plugins, start the server once. That first launch is what generates the BepInEx/config/ folder and writes out a default .cfg file for each plugin that exposes settings. Don’t skip this — many people try to edit a config before it exists, get confused, and assume the mod failed.
Step 3 — The critical part: server-side vs. client-side mods
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.
For the majority of gameplay mods, BepInEx and the matching plugins must be installed on both the server and every player’s client, 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.
The exceptions are client-only mods — 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 as well — they enforce or configure behavior the server owns and don’t need to exist on clients.
| Mod type | Install on server? | Install on clients? | Examples |
|---|---|---|---|
| Gameplay / content / logic | Yes | Yes (all of them) | Valheim Plus, Epic Loot, new biomes/items |
| Client cosmetic / local QoL | No | Optional, per player | Custom UI, minimap, camera tweaks |
| Server admin / enforcement | Yes | Usually no | Server Devcommands, Better Networking |
The practical takeaway: version-match aggressively. 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.
Step 4 — Configuring mods in BepInEx/config
Once the server has launched at least once with a plugin installed, look in BepInEx/config/. You’ll find a .cfg file per configurable mod — these are plain text, organized into [Section] headers with key = value pairs and inline comments describing each option. This is where you set drop rates, build limits, networking caps, feature toggles, and so on.
## Example shape of a BepInEx mod config (BepInEx/config/SomeMod.cfg)
[General]
## Enable the mod's core feature
# Setting type: Boolean
EnableFeature = true
## Multiplier applied to a gameplay value
# Setting type: Single
SomeMultiplier = 1.5Two things matter here. First, configs that affect shared gameplay generally need to match on server and clients too — 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 so the new values load. Editing a .cfg while the server is running does nothing until the next restart unless the mod explicitly watches for changes.
The Thunderstore + r2modman workflow (strongly recommended)
You can manage everything by hand — download each .dll, 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 is the package repository where Valheim mods live, and r2modman (and the Thunderstore Mod Manager app) is the manager that installs them with dependencies resolved automatically.
The workflow that keeps server and clients perfectly in sync:
- In r2modman, create a profile for your server and add every gameplay mod you want, at the versions you want.
- Let r2modman pull in dependencies (most mods list BepInExPack_Valheim as a dependency, so it’s handled for you).
- Use r2modman’s export profile feature to produce a shareable code or file. Send it to every player so they import the identical profile — instant version match.
- For the server itself, locate the profile’s
BepInExfolder on disk (r2modman keeps it under its profiles directory) and upload itspluginsandconfigcontents to the server root, or use a host that integrates Thunderstore directly.
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 — it turns the matching requirement from a chore into a one-click share.
Step 5 — Verifying the mods actually loaded
Never assume a mod loaded just because the file is in the folder. Verify it.
- Watch the server console / log on startup. BepInEx prints its own banner first (“BepInEx … by Bepis”), then logs each plugin it loads by name and version — e.g.
Loading [Epic Loot 0.x.x]. If a plugin is inplugins/but never appears in the log, it didn’t load (wrong target framework, bad.dll, or a missing dependency). - Check for the config files. If
BepInEx/config/contains the mod’s.cfgafter a launch, the mod ran far enough to register its settings. - Connect with a matched client and look for in-game effects — a mod’s UI panel, new items, or an admin command that only exists when the plugin is present.
- Look for load errors in the log. Lines containing
Erroror a stack trace next to a plugin name almost always mean a version mismatch against the current Valheim build, or a dependency that loaded out of order.
If BepInEx itself doesn’t print its banner, the framework isn’t installed in the right place — go back to Step 1 and confirm the BepInEx folder sits directly beside valheim_server.exe.
Admin commands, dev commands, and the dedicated-server trap
Modding is often paired with admin work, so it’s worth knowing a hard limitation that surprises everyone: on a vanilla dedicated server, the powerful cheat/dev commands — god, fly, spawn, genloc, debugmode — do not work, even for admins. The wiki is explicit that these are available “in singleplayer or manually hosted mode only.” A dedicated server admin (listed in adminlist.txt by SteamID64, one ID per line, no comments) can only use a small set: kick, ban/unban/banned, save, ping, and the world-modifier commands like setworldmodifier and setworldpreset.
So how do you get spawning and god mode on a dedicated server? With a mod. The Server Devcommands plugin (Thunderstore, BepInEx) re-enables the dev command set on a dedicated host — a perfect example of mods filling a gap the base game leaves open. If you want the full breakdown of what works where, see our Valheim console commands and creative-mode prefab guide.
Resource requirements for a modded server
Mods cost memory. A vanilla Valheim server already wants real RAM, and heavy content mods (Valheim Plus, Epic Loot) push that higher. Plan accordingly:
| Scenario | RAM | CPU note |
|---|---|---|
| Bare minimum (tiny vanilla world) | ~2 GB | Single-core clock matters most |
| Typical small world / few players | ~3 GB | Aim for ≥3.0 GHz per core |
| 2–10 players | 4 GB+ | Below 3.0 GHz causes rubber-banding |
| 10+ players or heavy mods | 8 GB+ | Server is largely single-threaded |
Two things to internalize. First, RAM usage grows with explored world size and structure count, so a long-running modded world will need more headroom over time — restart the server periodically to reclaim memory. Second, Valheim’s server loop is largely single-threaded, so a high single-core clock speed beats raw core count; CPUs below ~3.0 GHz are repeatedly cited as a cause of desync. If you’re modding for a group, also look at the Better Networking mod — the dedicated server has a hard-coded per-client send/receive cap around 64 KB/s, and Better Networking raises it (256 KB/s+), which is the single biggest fix for multiplayer rubber-banding. We cover this in depth in how to fix lag and desync on a Valheim dedicated server.
Going vanilla again, or troubleshooting
When something breaks, the fastest diagnostic is to remove mods and confirm the server runs clean. The verified, reliable method is to rename or remove the BepInEx folder (e.g. to Disabled BepInEx), which switches the whole framework off and reverts to pure vanilla. To disable a single mod instead, remove or rename just its .dll in BepInEx/plugins/. There’s a full walkthrough — including profile-based toggling — in our guide to disabling Valheim BepInEx mods.
When you reintroduce mods after a fix, add them back in small batches and check the log between batches — it’s far easier to find the one broken plugin that way than by loading twenty at once and staring at a wall of errors.
Frequently asked questions
Do mods need to be installed on both the server and the client?
For most gameplay mods, yes — BepInEx and the matching plugins must be on the server and on every connecting player’s client, at compatible versions, or connections fail and the world desyncs. The exceptions are client-only cosmetic/quality-of-life mods (which a player can run locally without the server having them) and a few server-only enforcement mods. When in doubt, install the same modpack everywhere; the r2modman profile-export feature makes that a one-click share.
Where exactly do I put Valheim mod .dll files?
In BepInEx/plugins/ inside your server root (the folder that holds valheim_server.exe). BepInEx scans that folder recursively, so a mod kept in its own subfolder like BepInEx/plugins/EpicLoot/ works fine. Config files are auto-generated separately into BepInEx/config/ the first time the server launches with that plugin present.
Why won’t my modded server show up or let players join?
The two usual causes are a version mismatch (server and client running different versions of the same gameplay mod) and a missing mod on one side. Confirm every player has the identical modlist and versions as the server, then re-check the server log to verify each plugin actually loaded — a .dll in the folder that never appears in the startup log didn’t load, often because it’s built for a different Valheim version than the current live build. Also make sure BepInEx itself prints its banner; if not, the framework is in the wrong location.
Can I use spawn, god, or fly commands on my modded dedicated server?
Not on a vanilla dedicated server — god, fly, spawn, genloc, and debugmode are restricted to singleplayer or manually hosted (listen-server) play and don’t work on a dedicated host even for admins. The fix is the Server Devcommands mod from Thunderstore, installed via BepInEx like any other plugin, which re-enables the dev command set for admins on a dedicated server.
How do I update a mod without breaking the server?
Update the server and all clients together. Bump the version in your r2modman profile, re-export it, and share the new profile with players before anyone reconnects. Replace the corresponding files on the server, restart so new .cfg values load, then check the startup log to confirm the new version loaded cleanly. Never update one side and not the other — a version skew is as fatal as a missing mod.
Do mods carry over to the public-test beta branch?
Test branches usually ship code changes that break mods built against the live build, so expect plugins to need updates (or to be temporarily incompatible) on public-test. The public-test branch is also code-gated — the access code is yesimadebackups — and back up your .db and .fwl world files before opting in. Note that as of late 2024 the SteamCMD anonymous download of the dedicated server may require game ownership. See our guide to the Valheim public-test beta for the full opt-in process.
Wrapping up
The whole pipeline reduces to five moves: install BepInExPack_Valheim into the server root, drop plugins into BepInEx/plugins, match the server’s gameplay mods on every client at the same versions, tune behavior in BepInEx/config (and restart to apply), and verify the load in the startup log. Use r2modman with profile export to make the matching step painless, and lean on mods like Server Devcommands and Better Networking to fill the gaps the dedicated server leaves open. If you want to compare hosting models before you commit hardware to a modded world, our breakdown of dedicated vs. slot-based Valheim hosting explains why RAM and single-core clock — not slot counts — decide how smooth a modded server actually runs.
Ready to play?
Run your own Valheim 1.0 server with XGamingServer
Spin up an always-on Valheim 1.0 server your friends can join in minutes — no port-forwarding, no tech headaches.
