7 Days to Die Server Settings for V3: serverconfig.xml, SandboxCode and Performance
Since V3.0, a 7 Days to Die dedicated server is configured in two places. serverconfig.xml still controls how the server runs, but difficulty, blood moons, loot and most gameplay rules now sit in a single SandboxCode line, and old V2 lines are silently ignored. This guide shows what lives where, how to set a code safely, and which settings actually change RAM, CPU, disk and bandwidth use.
serverconfig.xml now handles identity, ports, slots, crossplay, world choice, land claims and performance caps. Blood moons, loot, difficulty and similar gameplay rules moved into SandboxCode.
Old V2-style properties can still sit in the file, but V3.x simply ignores the removed ones. The server still boots, which makes the problem easy to miss.
The biggest levers are MaxSpawnedZombies, ServerMaxAllowedViewDistance, world size, animal cap, mesh queue, dynamic mesh, map rendering and transfer speed. Each trades smoothness against world density, join time or convenience.
Crossplay servers must keep sanctions enabled and stay at the default or fewer player slots. Push ServerMaxPlayerCount above 8 and console players will not see the server.
The V3 split: which 7 Days to Die server settings still live in serverconfig.xml?
V3.0 added over 150 Sandbox Options, and that changed how dedicated servers are configured. The important split is simple: serverconfig.xml now describes how the server runs, while SandboxCode describes how the game plays. If you still edit old lines such as difficulty, blood moon frequency or loot abundance in serverconfig.xml, V3.x will ignore those lines and keep running.
Use serverconfig.xml for things like server name and visibility, ports, maximum player slots, crossplay and EAC, world choice and size, land claims, chunk reset limits, map rendering, transfer speed and performance caps such as zombie and animal limits. Use SandboxCode for gameplay rules such as Blood Moon Frequency, Blood Moon Range, Blood Moon Count, Blood Moon Warning, Air Drops, Storm Frequency, Daylight Length, Biome Progression, Global Game Stage, Biome Game Stage, difficulty and loot settings.
That is why old V2 properties appear to “do nothing”. Officially removed or converted legacy properties include GameDifficulty, BlockDamagePlayer, BlockDamageAI, XPMultiplier, DayNightLength, DayLightLength, StormFreq, DeathPenalty, EnemyDifficulty, BloodMoonFrequency, BloodMoonRange, BloodMoonWarning, BloodMoonEnemyCount, LootAbundance, LootRespawnDays, AirDropFrequency, AirDropMarker and QuestProgressionDailyLimit. Leftover lines do not block startup, so the server looks healthy while your edits are being skipped.
Lives in serverconfig.xml (how the server runs) | Lives in SandboxCode (how the game plays) |
|---|---|
| Name, password, visibility | Difficulty presets (was GameDifficulty) |
| Ports (26900 by default) | Blood moon frequency, range, count and warning |
| Player slots, crossplay, sanctions | Loot abundance and respawn |
| World: Navezgane, RWG or pregen, and size | Air drops and markers |
| Land claims, bedroll zone | Day length and daylight |
| Zombie and animal caps | Storms, biome progression |
| View distance cap, mesh options | Zombie speeds and feral sense |
| Chunk age, save size limit | Death and drop-on-death penalties |
| Telnet, web dashboard, map rendering | XP and block damage multipliers |
The shipped default Sandbox code is below. It equals the legacy default GameDifficulty of Adventurer (1). The same excerpt also shows the performance-related properties at their defaults, which is useful as a clean baseline when you need to undo a bad round of tuning.
<property name="SandboxCode" value="AAAJABJACJADJARFBNC"/> <property name="GameWorld" value="Navezgane"/> <property name="WorldGenSeed" value="MyGame"/> <property name="WorldGenSize" value="6144"/> <property name="MaxSpawnedZombies" value="64"/> <property name="MaxSpawnedAnimals" value="50"/> <property name="ServerMaxAllowedViewDistance" value="12"/> <property name="MaxQueuedMeshLayers" value="1000"/> <property name="DynamicMeshEnabled" value="true"/> <property name="DynamicMeshLandClaimOnly" value="true"/> <property name="DynamicMeshLandClaimBuffer" value="3"/> <property name="DynamicMeshMaxItemCache" value="3"/> <property name="ServerMaxWorldTransferSpeedKiBs" value="512"/> <property name="MaxChunkAge" value="-1"/> <property name="SaveDataLimit" value="-1"/> <property name="EnableMapRendering" value="false"/> <property name="TwitchBloodMoonAllowed" value="false"/>
A safe SandboxCode workflow for rented servers
The reliable way to manage V3.x gameplay settings is to treat the code as an export, not as something you guess by hand. Generate it from the same game version as the server, keep a copy outside the host panel, and paste only the final code back into serverconfig.xml. That avoids two common problems: using a code generated by the wrong version, and losing your settings when a panel rewrites the file.
- If you are keeping a V2.6 save, first mirror the old gameplay rules in V3 Sandbox Options. The official guidance is to recreate the legacy settings in the in-game Sandbox Options menu, then copy the resulting code. That is the cleanest way to preserve how the world played before the upgrade.
- Generate the code from New Game > Sandbox Options. Copy the code only after you have set blood moon behaviour, loot, difficulty, day length and similar gameplay rules.
- Keep the code in a plain text note. If you later change hosts, switch panels or roll back a file, you can restore the exact rules quickly.
- Paste that code into the single
SandboxCodeproperty inserverconfig.xml. Do not leave yourself relying on old legacy properties further down the file. - Restart the server.
serverconfig.xmlis read at server start, so live edits do nothing until the next restart. - As a precaution, regenerate the code from the same V3.x build as the server after major updates. The point is not that every update breaks old codes; it is that version-matched exports are the least ambiguous state to keep.
If the real goal is to refresh a worn-out map, do not confuse that with Sandbox settings. V3.0 also added a Continue Game option to opt into a full reset of all unprotected chunks, plus a server command to trigger the same reset. That is a world-maintenance choice, not a loot or difficulty setting.
A sensible starting serverconfig.xml for a small UK group
For a private or friends-only group, the best starting point is usually close to the shipped defaults. That gives you a known baseline, keeps troubleshooting simple and avoids stacking several variables at once. Change visibility first, then add a Sandbox code for your preferred rules, then tune performance only if the server actually needs it.
<property name="ServerPort" value="26900"/> <property name="ServerVisibility" value="1"/> <property name="ServerMaxPlayerCount" value="8"/> <property name="ServerAllowCrossplay" value="false"/> <property name="EACEnabled" value="true"/> <property name="IgnoreEOSSanctions" value="false"/> <property name="GameWorld" value="Navezgane"/> <property name="GameName" value="MyGame"/> <property name="SandboxCode" value="AAAJABJACJADJARFBNC"/>
ServerVisibility 1keeps the server on friends visibility instead of fully public. That reduces random joins without affecting game performance.ServerMaxPlayerCount 8matches the default and keeps the option open for crossplay later, because console visibility depends on staying at the default or fewer slots.EACEnabled trueandIgnoreEOSSanctions falseare the shipped defaults. Leaving sanctions in place matters for crossplay, because a server that ignores them is not listed for console players, and keeping anti-cheat on is the safe baseline for any public-facing server. This avoids one of the easiest reasons a server disappears for console users.GameWorld Navezganeis the simplest baseline. If you move toRWGor a pregen world later, change one thing at a time so you can tell what affected stability, save size and join time.
If you do want crossplay, change ServerAllowCrossplay to true, keep sanctions enabled (IgnoreEOSSanctions stays false), and do not raise the slot count above 8.
Blood moons, loot and difficulty now live in SandboxCode
On V3.x, set blood moon timing, loot, air drops and difficulty in Sandbox Options, copy the code, and paste that code into SandboxCode. That is the only dependable route for settings such as Blood Moon Frequency, Blood Moon Range, Blood Moon Count, Blood Moon Warning, Loot, Daylight Length and related gameplay rules.
The blood moon setting people trip over most is the relationship between Blood Moon Count and MaxSpawnedZombies. Blood Moon Count is a gameplay rule in the sandbox (the legacy BloodMoonEnemyCount it replaced was a per-player figure). MaxSpawnedZombies is a world-wide server cap in serverconfig.xml. The two are not the same number: the sandbox says how big the horde should be, while the server cap limits how many zombies can be alive across the whole world at once. In plain terms: raising Blood Moon Count can appear to do nothing if the server is already full up on allowed zombies.
That matters for performance because zombie AI is one of the heaviest consistent server costs. More active zombies mean more pathing, more target checks, more hit processing and more state to keep current. The trade-off is obvious for players: thicker hordes feel better until the main server thread runs short of time. If blood moons feel thin, check the global cap before blaming the Sandbox code. If the server stalls on horde night, lowering Blood Moon Count alone may not be enough if the world-wide cap is still very high.
The server settings that actually change load
Not every option is worth touching. The settings below are the ones that genuinely move resource use on a V3.x dedicated server. The key is to know which resource each one pressures: main-thread CPU, RAM, disk activity or network bandwidth. Change one lever at a time, then watch for a specific symptom to improve rather than doing broad “optimisation” passes that hide the real cause.
| Setting | RAM | CPU / server load | Disk | Network |
|---|---|---|---|---|
MaxSpawnedZombies | Likely | Named | – | – |
ServerMaxAllowedViewDistance | Named | Named | – | Likely |
WorldGenSize / GameWorld | Likely | – | Named | Likely |
MaxSpawnedAnimals | – | Named | – | – |
MaxQueuedMeshLayers | Named | – | – | – |
DynamicMeshMaxItemCache | Named | – | – | – |
ServerMaxWorldTransferSpeedKiBs | – | – | – | Named |
MaxChunkAge / SaveDataLimit | – | – | Named | – |
EnableMapRendering | – | Likely | Likely | – |
TwitchBloodMoonAllowed | – | Named | – | – |
| Setting | Main cost | Why it works | Player trade-off | How to tell it helped |
|---|---|---|---|---|
MaxSpawnedZombies | CPU, then RAM | This is a world-wide cap. More active zombies means more server-side AI, pathing and combat checks. The shipped file warns that changing it can have a huge impact on performance. | Lower caps can make hordes and busy areas feel less dense once the cap is reached. | Blood moons and town fights stop hitching as hard, especially when several players are active in different places. |
ServerMaxAllowedViewDistance | RAM, CPU, bandwidth | Higher view distance means more distant chunks and entities must be tracked and sent. The file description calls it high impact on memory usage and performance. | Players cannot request as much distant world detail. Fresh terrain may pop in nearer. | Movement and combat feel steadier in built-up areas, with fewer memory-related spikes. |
GameWorld / WorldGenSize | Disk, RAM, bandwidth | Bigger worlds mean more chunks can be explored and saved, more drive space for the world and player data, and more world data to send to players on their first join. | Less map area for exploration if you choose smaller sizes or a pregen instead of a large RWG. | First joins shorten, save growth slows and long-running worlds stay easier to manage. |
MaxSpawnedAnimals | CPU | Animals use less CPU than zombies, but they still consume AI time. The cap matters most when players spread out enough to hit it. | Fewer wildlife encounters across widely separated players. | Less extra load when the group fans out across the map. |
MaxQueuedMeshLayers | RAM | Lowering the queue reduces how much mesh work is held in memory at once. | Chunk generation can take longer, so new areas may appear less promptly. | Memory pressure drops, but only keep the change if chunk generation does not become annoying. |
DynamicMeshEnabled, DynamicMeshLandClaimOnly, DynamicMeshLandClaimBuffer, DynamicMeshMaxItemCache | RAM and CPU near changed areas | Dynamic mesh builds simplified distant versions of areas players have changed, such as bases, so they look right from far away. Restricting it to land-claim areas and keeping the buffer and item cache modest limits how much changed-world data must stay ready. | Less generous dynamic coverage outside claims, or less caching around large build areas. | Base-heavy servers see fewer local hitches and lower memory use. |
ServerMaxWorldTransferSpeedKiBs | Bandwidth | This caps first-connect world transfer speed. Higher values can reduce first-join waits, but the official ceiling is only about 1300 KiB/s even if you set more. | Higher transfer rates can compete with live traffic on limited upload. | New joins complete faster without causing rubber-banding for players already online. |
MaxChunkAge / SaveDataLimit | Disk | These control save growth by resetting old or over-budget chunks. They do not make live simulation cheaper; they manage world persistence and storage. | Unprotected world changes can be lost when chunks reset. | Save size stops expanding as quickly, or remains within a planned disk budget. |
EnableMapRendering | CPU and disk | It renders map tiles while exploring for dashboard use, which adds background work and file output. | No live rendered map tiles if you leave it off. | Less background write activity and less extra rendering work while players explore. |
TwitchBloodMoonAllowed | CPU | The file warns it could cause server lag because of extra zombies spawned during blood moon. | That integration feature stays unavailable. | Horde night has one less source of sudden spawn pressure. |
World size: pick the smallest map that suits the group
World size is one of the easiest settings to underestimate because the cost arrives slowly. A bigger map gives more exploration room, but it also creates more possible chunk data, more saved terrain changes, more first-join world transfer and more memory pressure as the world matures. In other words, larger maps do not only affect generation day; they keep charging disk, bandwidth and housekeeping costs over time.
6144is about37.7km2.8192is about67.1km2.10240is about104.9km2, which is about2.8xthe area of6144.
Supported WorldGenSize values are 6144 to 10240 in multiples of 2048. For a small group, the practical admin question is not “what is the largest map available?” but “how much unexplored space will this group realistically use before the save becomes cumbersome?” A smaller map keeps people closer together, reduces how many far-apart chunk regions are kept active, and cuts the amount of world data new joiners must download under the transfer cap.
GameWorld can be Navezgane, RWG or a pregen such as Pregen06k01 or Pregen08k01. For administration, pregen and Navezgane are simpler to reason about. RWG adds seed and size choices, which is useful, but it also means one more place to create a problem when you are already chasing lag or long join times.
Crossplay, slots and the setting that hides your server from console players
Crossplay on V3.x is governed by a small set of hard rules. ServerAllowCrossplay must be enabled, sanctions must not be ignored, and the server has to stay at the default or fewer player slots. In practice that means a crossplay server is only found and joinable if IgnoreEOSSanctions is false and ServerMaxPlayerCount is 8 or fewer.
The slot rule is the easy one to miss. Admins often raise player count first, then wonder why console players cannot see the server. Nothing is “wrong” with the box; the listing rules simply exclude it. So if your server is meant for mixed platforms, keep the slot count conservative from the start instead of building a setup that you later have to undo.
ServerVisibility only affects listing privacy, not performance. ServerDisabledNetworkProtocols defaults to SteamNetworking, and for most rented servers that is best left alone unless you have a very specific reason to change network protocol handling.
My setting did nothing: quick troubleshooting table
Most V3 configuration problems are not mysterious. They come from editing the wrong place, not restarting, or expecting a performance setting to behave like a gameplay setting. Start with the table below before you assume the host is at fault.
| Symptom | Likely cause | First fix |
|---|---|---|
Changing difficulty, blood moon frequency or loot lines in serverconfig.xml changes nothing | Those legacy properties moved into SandboxCode in V3.x and old lines are ignored | Set the rule in Sandbox Options, copy the code, paste it into SandboxCode, then restart |
You pasted a new SandboxCode but the server still behaves the same | The server was not restarted, or you edited a copy of the file your host is not loading | Confirm the live file, save it, then restart because serverconfig.xml is only read at server start |
| Blood moons still feel capped after raising Blood Moon Count | MaxSpawnedZombies is acting as the world-wide ceiling | Review the global zombie cap in serverconfig.xml before changing sandbox values again |
| Console players cannot find the server | Crossplay is off, sanctions are ignored, or slots are above 8 | Set ServerAllowCrossplay to true, keep IgnoreEOSSanctions false, and keep ServerMaxPlayerCount at 8 or fewer |
| First joins take a long time but gameplay is fine afterwards | The world is large, and first-join transfer speed is capped by ServerMaxWorldTransferSpeedKiBs | Review map size, age of the save and the transfer cap; raise the cap only if your upload has room for it |
| Areas of the world seem to reset unexpectedly | MaxChunkAge or SaveDataLimit is forcing resets, or the area is not protected | Check those properties first, then verify land claim or bedroll protection before assuming corruption |
| Disk activity is high while players explore | One possible cause: EnableMapRendering is on and writing map tiles | Disable map rendering unless you actively use that dashboard feature |
Tune it more, or upgrade the server?
Settings help most when the server is misconfigured or oversized for its job. They help much less when you are already near sensible values and the machine simply lacks headroom. The official dedicated server minimum is a 2.8 GHz quad-core CPU, 8 GB RAM, broadband with 2.5 Mbps upload recommended minimum, and 20 GB disk. The official recommended point is a 3.2 GHz quad-core or faster CPU, 16 GB RAM and 10 Mbps upload. More players need more bandwidth and RAM.
| Situation | Tune first | When tuning has probably run out |
|---|---|---|
| Lag mainly appears on horde night or when several players split up | Lower MaxSpawnedZombies, review Blood Moon Count, and cap view distance more conservatively | If those settings are already modest and the server still stalls, you are likely short on CPU time or RAM rather than configuration |
| New players wait a long time to join | Review ServerMaxWorldTransferSpeedKiBs and world size; larger worlds mean more data to send | If upload is already the bottleneck, compare your connection or plan against the official 2.5 Mbps minimum and 10 Mbps recommended upload guidance |
| The save keeps growing and storage becomes awkward | Use a smaller map next wipe, review MaxChunkAge and SaveDataLimit, and disable map rendering if unused | If you genuinely need a large RWG world, remember up to 15 GB drive space may be needed for a large map, the client and lots of player data |
| You host the dedicated server and play the game on the same machine | Lower world size and high-impact settings to keep memory pressure down | The official warning is simple: running the server and the game client on the same computer doubles RAM requirements, so configuration alone may not save it |
If you are comparing plans instead of pushing the current one any harder, see our 7 Days to Die server hosting comparison. If price is the main constraint, it is also worth checking our guide to cheap UK game server hosting so you can judge what you are giving up in CPU headroom, RAM and support tools.
If your V3.x server is already on sensible settings and still struggles on busy nights, compare hosts and plans based on CPU, RAM, storage and panel access rather than chasing one more config change.
Compare the best 7 Days to Die server hosts7 Days to Die server FAQ
Why do my serverconfig.xml changes do nothing in V3?
Usually because you edited a legacy gameplay property that V3.x moved into SandboxCode. The server still starts, but those old lines are ignored. Also remember that serverconfig.xml is only read at server start, so a restart is required after edits.
Where do I set blood moon frequency on a V3 dedicated server?
Set it in the in-game Sandbox Options, then copy the generated code into the SandboxCode property in serverconfig.xml. Do not rely on old BloodMoonFrequency lines from V2-era guides, because V3.x ignores them.
What is the best view distance for a 7 Days to Die server?
There is no single best value for every server, but ServerMaxAllowedViewDistance is one of the strongest performance levers because it affects memory usage and general server load. Start from the default, reduce it only if you have clear signs of pressure, and keep the change only if players gain smoother play without unacceptable draw-distance compromise.
How many players can a 7 Days to Die server have?
The shipped default for ServerMaxPlayerCount is 8. You can set player counts for PC servers beyond that, but crossplay listing rules are stricter: servers are only found and joinable for console players if they use the default or fewer player slots and keep sanctions enabled.
How much RAM does a 7 Days to Die dedicated server need?
The official dedicated server minimum is 8 GB RAM, with 16 GB RAM recommended. Larger worlds, more players and higher active entity counts need more headroom, and hosting the dedicated server while also playing on the same machine doubles RAM requirements.
Related server guides
Compare hosts once your settings are sensible, or see how other survival games handle the same problems.
Game updates and host panels change. If a panel labels an option differently from the shipped file, follow your host’s current panel where it differs, but keep the V3 split in mind: server behaviour in serverconfig.xml, gameplay rules in SandboxCode.
