← Blog

Configurer un serveur 7 Days to Die pour jouer en équipe

Par Benjamin Dayan · PDG

· Mis à jour le October 31, 2026 · Lecture 6 min

Contents

The 7 Days to Die serverconfig.xml file is the control center for turning a brutal survival ruleset into a relaxed, build-oriented experience your friends will actually want to log into every week. Inside this one file you decide the day/night cycle, loot abundance, zombie block damage, player killing rules, land claim size and EAC settings — the six levers that define whether a session feels like a punishing grind or a cooperative sandbox.



Locating and Editing the 7 Days to Die serverconfig.xml File

On a standard installation, serverconfig.xml sits in the root folder of your game files, next to the executable. If you manage your environment through a Pterodactyl panel, you'll find it in the file manager without needing console or SFTP access — just open the file, edit the attribute values, save, and restart the instance for the changes to apply.

Every parameter in the file follows the same structure:

<property name="DayNightLength" value="60"/>

Only the value attribute needs to change. Never remove a line or rename a property — the parser is strict, and a missing closing quote or a stray character will stop the save from loading entirely. Always keep a backup copy of the file before a batch of edits, and test changes on a restart rather than a live session with players connected.

Before touching any parameter, make sure you're working from a recent save backup; small typos in XML attributes can prevent the world from loading. If you're starting a fresh environment for your group, our 7 Days to Die server hosting ships with serverconfig.xml already generated and reachable straight from the panel, so you can jump directly into the cooperative tuning covered below without touching a terminal.



Tuning the Day/Night Cycle for Cooperative Play

The day/night cycle drives the pace of every cooperative run. A short day leaves little time to loot, build and craft before the horde night rolls around, while a long day gives your group breathing room to explore and fortify a base together.

Key properties

  • DayNightLength – total duration of a full in-game day, expressed in real-world minutes.
  • DayLightLength – how many of those in-game hours are daylight versus night.
<property name="DayNightLength" value="90"/>
<property name="DayLightLength" value="18"/>

For a cooperative group that wants time to build, trade and loot without rushing, a DayNightLength around 90–120 minutes with an 18-hour DayLightLength keeps the night window short and manageable while leaving a comfortable amount of daytime for scavenging and construction.

Horde frequency

Pair the day length with BloodMoonFrequency to decide how often the group faces a coordinated horde night. A value of 7 keeps the classic weekly rhythm; raising it to 10 or 14 gives a more relaxed cooperative pace for groups focused on building rather than combat.



Loot Abundance, Zombie Block Damage and Land Claim Size

These three settings shape how generous and how destructible the world feels, which matters a lot once several players start sharing resources and bases on the same map.

Loot abundance

<property name="LootAbundance" value="150"/>
<property name="LootRespawnDays" value="5"/>

LootAbundance is a percentage multiplier applied to everything found in containers. Default is 100; pushing it to 150–200 reduces competition between players for resources and speeds up early progression, which tends to work well on cooperative setups where the focus is on building rather than scarcity. LootRespawnDays controls how quickly already-looted containers refill — lower it if your group plays in short, frequent sessions.

Zombie block damage

<property name="BlockDamageAI" value="60"/>
<property name="BlockDamageAIBM" value="100"/>
<property name="XPMultiplier" value="100"/>

BlockDamageAI sets how much damage regular zombies deal to structures outside of horde nights, while BlockDamageAIBM applies specifically during blood moon events. Lowering BlockDamageAI to 40–60% protects a shared cooperative base from being chewed through by stray zombies during the day, while keeping BlockDamageAIBM closer to 100% preserves the tension of the horde night itself.

Land claim size

<property name="LandClaimSize" value="41"/>
<property name="LandClaimDecayMode" value="1"/>
<property name="LandClaimOnlineDurationMode" value="1"/>

LandClaimSize defines the radius, in blocks, protected by a claim block. The default of 41 is often tight for a cooperative group sharing one base — many communities raise it to 48 or 55 so overlapping claims from multiple players cover the whole build without constant block-placement conflicts. LandClaimDecayMode and LandClaimOnlineDurationMode control how quickly protection decays when a player is offline; set them generously if your group doesn't play every day.



Player Killing Rules and EAC Settings

The last two parameters decide whether the world stays strictly cooperative or allows friendly fire, and whether Easy Anti-Cheat intervenes in how the game loads.

Player killing mode

<property name="PlayerKillingMode" value="0"/>

PlayerKillingMode accepts four values:

ValueBehavior
0No player killing allowed
1Kill allies only
2Kill strangers only
3Kill everyone

For a purely cooperative group, 0 removes any risk of accidental or griefing kills. If your community mixes trusted players with occasional strangers, value 2 keeps the core group safe from each other while still allowing PvP against outsiders joining the world.

EAC settings

<property name="EACEnabled" value="true"/>

EACEnabled toggles Easy Anti-Cheat validation when clients connect. Keep it set to true for a public or semi-public cooperative group to block modified clients and common cheats. Set it to false only if your group relies on client-side mods that EAC flags as unauthorized modifications — in that case, compensate with a private whitelist and a vetted player list rather than leaving the world open.

Whitelist and access control

<property name="EnemySpawnMode" value="true"/>
<property name="EnemyDifficulty" value="0"/>

Combine PlayerKillingMode and EACEnabled with a strict whitelist entered through the panel's admin tools, and rotate the server password periodically if the connection details have circulated beyond your immediate group. These basic access practices matter as much as the XML tuning itself once the world has valuable, shared bases on it.

For broader context on managing other titles alongside your 7 Days to Die world, check All our game servers or browse configuration guides on the Fly-Serv blog. Admins running their own infrastructure can also manage multiple instances from a Pterodactyl VPS environment.



Conclusion

Adjusting day/night length, loot abundance, zombie block damage, land claim size, player killing mode and EAC settings in a few focused edits reshapes the experience for a cooperative group without touching a single mod. Save a backup, change one parameter at a time, and restart to confirm the world behaves as expected before inviting the whole team back in.



FAQ

Why does my world fail to load after editing serverconfig.xml?

This usually comes from a broken XML structure, such as a missing quote or an extra character inside a property line. Restore your backup copy, re-apply the change one line at a time, and validate the file structure before restarting.

Can I change LandClaimSize on an existing world without resetting it?

Yes, LandClaimSize applies immediately on restart and affects claim blocks placed afterward. Existing claims keep their original radius until the claim block is picked up and replaced, so warn your group before changing this value mid-session.

Should I disable EACEnabled to use client-side mods?

Only disable it if the mods you use are flagged by Easy Anti-Cheat and you trust everyone connecting. Pair a disabled EAC with a strict whitelist rather than leaving the world openly joinable, since it removes a layer of cheat protection.

Read next