Mods can transform a Valheim dedicated server, but sooner or later every admin needs to turn them off again. Maybe a plugin broke after a game patch, maybe a friend can’t connect because their client doesn’t match your modded server, or maybe you simply want to roll back to a clean vanilla world. Whatever the reason, disabling BepInEx mods is one of the most common server-admin tasks in Valheim, and doing it cleanly is the difference between a five-minute fix and an hour of confused troubleshooting.
This guide covers everything: what BepInEx actually is, how to disable every mod at once, how to remove just a single misbehaving plugin, why your server and clients must stay in sync, how to revert all the way back to true vanilla, and how to rescue a modded server that won’t start or won’t accept connections. Every method here is the community-verified approach used on real dedicated servers.
What BepInEx Is (and Why Disabling It Matters)
BepInEx is the community Unity plugin and patcher framework that almost every Valheim mod loads through. It runs before the game itself starts and injects mod code into memory, without altering the original game files on disk. That last detail is important: because BepInEx never edits Valheim’s actual executables or assets, “uninstalling” mods is mostly a matter of stopping that injection from happening — your base game stays untouched the whole time.
The Valheim-specific distribution is the BepInExPack_Valheim package (by denikson) from Thunderstore. When you install it, it unpacks into your Valheim game or server root — the same folder that holds valheim_server.exe (or valheim.exe on a client) — and creates a BepInEx/ folder. Inside that folder lives the structure you’ll be working with whenever you enable or disable mods:
BepInEx/plugins/— every mod’s.dllfile lives here. This is what you add to or remove from.BepInEx/config/— per-mod configuration files, generated on first launch.BepInEx/core/— the framework itself.
Once you understand that mods are just DLLs sitting in BepInEx/plugins/, and that the whole framework lives under one BepInEx folder, disabling becomes straightforward. You’re either switching off the entire framework or pulling out individual plugin files. If you haven’t installed mods yet and want the full setup walkthrough first, see our companion guide on how to add and install mods to a dedicated Valheim server.
The Golden Rule: Server and Client Must Match
Before you touch a single file, internalize the rule that causes the most “why can’t anyone join?” support tickets in Valheim modding: for most gameplay mods, BepInEx and the matching plugins must be installed on both the server and every player’s client, at compatible versions.
This cuts both ways when disabling mods. If you remove a gameplay mod from the server but your players still have it loaded on their clients — or the reverse — you’ll get connection failures, version-mismatch rejections, or in-world desync. The clean approach is to coordinate: disable a gameplay mod on the server and tell every player to disable the same mod before they reconnect.
The exception is client-only mods. Purely cosmetic or quality-of-life mods (custom UI, camera tweaks, minimap helpers) often run only on the client and don’t need to exist on the server at all. You can disable those on individual clients without touching the server. The trouble is that it isn’t always obvious which category a mod falls into, so when in doubt, treat every mod as if it must match on both sides.
Method 1: Disable All Mods by Renaming the BepInEx Folder
This is the most-cited community method and the one to reach for when you want to test whether mods are the cause of a problem, or when you want to go fully vanilla in one move. Because BepInEx only loads if its launcher can find the framework on startup, renaming the folder makes the game launch as if no mods were ever installed — nothing is deleted, so it’s completely reversible.
- Stop the server completely. Never edit mod files while the process is running.
- Navigate to your server root (the folder containing
valheim_server.exe). - Rename the
BepInExfolder to something inert, for exampleBepInEx-disabledorDisabled BepInEx. - Start the server. It now boots as pure vanilla.
From a shell on a Linux host, the rename is a one-liner:
# From the Valheim server root directory
mv BepInEx BepInEx-disabled
# To re-enable every mod again later, just rename it back:
mv BepInEx-disabled BepInExThis approach is perfect as a diagnostic. If your server starts and behaves normally with the folder renamed, you’ve proven the problem is mod-related rather than a hardware, network, or world-corruption issue. If it still misbehaves with BepInEx disabled, the mods are not your culprit.
One note on Windows GUI panels and some managed file managers: a folder name with a space (Disabled BepInEx) works fine, but on command-line hosts it’s cleaner to use a name without spaces like BepInEx-disabled so you don’t have to quote it.
Method 2: Disable Individual Plugins from BepInEx/plugins
Often you don’t want to nuke everything — you want to keep your map mod and your storage mod but kill the one broken plugin that’s crashing the server after a patch. For that, work inside BepInEx/plugins/ directly.
Each mod is one (or a few) .dll files. BepInEx loads every DLL it finds in the plugins folder at startup, so the way to disable a single mod is to make sure its DLL is no longer there when the server boots. You have a couple of safe options:
- Move the DLL out of the plugins folder into a backup folder you create, e.g.
BepInEx/plugins-disabled/. This keeps the file (and its config) intact so you can drop it back later. - Delete the DLL if you’re certain you no longer want the mod. Be aware some mods ship multiple DLLs or a subfolder, so remove the whole mod’s set, not just one file.
- Empty or rename the entire
pluginsfolder if you want to disable all plugins while keeping the BepInEx framework itself loaded — a middle ground between Method 1 and removing single mods.
# Disable one mod while keeping the rest (Linux example)
mkdir -p BepInEx/plugins-disabled
mv "BepInEx/plugins/BrokenMod.dll" BepInEx/plugins-disabled/
# Disable every plugin but keep BepInEx loaded
mv BepInEx/plugins BepInEx/plugins-off
mkdir BepInEx/pluginsAfter moving or deleting plugin files, restart the server and watch the BepInEx console output — it logs each plugin it loads, so you can confirm the one you removed no longer appears in the list.
A Word on the BepInEx.cfg “enabled=false” Method
You’ll sometimes see advice to open BepInEx/config/BepInEx.cfg and flip an enabled = false toggle to switch the framework off without touching folders. The configuration file does contain various toggles, but the exact key to cleanly disable all mod loading isn’t reliably documented across sources, and the section names vary between BepInEx versions. Because of that uncertainty, we recommend the folder-rename method (Method 1) or removing plugin DLLs (Method 2) as the verified, predictable ways to disable mods. If you want to experiment with the cfg toggles, do it on a copy of the file and always keep the proven folder method as your fallback.
Mod Profile Switchers
If you frequently flip between modded and vanilla — say a heavily modded weekday world and a vanilla weekend run — utilities like Bepswitch can toggle BepInEx on and off via saved profiles or loadouts. These are quality-of-life wrappers around the same underlying mechanic (enabling/disabling the framework), so they don’t do anything you can’t do manually, but they make repeated switching faster and less error-prone.
Reverting All the Way Back to Vanilla
Disabling mods and fully reverting to vanilla aren’t quite the same thing. Renaming the BepInEx folder stops mods from loading, but if you want a genuinely clean server — for example to hand it off, to run on the public live branch with zero modded baggage, or to rule out leftover modded data — go a step further:
- Back up your worlds first. Copy both the
.fwland.dbfiles for each world before doing anything destructive. - Disable or delete the BepInEx folder using Method 1.
- Validate the game files through SteamCMD (or your host’s “reinstall/validate” button) so any patched-in files are restored to stock. For a dedicated server that means re-running
app_update 896660 validate. - Be aware of modded world data. Some mods add custom items, structures, or pieces that get written into your
.dbworld file. When you load that world in vanilla, those modded objects can vanish or, in rare cases, log errors. This is exactly why you keep a backup — if a world depended heavily on a content mod, going vanilla may degrade it, and you may prefer to start a fresh vanilla world instead.
The dedicated server appID for SteamCMD is 896660 (the playable game’s appID is 892970 — don’t mix them up). A validate pass on 896660 restores the server binaries without wiping your worlds_local save folder, as long as your save directory is set with -savedir outside the install path or is otherwise preserved by your host.
Where the Files Live
Knowing the exact paths saves a lot of guesswork. Here’s where the relevant folders sit across the common Valheim setups:
| What | Location |
|---|---|
| BepInEx framework | Server/game root, beside valheim_server.exe → BepInEx/ |
| Mod DLLs | BepInEx/plugins/ |
| Mod configs | BepInEx/config/ |
| Worlds (self-host, Windows) | %USERPROFILE%/AppData/LocalLow/IronGate/Valheim/worlds_local/ |
| Worlds (self-host, Linux) | ~/.config/unity3d/IronGate/Valheim/worlds_local/ |
| Worlds (dedicated server) | worlds_local (or worlds) under the dir set by -savedir |
| Admin list | adminlist.txt in the same save directory (one SteamID64 per line) |
On a managed host the BepInEx folder usually sits in the server’s file manager root alongside the executable, and your worlds sit beside the server’s worlds_local save directory. For exact panel paths and our supported mod workflow, our Valheim server documentation walks through the file structure step by step.
Troubleshooting a Broken Modded Server
When a modded server won’t start, won’t accept players, or behaves strangely after an update, work through this in order. The whole point of the disable methods above is that they let you bisect the problem quickly.
Step 1: Confirm it’s a mod problem at all
Rename the BepInEx folder (Method 1) and start the server vanilla. If it works, mods are the cause. If it still fails vanilla, stop chasing mods and look at the world file, the start parameters, RAM/CPU, or networking instead.
Step 2: Check version compatibility after a game patch
The single most common cause of a suddenly-broken modded server is a Valheim update. When the live build moves (the current Early-Access line is the 0.21x family, e.g. 0.217.46), older plugins compiled against a previous version can crash on load. The fix is to update each affected mod to a build that supports the new game version, or roll the server back to the previous game version until the mods catch up. Read the BepInEx console log — it names the plugin that throws on startup.
Step 3: Isolate the offending plugin
If vanilla works but full-modded doesn’t, re-enable plugins in small batches (or remove half, test, then remove half of the remainder) until the bad DLL reveals itself. Move suspects to plugins-disabled/ rather than deleting them, so you can restore the innocent ones.
Step 4: Re-sync clients
If the server starts fine but players are rejected at the connect screen, you almost certainly have a client/server mod mismatch. Make sure everyone is running the exact same set and version of gameplay mods as the server — or, if you disabled a mod on the server, that everyone disabled it client-side too.
Step 5: Rule out resources and networking
Heavy mod packs raise RAM use sharply. Where vanilla is happy at around 2–3 GB, mod-heavy servers (think Valheim Plus or Epic Loot) want 4 GB+, and 10+ players or large modded bases can push past 8 GB. Valheim’s server loop is also largely single-threaded, so a low CPU clock (below roughly 3.0 GHz) causes rubber-banding regardless of mods. If your symptoms are lag and desync rather than crashes, that’s a separate rabbit hole — see our dedicated walkthrough on how to fix lag and desync in a Valheim dedicated server, which covers the hard-coded ~64 KB/s per-client send/receive cap and the Better Networking fix.
Quick Reference: Disable Scenarios
| Goal | Do this | Reversible? |
|---|---|---|
| Turn off ALL mods fast | Rename BepInEx → BepInEx-disabled | Yes — rename back |
| Disable one broken mod | Move that .dll out of BepInEx/plugins/ | Yes — move it back |
| Disable every plugin, keep framework | Empty or rename the plugins folder | Yes |
| Test if mods cause a bug | Rename BepInEx, start vanilla, compare | Yes |
| Full clean vanilla revert | Disable BepInEx + SteamCMD validate on app 896660 | Reinstall mods to undo |
Frequently Asked Questions
How do I disable Valheim BepInEx mods without deleting them?
Rename the BepInEx folder in your server root to something like BepInEx-disabled. The game then launches vanilla because the framework’s launcher can no longer find it, but every file — mods, configs, the framework itself — stays on disk. To re-enable everything, rename the folder back to BepInEx and restart. To disable just one mod without deleting it, move its .dll out of BepInEx/plugins/ into a backup folder you create.
Do I need to remove mods from both the server and the client?
For gameplay mods, yes. BepInEx and matching plugins must be present and version-compatible on both the server and every player’s client, so if you disable a gameplay mod on the server, players should disable it too or they’ll hit connection failures and desync. Client-only cosmetic or UI mods are the exception — those run only on the player’s machine and can be disabled per-client without touching the server. When unsure, treat the mod as needing to match on both sides.
How do I revert my Valheim server back to vanilla?
Back up your world’s .fwl and .db files, disable or delete the BepInEx folder, then run a SteamCMD validate pass on the dedicated server appID 896660 to restore stock files. Note that worlds which relied on content mods may lose those custom items or structures when loaded in vanilla, which is why the backup matters — if a world was heavily mod-dependent, consider starting a fresh vanilla world instead of forcing the modded one to run clean.
My modded Valheim server won’t start after an update — how do I fix it?
Game updates are the top cause. First, rename the BepInEx folder and confirm the server starts vanilla, which proves it’s a mod issue. Then check the BepInEx console log to find the plugin that throws on startup — usually it’s a mod compiled against the old game version that breaks on the new one (the live line is currently the 0.21x family). Update that mod to a compatible build, or remove it via BepInEx/plugins/ until it’s patched. If you can’t wait, roll the server back to the previous game version.
Will disabling BepInEx delete my world or progress?
Disabling BepInEx itself does not touch your world files — your .fwl and .db live in the worlds_local save folder, separate from the BepInEx framework. The risk isn’t the framework; it’s content mods that wrote custom data into your .db. Loading such a world without the mod that created those objects can make them disappear. Always back up both world files before disabling mods, and you’ll never lose real terrain, buildings, or chest contents.
Can I temporarily disable mods just to test something, then turn them back on?
Absolutely — that’s the main reason the folder-rename method is so popular. Rename BepInEx to BepInEx-disabled, start the server to test in vanilla, then rename it back to BepInEx to restore your full mod loadout exactly as it was. Profile switchers like Bepswitch automate this if you toggle often. Nothing is deleted, so it’s the safest way to A/B test whether mods are behind a problem.
Running a Stable Modded (or Vanilla) Valheim Server
Disabling mods is easy once you know the two levers — the BepInEx folder for everything, and BepInEx/plugins/ for individual DLLs — and once you respect the rule that gameplay mods must match on server and client. Keep backups of your .fwl and .db files before any change, restart the server cleanly between edits, and read the BepInEx console log when something breaks; it almost always names the guilty plugin.
If you’re weighing whether to run mods at all, or how much horsepower you need to keep them stable, our breakdown of dedicated versus slot-based Valheim hosting explains why RAM and CPU clock — not player-slot count — decide whether a modded world runs smoothly. And when you’re ready for a true 24/7 box with full file access for BepInEx, fast SSD storage, and high single-core clocks, you can spin up a dedicated Valheim server with us and have complete control over your mods, configs, and worlds from day one.
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.
