How to Install Mods on a 7 Days to Die Server
Some 7 Days to Die mods only need the server, others need every player to install the same files and switch EAC off. Here is how to tell which is which, the folder rules the game enforces, a safe install order and how to keep your save intact.
The quickest way to predict trouble is to look inside the mod folder. If it is only XML config files, the server can usually handle it alone. If it includes assets, prefabs or DLLs, assume clients will need files too until the mod author says otherwise.
XML-only mods can usually keep EAC on. Client-required mods and most DLL changes usually mean EAC off on the server and the same launch mode for every PC player; console crossplay is then off the table.
The game only reads folders directly under Mods/, and each one must contain ModInfo.xml in the right format. One folder too deep, the wrong filename case on Linux, or a duplicate mod name is enough to make a mod vanish.
Adding a mod is usually easier than removing one. Mods that add blocks, items or prefab content can leave a world with missing references after removal, so keep backups and use a new GameName for overhauls or major changes.
First question: server-side only, or does every player need it?
Start here, not with upload instructions. When a player joins a V3 server, the client shows Receiving and loading configs.... That is the moment the server sends its patched XML configs to the client. It does not send assets such as icons, models, sounds, UI atlases, resource bundles or custom prefabs. DLL code sits in the middle: a server-only admin DLL can stay server-side, but code that changes behaviour the client also simulates usually needs both sides on the same version.
| What is inside the mod folder | Who installs it | EAC position | Why this happens |
|---|---|---|---|
Config XML only, plus localisation or XUi XML | Server only | Can usually stay on | The server sends its patched configs to every player on join, so nothing needs installing on their side. |
Icons, textures, sounds, models, meshes, UI atlases, Resources bundles | Server and every PC player, same version | Usually off | Assets are never pushed from the server. Clients need matching local files on disk and in memory, or validation fails. |
| Prefabs or POIs | Server and every PC player, exactly as instructed by the pack | Usually off | World assets are not sent to clients. These changes also carry save-world risk because the world may reference content that is no longer there later. |
.dll files | Depends on what the DLL changes | Often off | Server-only command or admin code can stay on the server. Behaviour the client must understand needs code on both sides, and most DLL mods do not sit well with EAC. |
| Overhaul or total conversion | Everyone, same version | Off | Overhauls combine XML, assets and often code. They usually need more RAM, a clean test pass, and usually a new world. |
If a mod is only XML, the practical upside is simple: less client support, EAC can usually stay on, and the change is easy to roll back. The trade-off is that XML-only mods cannot add custom art or custom models. You know this class of mod is working when the server log shows it loaded and the changed value appears in game even though players installed nothing locally.
| Mod contains | Server | Players need it | EAC can stay on |
|---|---|---|---|
| Config XML only | Yes | No | Yes |
| Icons, textures, sounds, models | Yes | Yes | No |
| Prefabs and POIs | Yes | Yes | No |
| Server-only DLL (admin commands) | Yes | No | Partly |
| DLL that changes gameplay | Yes | Yes | No |
| Overhaul | Yes | Yes | No |
A small XML-only modlet is just a ModInfo.xml plus a Config folder. Its Config/items.xml changes one value with an XPath patch. In this example the item name and stack size are placeholders:
<configs> <set xpath="/items/item[@name='exampleAmmo']/property[@name='Stacknumber']/@value">500</set> </configs>
EAC, launch mode and who can join
V3 defaults to EAC on. For XML-only server-side modlets, that is usually fine because clients are not changing local game files; they are only receiving server configs. As soon as a mod requires altered client assets, a client DLL, or a full overhaul install, plan around EAC being off unless the mod author explicitly says otherwise.
<property name="EACEnabled" value="false" />
Why that matters: EAC checks the client launch mode against the server setting. If the server has EAC off, players must launch without EAC. If the server has EAC on, players must launch with EAC. When they press Play in Steam, the game offers both launch options, so tell your group which one to pick. A mismatch stops joins before you get to any real mod diagnosis, so this is one of the first things to confirm after a game update or reinstall. If the join failures stop as soon as both sides use the same EAC state, you have found the problem.
There is a second trap here. Some mods use a SkipWithAntiCheat flag in ModInfo.xml. When EAC is on, the game skips that mod. That can make a server look healthy while the mod simply is not active. If a mod “loads” in your file manager but has no effect with EAC on, check the mod’s instructions and test again with the expected EAC setting.
For console players, treat any modded server as PC-only. Crossplay needs EAC on, sanctions on, and no more than the allowed slot limit, but host documentation also states that PS5 and Xbox players cannot join a server running mods. So the admin choice is straightforward: if you want console access, stay unmodded; if you want mods, support PC clients only.
Folder rules the loader actually enforces
The loader is fussier than many mod pages suggest. A mod is not “some files in a zip”; it is a folder directly inside Mods/ that contains ModInfo.xml. The server only reads the folders directly under Mods. If you leave the archive’s extra wrapper folder in place, the loader never reaches the real mod.
Correct and wrong folder trees
Correct: ModInfo.xml sits one level under Mods.
Mods/
MyServer_BiggerAmmoStacks/
ModInfo.xml
Config/
items.xml Wrong: the archive’s own wrapper folder adds an extra level.
Mods/
MyServer_BiggerAmmoStacks/
MyServer_BiggerAmmoStacks/
ModInfo.xml
Config/
items.xml The wrong tree above triggers the exact log line Folder X does not contain a ModInfo.xml, ignoring. That happens because the loader scans only the first level under Mods/. Fixing the extraction point costs nothing but a restart, and you know it helped when the ignore line disappears and the mod starts logging as loaded.
Use the V2 ModInfo format
Old A19 and A20 style wrappers are refused in V3. The current format puts fields directly under <xml>. On Linux servers, the filename case matters too: it must be exactly ModInfo.xml, not a lower-case variant.
<xml> <Name value="MyServer_BiggerAmmoStacks" /> <DisplayName value="My Server Bigger Ammo Stacks" /> <Version value="1.0.0" /> <Description value="Example XML-only server modlet" /> <Author value="ExampleAuthor" /> <Website value="" /> </xml>
The loader also expects a clean mod name. Name can use letters, digits, _ and - only, and DisplayName must not be empty. If two mods share the same Name, the second one is ignored. The most common version of that is a second copy of Harmony next to the game’s own 0_TFP_Harmony. Leave any TFP_ and 0_TFP_ folders alone; they ship with the game for a reason.
Remember there are two Mods folders
The game reads the user data Mods folder first, then the Mods folder in the game or server install directory. On self-hosted systems that means an old copy can survive in the user data path even after you “updated” the install folder version. That is a classic cause of duplicate names, stale files and confusion when a change seems to ignore your upload.
- Windows user data:
%APPDATA%\7DaysToDie\Mods - Linux user data:
~/.local/share/7DaysToDie/Mods - macOS user data:
~/Library/Application Support/7DaysToDie/Mods - Install location:
Mods/under the server or game install
Log lines worth searching for
Use the latest server log or output_log. Lines with ERR or EXC usually name the mod that caused the problem.
Loaded Mod: MyServer_BiggerAmmoStacks Folder X does not contain a ModInfo.xml, ignoring ModInfo.xml in legacy format. V2 required to load mod Mod with same name (X) already loaded, ignoring XML patch for "items.xml" from mod "Name" did not apply Patch type (name) unknown
A safe install order that protects the save
Install order is mostly about avoiding half-fixes and making the log tell a clear story. The server reads serverconfig.xml and the mod list at startup, so live edits are the wrong habit here.
- Back up the world and your active config. If a mod later proves wrong for V3, rollback is much faster than repairing a damaged save. This matters most for block, item and prefab mods because worlds and inventories can keep references to content that no longer exists.
- Check the mod is built for your exact game build. Client and server must run the same build, and big updates break mod targets. V3.0 renamed files and folders that many older mods patch, so a “loaded” V2-era mod can still do nothing.
- Stop the server fully. Adding, removing or updating mods while it is running is unreliable because the mod loader has already built its view of the world for this session. Stopping also avoids partial file writes while you upload or extract.
- Upload to
Mods/and create that folder if it does not exist. Use FTP, SFTP or your panel’s file manager. The goal is not just “files present”; it is the exact loader-friendly layout. - Extract archives so
ModInfo.xmlsits directly inMods/ModName/. This is the step that prevents the one-folder-too-deep problem. It costs a minute of file checking and saves a lot of blind restarts. - Start the server only after all parts of the mod are in place. Dependencies, XML patches and DLLs are resolved at startup. Starting with half a package produces misleading errors that disappear only after a clean restart.
- Check the log before you announce anything to players. Look for
Loaded Mod:, then scan forERR,EXCand patch failures. Loaded means the folder passed the loader; it does not guarantee the mod’s changes applied. - Join and test with one mod at a time, or a small batch. This costs extra restarts, but it cuts the search area when something breaks. For server-only XML mods, the proof is simple: players join without installing files and still get the changed configs.
Do not edit the shipped serverconfig.xml directly, because updates can overwrite it. Keep a copied config and launch with -configfile=yourconfig.xml. If you want the file locations and startup-only settings laid out cleanly, the 7 Days to Die server settings guide for V3 covers the config copy, GameName and the settings that only take effect after a restart.
Dependencies, Harmony and silent overrides
Some problems are not bad installs at all; they are missing dependencies or two good mods changing the same thing. C# mods often depend on Harmony. V3 already ships the game’s own 0_TFP_Harmony, so leave it alone. If you upload a second Harmony copy with the same mod Name, the second one is ignored and the log tells you so with Mod with same name (X) already loaded, ignoring.
Other mods require a separate framework or another content pack. Read the mod page closely before you upload anything. If a dependency is missing, the server will often still start, but you will usually see ERR or EXC lines naming the dependent mod. That is cheaper to diagnose at startup than after players have joined and reported random symptoms.
When two modlets patch the same XML value, the one loaded later wins silently. This is about patch order, not hardware. The server applies patches to the same XML tree in sequence, and the last matching change sticks. The player-facing trade-off is inconsistency: one mod appears “broken” even though it loaded correctly. You know this is the issue when both mods load cleanly, there are no patch errors, but only one expected value appears in game. Move a suspect folder out to a ModsDisabled folder, restart, and test again.
Version conflicts: why “Loaded Mod” is not enough
V3.0 renamed files and folders that older mods target. That means a mod can pass the folder checks, show as loaded, and still fail to change anything because its xpath no longer matches the live XML structure. The exact clue is XML patch for "items.xml" from mod "Name" did not apply. The server read the mod, but the target node was not where the mod expected it to be.
The fix is either a V3-compatible mod update or pinning the game version until the mod catches up. Pinning is practical for private groups, but the trade-off is that you hold back official updates as well, and players must select the same version on their side, under the game’s Properties > Betas in Steam.
If you see Patch type (name) unknown, the mod is using an unsupported or wrong patch verb. The supported verbs are set, setattribute, removeattribute, append, prepend, insertBefore, insertAfter, remove, csv, conditional and include. In both cases, updating the mod is the real fix; a restart alone will not solve it.
Protecting worlds: adding is easy, removing is risky
Adding a small XML balance mod to an existing world is usually low risk. Removing content mods is the dangerous part. If a mod added blocks, items or world content and the save has already used them, the world can end up with missing references in chunks, containers, crafting queues or player inventories after removal. That is why the first backup matters more than the first upload.
For diagnosis, do not delete a mod folder straight away. Move it out of Mods into something like ModsDisabled next to it, then restart. That gives you a clean off switch without losing the exact files you were testing. The trade-off is that the world still loses access to whatever that mod provided, so this is a good test method but not a safe permanent removal plan for block and item mods.
Use a new world for overhauls, and usually after removing a mod the world depends on. The clean way to do that is to change GameName so the server starts a fresh save while keeping the old world intact. This matters even more for prefab and POI packs, which may also require files in Data/Prefabs or a specific mod folder layout; follow the pack’s own instructions rather than assuming every prefab pack installs like a standard modlet.
Updating mods and deciding if the server needs more headroom
When a mod author releases an update, delete the old folder and install the new one instead of copying over the top. That prevents removed files from the old version lingering on disk and still loading. If the mod has client-side parts, every player must update to the same version as well. After any game update or reinstall, re-check EACEnabled because configs can reset to defaults and switch EAC back on.
Hardware pressure is not the same for every mod type. XML-only modlets are usually light; the loader cost is mostly startup CPU and disk reads. DLL-heavy sets and overhauls can add main-thread CPU work and increase heap and RAM use, while prefab-heavy changes affect disk and memory during world load and generation. V3 starts at 8 GB RAM minimum, with 16 GB recommended, so large mod lists and overhauls push you closer to the higher end rather than the lower one.
| Change you are planning | Resource hit first | What to do before upgrading | How to tell it helped |
|---|---|---|---|
| A few XML-only modlets | Startup CPU and a little join-time bandwidth | Add them gradually, watch the log, and check the changed configs in game | The server starts cleanly, players join with no client installs, and the values actually changed |
| A large stack of XML modlets touching the same files | Admin time more than hardware | Prune overlaps, check for patch failures, and disable likely conflicts one at a time | The final values stop changing unexpectedly and “did not apply” lines disappear |
| DLL mods or an overhaul | Main-thread CPU and RAM | Plan for EAC off, keep clients version-matched, and watch memory use after startup and after players join | The server stays stable after a restart cycle and players stop hitting validation or data errors |
| Prefab or POI packs | Disk activity and RAM during world load or generation | Follow the pack’s install path exactly and use a new world where required | The world starts cleanly and clients do not report missing or broken locations |
If you are moving beyond simple XML tweaks and want a clearer view of panel features, update handling and plan headroom, our 7 Days to Die server hosting comparison shows which hosts give you full file access, version pinning and enough memory for a larger overhaul.
If your group is moving from a handful of server-side modlets to a full overhaul, compare the available server options first so you are not rebuilding everything again after the first update cycle.
Compare the best 7 Days to Die server hostsTroubleshooting: symptom, likely cause, first fix
Use the server log as the final authority. The pattern below covers the failures that waste the most time because the server can still appear online while the mod is not actually doing what you expect.
| Symptom | Likely cause | First fix |
|---|---|---|
| Mod is not listed as loaded | Folder is one level too deep, ModInfo.xml is missing, or the filename case is wrong on Linux | Fix the folder tree so Mods/ModName/ModInfo.xml is direct, then restart and recheck the log |
ModInfo.xml in legacy format. V2 required to load mod | Old A19 or A20 style metadata | Replace the mod with a V3-compatible version using the V2 format |
Mod with same name (X) already loaded, ignoring | Duplicate mod folder, often a second Harmony copy or an old copy in the user data Mods folder | Search both Mods locations, remove the duplicate, and leave the game’s own 0_TFP_Harmony alone |
| Mod loads but nothing changes | The XML patch target moved in V3, or another mod loaded later overwrote the same value | Check for did not apply lines first, then disable likely conflicting mods and retest |
Remote data validation failed. Modified files detected. | Players are missing a required client mod, using the wrong client version, or joining with the wrong EAC mode | Confirm the mod really is client-required, then match client files, game build and EAC state to the server |
| Unexpected data received errors on join | Wrong or absent overhaul files on the client | Make sure every player has the exact overhaul version and launches with the same EAC mode as the server expects |
| Server worked before a game update and now patches fail | The game build changed, but the mod still targets older file names or xpaths | Update the mod, or pin the server and players to the previous game version until the mod is updated |
| World has missing items, broken blocks or odd chunk issues after mod removal | The save depended on content added by the removed mod | Restore the backup or start a new world with a new GameName |
| Clients can only join when they disable EAC, or only when they enable it | Server and client EAC settings do not match | Set the server’s EACEnabled value correctly, restart, and have every player launch the same way |
7 Days to Die server FAQ
Do players need to install mods to join a modded 7 Days to Die server?
Only if the mod contains files the server cannot send. XML-only config modlets are usually server-side because the server sends patched configs during Receiving and loading configs.... Assets, prefabs, most DLL changes and overhauls need matching client installs on every PC.
Do I need to turn off EAC for mods?
Not for plain XML-only server-side mods in most cases. You usually need EAC off when players must alter local files, install client DLLs or run an overhaul, and both server and clients must use the same EAC mode. If a mod uses SkipWithAntiCheat, it may simply be skipped while EAC is on.
Can PS5 and Xbox players join a modded server?
No; treat a modded server as PC-only. Crossplay conditions matter for unmodded servers, but host documentation states that console players cannot join a server running mods. If console access matters, keep the server unmodded and EAC-enabled.
Can I add mods to an existing world?
Usually yes for small XML balance changes, especially ones that do not add new content. The bigger risk is removal later, particularly for mods that add blocks, items or prefab content the save has already used. Overhauls are best started on a new world by changing GameName.
Why is my mod not loading on the server?
The usual causes are a bad folder tree, a legacy ModInfo.xml, wrong filename case on Linux, a duplicate Name, missing dependencies or a V3-incompatible xpath. Start with the log: check for Loaded Mod, then search for ERR, EXC, did not apply and duplicate-name messages. The log almost always names the rule that was broken.
More 7 Days to Die server guides
Our other 7 Days to Die server guides, plus the host comparison.
Written for 7 Days to Die V3. Mod names, item names and values in the examples are placeholders. If your host’s panel labels differ, the folder rules and log lines stay the same.
