7 Days to Die Server Settings: A V3 Reference Guide

If a 7 Days to Die server settings guide tells you to paste separate XP, loot or blood-moon lines into serverconfig.xml, pause before copying it. In V3.2.0, that file covered server identity, access, world setup and server operation; SandboxCode carried gameplay options. The dedicated server checked for this reference reports V3.2.0 (b10), a historical baseline rather than today’s stable release. The Fun Pimps announced V3.3.0 Stable on October 5, 2026, and its latest experimental announcement located here is V3.3.0 EXP b18. Keep the server and every player’s client on compatible builds, and check the exact file shipped with the version you run.

If you prefer a form over editing XML, Game Hosting’s 7 Days to Die panel mirrors the split with about 45 XML fields and a separate SandboxCode editor for 165 options and 17 presets. If you are still choosing how to run your world, see the dedicated-server options and our host checklist.

Locate 7 Days to Die server settings by type#

V3 has two places to check: serverconfig.xml for server properties and SandboxCode for the game rules that appear in the sandbox editor. Do not use an old table of XML names as a complete V3 schema. The inspected V3.2.0 b10 server file includes 68 properties and one SandboxCode value; the matching sandbox catalog contains 165 options. The file counts and defaults below are specific to that inspected build, not verified V3.3.0 defaults.

The inspected V3.2 XML is a reference for that build’s property names and defaults. Its SandboxCode example is AAAJABJACJADJARFBNC, the default Adventurer configuration. Stable is now V3.3.0; this article has not checked its shipped XML. Recheck the exact build before copying property names or defaults. See the official V3.3.0 Stable notes, the latest V3.3.0 experimental update located and the earlier V3.2.0 Stable notes for the version boundaries.

Set the server name, visibility and player limit#

Make the listing recognizable, then choose who can find it. These values come from the V3.2.0 b10 default file:

On a dedicated server, ServerVisibility=1 is easy to misunderstand: the inspected V3.2.0 file explains that friends-only listing works only after the first player connects manually by IP, because a dedicated server is not itself a friend. Confirm that caveat and the exact value in the configuration for the build you use. For a private group, use a password and decide whether a hidden listing or a public listing with a password fits your setup. Change the name before telling friends what to search; then verify the exact spelling in the server browser. For a fuller comparison of passwords, allowlists and visibility, see how to make a private 7 Days to Die server for friends.

Do not raise the player limit just because a panel accepts a larger number. More players add simulation, memory and network work, and console crossplay has a lower documented limit. Check the version and platform mix first, then pick a cap your server can actually support.

Choose the world before the first session#

GameWorld selects the world. The default is Navezgane; RWG asks the game to generate a random world. The current file also lists shipped pregenerated worlds such as Pregen06k01, Pregen06k02, Pregen08k01 and Pregen08k02. Confirm a world name exists in the installed build before entering it by hand. For a group choosing among those options before its first start, see our guide to world settings for a new server.

Treat these as setup choices, not cosmetic labels. Write down the world, seed, size and save name the group intends to use before launch, and back up an existing save before experimenting with a different version or map. WorldGenSeed and WorldGenSize matter only when generating an RWG world; changing them does not redraw a named map.

Set player rules and protect claimed bases#

Several rules people call “difficulty” remain ordinary server properties, while the gameplay sliders belong in SandboxCode. In the current file, PlayerKillingMode=3 means players can kill everyone; values 0, 1 and 2 mean no killing, allies only, and strangers only. Pick the PvP rule before inviting a group that expects a different one.

Claims are not a substitute for backups or server access controls. If players share a base, agree on claim size and expiry before someone goes offline for a week. Camera restrictions are separate too: CameraRestrictionMode=0 allows first- and third-person views, 1 restricts players to first-person and 2 to third-person. Keep these concrete server rules distinct from XP, loot, death penalties and other sandbox options.

Keep the world load within a sensible range#

The V3 file exposes population and view-distance limits, but increasing them does not make a world spawn more activity everywhere. Start with defaults and raise a limit only after measuring the actual server under your group’s normal play.

There is no universal “best” zombie cap or view distance for every map and player count. A large RWG world with a dispersed group behaves differently from a small private session around one base. Change one performance setting at a time, keep a backup, and compare memory and responsiveness during a typical horde night before deciding whether the change helped.

Use SandboxCode for XP, loot and blood-moon rules#

Use the V3 sandbox controls for gameplay values such as difficulty, XP, loot, day length, zombie movement and blood-moon frequency. They are encoded in the SandboxCode property rather than represented by the old standalone property list in the stock V3 file. The panel and the game’s own Sandbox Options menu show these as named choices, which is easier to audit than guessing what a code position means.

The default code in the current V3.2.0 server file is:

AAAJABJACJADJARFBNC

That code is a compact bundle, not a readable set of individual XML lines. When your group changes several options, export or copy the complete code from a V3-compatible editor and keep the chosen code with the server’s backup notes. Do not paste a legacy tutorial’s XPMultiplier, GameDifficulty, BloodMoonFrequency or LootAbundance line and assume it is the supported V3 control: those are absent from the stock V3.2 serverconfig file. The current server can surface manually added values through its generic game-preference query, but that alone does not establish that an old line is the effective or supported gameplay setting. Use the named SandboxCode option and verify the code after saving.

If your group uses a custom map or overhaul, check its author’s required game build and settings before updating the server. Stable and experimental branches can move independently, and a save or mod compatible with one build is not automatically compatible with another. For mod setup and attribution, use our 7 Days to Die server-mod guide; it names each mod’s author instead of presenting community work as ours.

Secure admin access and check console crossplay#

Keep admin interfaces deliberate. WebDashboardEnabled defaults to false; its default port is 8080. TelnetEnabled defaults to true, and TelnetPort defaults to 8081. The stock XML says that an empty TelnetPassword restricts Telnet to the local loopback interface. If you do not use Telnet, turn it off. If you do, set a strong password and restrict network access with your firewall. Do not expose an unauthenticated admin interface to the internet.

Once you have a safe route into the server, our console commands for server admins guide covers the V3.2 save, player and world-time commands without asking you to expose Telnet.

For crossplay with the current PC, PlayStation 5 and Xbox Series X|S editions, set ServerAllowCrossplay=true, keep EACEnabled=true and IgnoreEOSSanctions=false, use a public listing and a player cap of 8 or fewer. Crossplay also requires a compatible, unmodded server and settings within the developer’s accepted ranges; a custom SandboxCode can make a server unavailable to consoles even while PC players can join. Check the official crossplay requirements before changing non-default values. The current console edition announcement covers the PC, PlayStation 5 and Xbox Series X|S release; do not apply these settings to the original Telltale-era Xbox One and PS4 edition.

Check the configuration before inviting players#

Before sharing a join code, verify the server name and listing, test the password with one player, confirm the world and save name, and compare the displayed sandbox options with the intended SandboxCode. Check that the server and clients use the same stable or experimental build. If an overhaul is involved, confirm its author’s version notes and backup the save before switching branches.

For a PC-only group, the default 8-player cap and stable branch are a straightforward starting point; for console crossplay, use the stricter requirements above and keep the server vanilla. If your setup’s goal is simply to keep a world available without hosting it from a player’s PC, compare the ways to run a dedicated server before changing more settings. The safest reference is always the exact serverconfig file and SandboxCode for the build you are actually running.