1. Does this update need a new world?
The Fun Pimps say so in each release's notes, and the pattern since 2025 is consistent:
- Minor updates keep saves. The 2.5 notes (2025-12-08) say "Although the build is compatible with 2.X save games we highly recommend starting a new game for the best experience."
- Major updates change the rules. The V3.0 "Dead Hot Summer" notes (2026-06-11) "Added warning when trying to load save game from older major version", and moved most gameplay settings out of the config file: "With the addition of over 150 Sandbox Options, some of the legacy options previously set in serverconfig.xml have been moved to a new SandboxCode XML property." A V2.6 save can continue, but only after the step in section 3.
- Point releases in the V3 series (3.0.1 on 2026-07-13, 3.1.0 on 2026-07-27, 3.2.0 on 2026-08-26 and 3.3.0 on 2026-10-05) carry no new-game requirement in their notes. The 3.1 notes do add a branch reminder: "If you're playing on a dedicated server and can't connect yet, you will need to select the correct branch, Default Public Version which is the v3.1.0 stable".
The server tells you which build it is on the first lines of its log, for example Version: V 3.3.0 (b18) Compatibility Version: V 3.3.0, Build: LinuxServer 64 Bit, and a few lines later Last played version: for the save it is about to open. If those two differ by a major number, read section 3 before you let it load.
2. What a "world" is on a dedicated server
Three settings in serverconfig.xml decide which save the server opens, and the comments beside them are The Fun Pimps' own:
GameWorld: "'RWG' (see WorldGenSeed and WorldGenSize options below) or any already existing world name in the Worlds folder (currently shipping with e.g. 'Navezgane', 'Pregen06k01', 'Pregen06k02', 'Pregen08k01', 'Pregen08k02', ...)".WorldGenSeed: "If RWG this is the seed for the generation of the new world. If a world with the resulting name already exists it will simply load it".GameName: "Whatever you want the game name to be (allowed [A-Za-z0-9_-. ]). This affects the save game name as well as the seed used when placing decoration (trees etc.) in the world. It does not control the generic layout of the world if creating an RWG world".
The save itself lives under the user data folder, in Saves/<GameWorld>/<GameName>. On Linux the default user data folder is ~/.local/share/7DaysToDie, so a default config saves to ~/.local/share/7DaysToDie/Saves/Navezgane/MyGame, which is the path the server prints when it starts its save thread. The config lets you move all of it: "UserDataFolder: Use this to override where the server stores all user data, including RWG generated worlds and saves. Do not forget to uncomment the entry!" The admin list is kept relative to the same place: AdminFileName is a "Path relative to UserDataFolder/Saves".
Those three settings also give you the two ways to start over:
- New GameName, same world. Change
GameNameand the server creates a fresh save for the same map on the next start. The old save folder stays on disk, so this is the reversible option. - New map. Change
WorldGenSeed(andWorldGenSizeif you want) withGameWorldset toRWG, or pick another shipped world name. A generated world is kept under the user data folder too, and reusing a seed loads the existing world rather than generating again.
Stop the server before either change. The console command for that is shutdown, and saveworld first if you want the last minutes written out. The backup checklist applies: copy the whole user data folder before you touch it.
3. Keeping a V2.6 save on V3
V3.0 removed the difficulty and most gameplay properties from serverconfig.xml. The release notes describe the migration for admins who do not want to wipe: "For server admins that wish to continue their V2.6 save game, you will need to recreate your legacy serverconfig.xml settings using the in-game Sandbox Options menu. Copy the code, and then paste it as the SandboxCode property value in the updated V3.0 serverconfig.xml file." The shipped V3.3 config carries the property with this default:
<property name="SandboxCode" value="AAAJABJACJADJARFBNC"/>
Its comment says it is "Currently set to the default difficulty of Adventurer", and that the code "can be changed by starting the new game screen, clicking on the sandbox options button, adjusting the options, and then using the copy code button to paste it here." Two things from the later notes: 3.1 warns that "Invalid codes may default some or all settings", and the 3.1.0 notes list a fix for an "EndofStreamException and corrupted game from converting copies of saves to v3.0", so convert a V2.6 save on 3.1.0 or later rather than on the launch build.
One consequence for anyone who used to set difficulty on the command line or in the old GameDifficulty property: in our V3.3 test the server still recorded a GamePref.GameDifficulty when it was passed one, but the difficulty it reported in its game stats did not follow that value. Set difficulty through the code, not the old property.
4. The middle option: reset the map but keep the players
V3.0 added something between "keep" and "wipe". The notes list "Add Continue Game option to opt into a full reset of all unprotected chunks" and "Add server command to trigger a full reset of all unprotected chunks". The in-game option is called Reset Unprotected Chunks, and the game's own description is: "On load, resets all chunks not protected by a land claim or bedroll." Its confirmation reads: "All unprotected chunks will be reset when the world loads. This cannot be undone. Continue?"
On a dedicated server the same thing is a console command. The server's help text for it:
*** Command(s): worldchunkreset, wcr ***
Usage: wcr [-g|-gmode <n>]
Examples:
'wcr' - reset all unprotected chunks using the default grouping.
'wcr -g 2' - reset all unprotected chunks, grouping mode 2.
Grouping modes (-g|-gmode, default 3):
'1' - NoGrouping: Chunks are reset based on their own protection flags only.
'2' - SeparatePOIs: Each POI gets the combined protection flags from all chunks overlapping the POI.
'3' - GroupedPOIs: Like SeparatePOIs, but POIs with overlapping chunks also merge into groups. Standard reset; should not cause POI discontinuities.
Notes:
- All chunk protection statuses are respected. To bypass protections, see 'rr'.
- Use with caution! This operation permanently deletes all saved data for affected chunks.
The grouping modes are the same three the Sandbox option offers as "Protection Determined per Chunk", "Protection Extends to POI" and "Protection Extends to POI Groups": they decide whether a land claim or bedroll in one chunk protects the whole point of interest it sits in. Two narrower commands exist beside it. regionreset (rr) does the same per region and adds protection modes, of which only the default respects every protection; the server's help marks the others "EXPERIMENTAL" and "provided for debug purposes only". chunkreset (cr) "Rebuilds the chunks that contain the given coordinate range"; its help says nothing about protection, so treat it as a tool for a chosen area rather than a wipe. With their default modes, wcr and rr leave chunks protected by a land claim or a bedroll alone and regenerate the rest, which is what most "wipe the loot but keep our base" requests actually want. The log confirms completion with [GameManager] Unprotected chunks have been reset.
Two older settings in the config do the same thing gradually. MaxChunkAge is "The number of in-game days which must pass since visiting a chunk before it will reset to its original state if not revisited or protected (e.g. by a land claim or bedroll being in close proximity)", -1 by default. SaveDataLimit caps each save's disk use, and when the cap is reached "Saved chunks may be forcibly reset to their original states to free up space"; negative values disable it. In V3.3 the Sandbox options show the same two as "Chunk Reset Timer" and "Chunk Persistence".
5. The full wipe
When the answer really is "start over", the order that loses nothing is:
- Announce it, then
saveworldandshutdownin the console. - Copy the user data folder somewhere else. It holds the saves, generated worlds and
serveradmin.xml. - Change
GameName, or the seed and size for a new map. DeletingSaves/<GameWorld>/<GameName>instead is the only way to reuse the same name and map. - Review
SandboxCode, because the config's closing comment still applies: "There are several game settings that you cannot change when starting a new game. You can use console commands to change at least some of them in-game", in the formsetgamepref BedrollDeadZoneSize 30. - Start the server and watch for the save thread line naming the new folder.
One setting from the config about the join screen is worth passing on to players: PersistentPlayerProfiles is false by default, so "a player can join with any selected profile"; "If true they will join with the last profile they joined with".
Where ForgeWorld Gaming fits
On a ForgeWorld Gaming 7 Days to Die server, serverconfig.xml is yours to edit on the control panel's Files tab, and the panel never rewrites it, so GameName, GameWorld, WorldGenSeed, WorldGenSize and SandboxCode are changed there and take effect on the next start. A server update that ships a different serverconfig.xml does replace it, and so does a reinstall, as the 7 Days to Die server settings reference explains, so keep a copy of your edited file. The start command sets a few things over the file: the game port, the player count of your plan, the telnet settings, the disabled network protocols from the Startup tab's Network Protocols variable, and a legacy -GameDifficulty from its Game Difficulty variable; everything else in the file is honoured. On V3 set the difficulty in SandboxCode and leave that variable alone. The user data folder is .local/share/7DaysToDie on the Files tab, so a default save sits at .local/share/7DaysToDie/Saves/Navezgane/MyGame, next to serveradmin.xml, and the Console tab is the telnet console, where saveworld, shutdown and wcr are typed. While the Auto Update variable is on, each start checks Steam for a newer server build; a test server we started on 2026-10-19 reported V 3.3.0 (b18). While Auto Update is on, each start passes the Beta Branch variable to that Steam check, so a branch entered there is installed at the next start without a reinstall. Last checked 2026-10-19.
Prefer renting to keeping your own server machine online? ForgeWorld Gaming currently offers 7 Days to Die Standard: 4, 8 player slots at CA$16.49–CA$20.49/month. Hosted in Iowa, United States. Prices are in Canadian dollars, with no setup fee and cancel any time. Your server is set up automatically after payment. Continue to secure billing, 7 Days to Die · Dedicated server, CA$16.49 / month (Standard, 4 slots), or compare 7 Days to Die plans.