Project Zomboid servertest.ini Settings Explained (Build 42)

Where servertest.ini lives, and what the four server files do

On Windows, the default config folder is C:\Users\<you>\Zomboid\Server. On Linux, it is ~/Zomboid/Server. If you start the dedicated server without extra launch flags, it uses the default server name servertest, which means it will read and write files named servertest.ini, servertest_SandboxVars.lua, servertest_spawnpoints.lua and servertest_spawnregions.lua.

The important bit is that servertest is not special beyond being the default. Start the server with -servername NAME and the whole config set changes with it: a different .ini, a different SandboxVars file, a different save folder and a different account database. That is why a server can look as if its settings vanished when in fact it simply booted a different named profile. If you still need install and launch basics, the dedicated server setup guide covers the dedicated app, launch flags and folder layout.

• servertest.ini: server identity, browser listing, ports, passwords, player cap, access rules, anti-cheat, backups, RCON, mods, Workshop IDs and map load order.
• servertest_SandboxVars.lua: world rules such as zombie population, loot, farming, vehicles and progression. Those are covered separately in the sandbox settings guide.
• servertest_spawnpoints.lua: exact spawn coordinates.
• servertest_spawnregions.lua: which regions or professions feed the spawn menu.

Your live world save is separate again, under Zomboid/Saves/Multiplayer/servertest. Accounts and whitelist data are in Zomboid/db/servertest.db. Character records live in players.db inside the save folder. For troubleshooting, the main server log is server-console.txt.

.ini syntax is simple: one setting per line, written as key=value. Toggles use true or false. Some lines take lists, often separated by semicolons, such as WorkshopItems=. Map= uses semicolons as well, but there the order matters, and the comma in the default Muldraugh, KY is part of the map’s name, not a separator. The format of Mods= has changed during Build 42, so let the game or your panel write that line once and copy its format when you add more.

How changes take effect: live reload, command change, or full restart

Most servertest.ini values can be changed on a running server, then applied with reloadoptions. That is useful for rule toggles and text fields because the server re-reads its options without replacing the save. To change a single option from the console or admin chat, use changeoption and check the result with showoptions.

reloadoptions
showoptions

/changeoption PublicName "Fresh World EU"
/changeoption PauseEmpty "true"
/showoptions

Use the server console without a leading slash, or in-game admin chat with one. If you need the exact syntax for other admin tools, the full admin command list has the syntax for every other command.

Some changes deserve a full stop and start instead, because they affect how clients connect or what they must download:

• DefaultPort, UDPPort and RCONPort: the server opens its ports when it starts.
• Mods, WorkshopItems and Map: the server has to mount the right content, Steam has to fetch it if needed, and clients need to reconnect against the same list.
• Anything in SandboxVars.lua: sandbox changes need a restart.

For hand edits, the safe habit is simple: stop the server, edit, start it again. A running server or a panel can write its own copy of the file and quietly undo a good edit.

The first ten lines worth setting on any new server

These are the settings that define privacy, safety, persistence and admin control before anyone builds anything valuable. The defaults work, but they already make choices for you: anyone can register, PvP is on and the world only saves when players leave an area. Settle these before players build on one set of rules and find them changed later.

Public=false
PublicName=My PZ Server
Open=true
Password=
MaxPlayers=32
PauseEmpty=true
SaveWorldEveryMinutes=0
PVP=true
SafetySystem=true
RCONPassword=

If you close the server with Open=false, remember the access workflow changes as well: admins must create accounts, and on current Build 42 servers that also means adding the player’s SteamID. The admin and whitelist guide covers that process cleanly.

Every servertest.ini setting, by group

The reference tables below list every key, its default and what it does, grouped by job so you can scan server identity, networking, access, safehouses, anti-cheat, logging and the rest without hunting through one long alphabetic dump.

Settings that change performance or network load

Not every lag complaint is a hardware problem. A handful of lines change how much the server has to simulate, store or send, and they are worth checking before you buy more RAM.

• MaxPlayers: more players means more loaded areas, more zombie simulation, more inventory updates and more map streaming. That compounded load is why the official notes warn about going above 32.
• SaveWorldEveryMinutes: periodic saves reduce rollback after a crash, but they also create regular disk work. If freezes line up with the save timer, lengthen the interval.
• MaxPacketsPerSecond: this caps how many packets per client the server will process. Raising it can admit more network chatter and CPU work; lowering it can reject abusive or noisy traffic, but too low can punish legitimate busy clients.
• CarEngineAttractionModifier (default 0.5): how far car noise pulls zombies. The game’s own notes say lower values can help with lag, because fewer zombies are dragged into active pathfinding around drivers.
• ItemNumbersLimitPerContainer (default 0, no limit): caps items per container, counting every nail separately. It stops giant hoarder crates, but a limit of 50 really does mean 50 nails, so set it generously.
• BloodSplatLifespanDays (default 0, never): removes old blood splats when chunks load, which keeps long-running worlds tidier.

If these settings are already sensible and the save still stutters as the world grows, check the Java heap as well. Heap that is too small causes constant garbage collection and worsening stutter; heap set too close to the machine limit risks the process being killed with no clean save because Java also uses memory outside the heap. For broader diagnosis, including when to tune the config and when the machine simply needs more headroom, use the Project Zomboid server lag guide.

Safehouse, faction and PvP settings work as one rules system

Treat these lines as a single policy, not separate toggles. PVP decides whether player damage exists at all. If PVP=false, the safety settings are largely irrelevant because nobody can hurt anyone anyway. If PVP=true and SafetySystem=true, each player can toggle safety status; at least one of the two players has to be in PvP mode for damage to happen. That is why this system feels forgiving for mixed groups but still allows consensual fights.

ShowSafety exposes that state in-world so players can read intent. SafetyToggleTimer (default 2) is how long it takes to switch PvP mode on or off, which stops instant flips mid-fight, and SafetyCooldownTimer (default 3) is the wait before a player can switch again.

Safehouses then decide where those PvP rules should be softened or hardened. PlayerSafehouse and AdminSafehouse decide who can claim. SafehouseDaySurvivedToClaim gates how quickly players lock down property. SafehouseAllowTrepass, SafehouseAllowLoot and SafehouseAllowFire determine whether a safehouse is simply a home marker or an actual protection layer. DisableSafehouseWhenOwnerConnected makes a safehouse behave like a normal house while an owner is online, so it is only secure while they are away. That suits raid-focused communities and feels odd on casual co-op worlds.

Factions add the social layer on top. Faction=true allows formal groups; the day-survived and tag requirements slow down instant clan branding on a fresh wipe. War lets safehouses be attacked during a declared war: WarStartDelay (600 seconds) is the warning time, WarDuration (3,600 seconds) is how long it lasts and WarSafehouseHitPoints (3) is the safehouse hit point limit. It makes conflict scheduled rather than random vandalism.

Anti-cheat response modes: what the numbers mean, and how strict to start

All AntiCheat* lines use the same response scale: 1 Ban, 2 Kick, 3 Log and 4 Disable. Most checks default to 2, a sensible middle ground: the cheater is removed at once, but a false positive costs an innocent player a reconnect rather than a ban. AntiCheatNoClip and AntiCheatPacketException ship at 4, switched off.

For a new public community, start conservative. Kick or log first, watch the pattern in the server logs, and only move a check to ban once you know what normal play triggers on your server. Permanent bans are admin work: appeals, mistaken matches and trust damage all cost more than a short kick.

Keep DoLuaChecksum=true in mind here too. It is not one of the numbered anti-cheat lines, but it does kick clients whose Lua files do not match the server. That protects against tampered files, yet it is also a known source of false positives on some Linux setups, so if players start failing with file-mismatch errors after a clean update, rule that out before assuming cheating.

The lines you must never lose

Some settings are replaceable. These are not. Back up your .ini together with the save and the database, and keep a copy outside the live machine. The backup and restore guide goes through the process, but the short version is simple: if these lines change unexpectedly, players feel it immediately.

• ResetID and ServerPlayerID: if the numbers no longer match what a player’s client expects, that player has to create a new character. The game’s own notes advise backing them up somewhere safe.
• Seed: this is the world generation seed. Changing it does nothing to an existing world; to generate with a new seed you also need to remove map_worldgen.bin from the save after backing it up.
• Mods, WorkshopItems and Map: these define the content set and map load order. They decide what the server loads, what clients must download and, with map mods, which cells win when two maps overlap.

On map load order, later entries overwrite earlier ones where they intersect, and the default Muldraugh, KY belongs at the end. On a live save, adding or removing mods is the point where discipline matters most: back up first, restart fully, and do not remove a mod casually if its items or tiles already exist in the world. Removed content can leave broken objects behind in the save. For the messy bits of Build 42 mod formatting and map order, the Workshop and map mods guide covers it in detail.

Symptom, likely cause, first fix

When something feels wrong, start with the setting that explains the behaviour before touching half the file. This table covers the failures that come up most often after a rules change, migration or fresh Build 42 setup.

Project Zomboid server FAQ

Where is servertest.ini on a dedicated server?

By default it lives in the user’s Zomboid server config folder: C:\Users\<you>\Zomboid\Server on Windows and ~/Zomboid/Server on Linux. If you start the server with -servername NAME, the file name changes to NAME.ini. Make sure you edit the file that matches the server name actually used at launch.

Do I need to restart after changing servertest.ini?

Not always. Many options can be applied live with reloadoptions or changed directly with /changeoption, then checked with showoptions. Use a full restart for port changes and for Mods, WorkshopItems or Map changes, because clients and Steam need to pick up the same content set.

What is the difference between servertest.ini and SandboxVars.lua?

servertest.ini covers server operation: listing, access, ports, admin, anti-cheat, backups, mod loading and similar non-world rules. SandboxVars.lua controls the world itself, such as zombie population, loot and many survival rules. In practice, if a setting changes how the world plays, it is usually Sandbox; if it changes how the server runs, it is usually the .ini.

How do I make my server private?

Set Public=false so it is not listed in the in-game browser, set Open=false so players cannot self-register, and add a join Password if you want a simple shared gate as well. Then create the allowed accounts manually and add their SteamIDs before they join. That gives you browser privacy, account control and a password gate together instead of relying on only one layer.

Why did my settings reset after a restart?

The usual cause is that the file was edited while the server, a panel or the Host screen later wrote its own copy over it, or the server started with a different -servername and loaded another file set. Stop the server, confirm the active server name, edit the correct files, then start it again. If it keeps happening on a rented server, make the change in the panel’s own settings page instead of the file.

More Project Zomboid server guides

The rest of our Project Zomboid server guides, plus the host comparison.