V3.0 SandboxCode - The serverconfig.xml Migration Guide for Dedicated Servers

Updated July 23, 2026. V3.0.1 is the current stable branch; the SandboxCode migration below is unchanged. The new note is V3.1.0.

V3.1.0 "Henpocalypse" (now in experimental) adds sandbox options and changes existing ones. On the latest_experimental branch, your SandboxCode gains new keys and two existing ones change shape: Density and Respawn are now split into day and night values and into enemy and animal types, so a SandboxCode encoded under V3.0 may need re-generating. New sandbox options: Chicken Coop Time / Yield / Input, Chicken Stress Event, Infection Chance, Hunger Multiplier, Thirst Multiplier, and a Stack Size Multiplier (capped at 30,000). 3.1.0 also fixes the getsandboxoptions console command not returning results to clients, plus a serverside memory-stream exception and an EOS exception during POI reset. This applies only once your server is on the 3.1.0 experimental branch; V3.0.1 stable is unaffected until it promotes.

V3.0 makes the biggest change to serverconfig.xml in the game's history: 29 legacy properties are removed and replaced by a single SandboxCode property that encodes your entire sandbox configuration. If you run a dedicated server, your old config will not carry those settings into V3.0 - here is exactly what changed, the migration procedure TFP prescribes, and the gotchas for continued V2.6 saves.

What changed

The 150 new sandbox options replace the old scattering of serverconfig properties. Instead of editing individual XML lines, you now configure everything in the in-game Sandbox Options menu, which generates a compact code string - or build, encode and decode that string in your browser with the 7 Days to Die SandboxCode generator, without launching the game. That code is the new single source of truth, set in serverconfig.xml as:

<property name="SandboxCode" value="AAAJABJACJADJARFBNC"/>

That default value is the equivalent of the legacy GameDifficulty "Adventurer" (1) setup. Any custom ruleset produces its own code.

The 29 removed legacy properties

These no longer function in V3.0's serverconfig.xml - their values are encoded in SandboxCode instead:

GameDifficulty · BlockDamagePlayer · BlockDamageAI · BlockDamageAIBM · XPMultiplier · DayNightLength · DayLightLength · BiomeProgression · StormFreq · DeathPenalty · DropOnDeath · DropOnQuit · JarRefund · EnemySpawnMode · EnemyDifficulty · ZombieFeralSense · ZombieMove · ZombieMoveNight · ZombieFeralMove · ZombieBMMove · AISmellMode · BloodMoonFrequency · BloodMoonRange · BloodMoonWarning · BloodMoonEnemyCount · LootAbundance · LootRespawnDays · AirDropFrequency · AirDropMarker · QuestProgressionDailyLimit

Server-level properties unrelated to gameplay rules (ports, names, passwords, player counts, region settings) are untouched.

The migration procedure

  1. Before updating: record your current settings. Open your V2.6 serverconfig.xml and note the values of every property in the removed list above. A screenshot or copy of the file is enough.
  2. Now that the experimental branch is live - or on stable later - update the server, after a verified backup of the save. (Opt in via the Steam beta branch latest_experimental.)
  3. Recreate the ruleset in-game. Start the V3.0 client, open the Sandbox Options menu, and set each option to match your recorded values (the new options are finer-grained, so most legacy values map onto an equivalent or better knob).
  4. Copy the generated code from the menu.
  5. Paste it into V3.0's serverconfig.xml as the SandboxCode value, replacing the default.
  6. Start the server and verify in-game that difficulty, XP, blood moon cadence, and loot behave as before.

What the V3.0 file should look like (simulated)

The shape of the file is straightforward and derivable: take the V2.6 default, delete the 29 removed properties, add SandboxCode. Everything below the gameplay section (server name, ports, slots, telnet, land claims) is untouched by the changes. This is built from the official notes; with V3.0 experimental now live, you can confirm it against the real file in your own install.

V2.6 gameplay section (today):

<!-- GAMEPLAY / Difficulty -->
<property name="GameDifficulty"      value="2"/>    <!-- REMOVED in V3.0 -->
<property name="BlockDamagePlayer"   value="100"/>  <!-- REMOVED -->
<property name="BlockDamageAI"       value="100"/>  <!-- REMOVED -->
<property name="BlockDamageAIBM"     value="100"/>  <!-- REMOVED -->
<property name="XPMultiplier"        value="100"/>  <!-- REMOVED -->
<property name="DayNightLength"      value="60"/>   <!-- REMOVED -->
<property name="DayLightLength"      value="18"/>   <!-- REMOVED -->
<property name="DropOnDeath"         value="1"/>    <!-- REMOVED -->
<property name="DropOnQuit"          value="0"/>    <!-- REMOVED -->
<!-- Zombies -->
<property name="EnemySpawnMode"      value="true"/> <!-- REMOVED -->
<property name="EnemyDifficulty"     value="0"/>    <!-- REMOVED -->
<property name="ZombieFeralSense"    value="0"/>    <!-- REMOVED -->
<property name="ZombieMove"          value="0"/>    <!-- REMOVED -->
<property name="ZombieMoveNight"     value="3"/>    <!-- REMOVED -->
<property name="ZombieFeralMove"     value="3"/>    <!-- REMOVED -->
<property name="ZombieBMMove"        value="3"/>    <!-- REMOVED -->
<property name="BloodMoonFrequency"  value="7"/>    <!-- REMOVED -->
<property name="BloodMoonRange"      value="0"/>    <!-- REMOVED -->
<property name="BloodMoonWarning"    value="8"/>    <!-- REMOVED -->
<property name="BloodMoonEnemyCount" value="8"/>    <!-- REMOVED -->
<!-- Loot -->
<property name="LootAbundance"       value="100"/>  <!-- REMOVED -->
<property name="LootRespawnDays"     value="7"/>    <!-- REMOVED -->
<property name="AirDropFrequency"    value="72"/>   <!-- REMOVED -->
<property name="AirDropMarker"       value="false"/><!-- REMOVED -->
<!-- (plus, in V2.x-era files: BiomeProgression, StormFreq, DeathPenalty,
     JarRefund, AISmellMode, QuestProgressionDailyLimit - all REMOVED) -->

V3.0 gameplay section (simulated):

<!-- GAMEPLAY -->
<property name="GameWorld"    value="Navezgane"/>
<property name="WorldGenSeed" value="asdf"/>
<property name="WorldGenSize" value="6144"/>
<property name="GameName"     value="My Game"/>
<property name="GameMode"     value="GameModeSurvival"/>

<!-- ALL gameplay rules now live in one property. Generate the code in the
     in-game Sandbox Options menu and paste it here. This default is the
     equivalent of the old GameDifficulty="Adventurer": -->
<property name="SandboxCode"  value="AAAJABJACJADJARFBNC"/>

<!-- Unchanged: PlayerSafeZone*, Bedroll*, MaxSpawnedZombies/Animals,
     view distance, PartySharedKillRange, PlayerKillingMode, LandClaim*,
     DynamicMesh*, Twitch*, and the entire general-server section
     (ServerName, ports, slots, passwords, telnet, EAC). -->

The visual is the point: roughly thirty lines of gameplay tuning collapse into one opaque string, and the in-game menu becomes the only sane editor. Server panels that template these properties will need V3.0-aware templates; until your host ships one, the copy-paste flow above is the way.

Continuing a V2.6 save

TFP confirms V2.6 save continuation is supported, but the settings migration is on you: the server will not translate your old properties automatically - an un-migrated config silently runs the default Adventurer-equivalent ruleset, which is how a hardcore server wakes up casual. TFP also notes, verbatim, that you "may need to work with your specific provider" - hosting panels that template serverconfig.xml need V3.0-aware templates before their customers update. Until your host confirms V3.0 support, pin your server to V2.6.

Gotchas worth knowing on day one

  • The code is opaque. SandboxCode is not human-readable; the in-game menu is the only sane editor. Keep a text note of your intended settings alongside the code in your server docs.
  • Preset sharing is the new config sharing. Community rulesets travel as preset codes now - treat codes from strangers like any pasted config: load them in singleplayer first and review what they set.
  • Experimental first. The usual rule applies double for a config-format change: run V3.0 on a test world before moving your community save, remember saves do not downgrade, and keep client and server on the same branch (a 3.0 client cannot join a 2.6 server).
  • Mods and the new formats. V3.0 also renames Localization.txt to Localization.csv and overhauls XUi - expect server-side mods to need updates in the same window. Full modding notes in the release-notes breakdown.

V3.0.1 experimental: server-relevant fixes

V3.0.1 Experimental is the first post-stable patch (opt in via the Steam latest_experimental branch). Several of its fixes touch server config and sandbox behavior directly:

  • Airdrops now respect the "night" setting. If you set the airdrop sandbox option to night and drops were not appearing, V3.0.1 fixes it - timing now behaves as configured.
  • PvE "no killing" settings no longer leak PVP damage. Under some conditions players could still take PVP damage with killing disabled; that is patched. Re-verify your PvE ruleset on the experimental branch.
  • Max-degradation reset exploit closed. Item max degradation could be reset by restarting the game and rejoining a server - fixed, which matters if you run the Repair & Degradation lever.
  • Dedicated-client and networking: biome zombie kills with Celebrate now count toward the Kill Challenge, and a null-reference error on receiving NetPackageLockRequest (a join/lock packet) is fixed.

Keep client and server on the same branch, and test on a throwaway server before flipping a live world. Full breakdown on our V3.0 page.

Sources