Quick Answer
Server settings live in separate layers, and editing the wrong one is the classic no-op: the INI (server behavior, ports, WorkshopItems=, Mods=), the SandboxVars file (world rules — loot, zombie speed, time, water shutoff, PVP), and the world save under Zomboid/Saves/Multiplayer. The routine that survives: identify the active profile, back up INI + SandboxVars + world together, change ONE group at a time, restart when required, verify with one client. Remember water shutoff is a world rule (0-2 months default) and zombie speed a sandbox value — different files.
Table of Contents
Settings-change workflow
The INI, SandboxVars, world save, and mod fields are separate layers. Change one at a time so a bad edit gets reversed by file, not by memory.
| Stage | Do | Passes when |
|---|---|---|
| Identify | Confirm the active preset and its files under Zomboid/Server | The file you're editing belongs to the running profile |
| Back up | Copy the INI, SandboxVars, world save, and mod records with a date | A previous state exists outside the live folder |
| Scope | Change one group — loot, zombies, PvP, or time | Only the intended group differs from the backup |
| Restart | Restart when the setting requires it | The loaded profile matches the edited one |
| Verify | Check the outcome with one client | The rule is visible before the next change |
Which layer holds which setting
The captured reference separates server configuration into layers and lists loot, zombie speed, time, water shutoff, and PVP among the server-level groups. Here is the layer map, with the settings players actually argue about.
| Setting group | Where it lives | What changing it really means |
|---|---|---|
| Loot abundance and distribution | World rules (SandboxVars layer), preset or custom | A world-rule change — back up the world save with it, and expect already-generated containers to keep their old rolls |
| Zombie speed and population | World rules (SandboxVars layer) | Speed is a sandbox value; population also interacts with the 30-day default growth curve — verify with one client after restart |
| Time and daylight | World rules (SandboxVars layer) | Also a world rule, despite feeling like a server knob |
| Water shutoff | World rules — 0-2 months in the default Apocalypse sandbox | A dated roll, not a switch: once it happens in the save, editing the setting later doesn't un-happen it. Get this right at world creation |
| PVP | Server-level settings group, preset or custom | Agree it with the group BEFORE launch — a mid-campaign PVP flip is a trust problem, not a settings problem |
| WorkshopItems, Mods, Map | The INI's separate mod fields | Not world rules: these change what gets loaded. Both WorkshopItems and Mods must be enabled for each item, per a Steam Support response |
Preset versus custom, and why the distinction saves servers
The reference distinguishes preset from custom configuration — and that distinction is the difference between a reversible change and an unsalvageable one.
A preset is a named, versioned bundle of world rules — the shared language your players agreed to. A custom change is an edit on top of that bundle, and every custom edit widens the gap between 'what the preset would do' and 'what this server does'. The operational rule that falls out: custom changes get logged (old value, new value, date, reason) even when nothing breaks — because the log is the only thing that makes the NEXT change safe. An unlogged custom server is a server nobody can reproduce after a failure.
The version mark matters here too. The dedicated-server page that anchors these file paths is 42.20.0-marked, and the 42.21 patch notes recommend manually backing up existing saves before testing on a new branch. Settings layers are the most stable part of a server, but 'stable across patches' is a claim about the past — your dated backup is the guarantee about the future.
And the failure the layer map prevents: 'I changed the water shutoff but it's still off.' If the shutoff already fired in the save, the setting edit can't retro-clean the taps — that fact lives in the world save now. Knowing which layer holds a setting tells you before you edit whether the change is live (INI restart), generational (world rules for new cells), or impossible (facts already baked into the save). That's the whole skill of server settings, in one table.
Reference data
PZFans separates the server settings layers and names the files a multiplayer server uses — including the split between WorkshopItems, Mods, and Map on one side and world rules on the other. Exact defaults and limits still need a Build 42.21 check.
| Settings layer | File or field | What it controls |
|---|---|---|
| Server INI | Zomboid/Server/<server>.ini | Server identity and connection profile |
| SandboxVars | Zomboid/Server/<server>_SandboxVars.lua | World rules — edit them here, not in the INI |
| World save | Zomboid/Saves/Multiplayer/<server> | The live world to back up |
| WorkshopItems / Mods / Map | Separate multiplayer mod fields | Compare server and client activation |
| ZombieConfig | Separate zombie population or behavior config | Don't mix population changes with player settings |
| Preset | Server preset name must match the files being edited | Prevents a valid change from being silently ignored |
FAQ
Where are Project Zomboid server settings stored?
In separate layers: the server INI (behavior, ports, WorkshopItems=, Mods=), the SandboxVars file (world rules like loot, zombie speed, time, water shutoff, PVP), and the world save under Zomboid/Saves/Multiplayer. Identify the active profile first — editing a dead profile is the classic silent no-op.
Can I change the water shutoff after the world was created?
Only forward. The shutoff is a dated roll (0-2 months in the default Apocalypse sandbox) — once it fires, the fact is baked into the world save, and editing the setting later doesn't restore the taps. Get water rules right at world creation; the same generational logic applies to loot rolls in already-generated containers.
Why did my settings change do nothing?
Three recorded causes: you edited the wrong profile (confirm the active preset first); the change is generational, not live (world rules apply to new content, not already-generated cells); or the server wasn't restarted when the setting required it. Verify with one client after each change — before the next one.
What's the difference between preset and custom server configuration?
A preset is a named, versioned bundle of world rules — the shared language the group agreed to. Custom is any edit on top. Log every custom change (old value, new value, date, reason): the log is the only thing that makes the next change safe, and an unlogged custom server is one nobody can reproduce after a failure.
Do server settings changes require a restart?
Most do — confirm per setting, and always check that the loaded profile matches the edited one after the restart. The workflow that avoids regressions: back up INI + SandboxVars + world together, change one group at a time, restart, verify with one client before touching the next group.