Configurer un serveur Project Zomboid : les fichiers qui comptent vraiment

A clean Project Zomboid server config is the difference between a community that survives months of looting runs and one that crashes every time a horde hits the generator shack. Most issues blamed on "bad luck" actually come from misunderstood servertest.ini values, sandbox variables set without testing, or a mod load order nobody documented.

How a Project Zomboid Server Process Actually Works

Project Zomboid runs its multiplayer mode as a separate executable from the client. When you launch the server binary (StartServer64.sh on Linux, StartServer64.bat on Windows), it spins up a Java process that reads a set of configuration files, loads the map and save state, opens the game port and the RCON port, then starts ticking the simulation. Players connect over UDP, but the actual logic — zombie pathing, loot tables, power grid decay — all runs server-side, which is why CPU single-thread performance matters more than core count for this specific game.

The first time you run the executable with a given -servername argument, it generates a folder structure under Zomboid/Server/ containing the ini file, the sandbox variables file, and a separate save directory. Every subsequent launch re-reads these files, so a typo in servertest.ini doesn't crash the game on save load — it just silently applies a wrong value, which is the most common source of "why is loot not respawning" tickets.

If you're setting this up for the first time and want the process management, backups and anti-DDoS layer already handled instead of configuring the Java process yourself, the Project Zomboid server hosting page covers the ready-to-use setup; the rest of this article focuses purely on what's inside the config files once the process is running.

For a broader catalog of supported titles with the same Pterodactyl-based management approach, see All our game servers.

Project Zomboid Server Config: SandboxVars.lua and servertest.ini

These two files control almost everything that affects difficulty, performance and player experience. They live in the same Server folder and are read on startup — changes require a restart, not just a save reload.

servertest.ini: connection, performance and population caps

This file handles network behavior, player limits, PVP rules and the first layer of performance tuning. A few parameters deserve more attention than the defaults suggest:

PVP=true
PauseEmpty=true
GlobalChat=true
MaxPlayers=32
PingLimit=400
Open=true
Public=false
PublicName=MyZomboidWorld
Mods=
WorkshopItems=
Map=Muldraugh, KY
SaveWorldEveryMinutes=0
BackupsCount=5
BackupsOnStart=true

PauseEmpty=true stops the simulation when nobody is connected, saving CPU cycles instead of letting zombies wander an empty map all night. SaveWorldEveryMinutes=0 disables the periodic autosave timer because Project Zomboid already saves on player disconnect and container interaction in most builds — leaving a short interval active on a populated map can cause noticeable stutter during the write, so test this value instead of trusting a forum default.

SandboxVars.lua: the gameplay engine

This is the file that actually defines the world's difficulty curve. It's a Lua table, so syntax errors (missing commas, wrong brackets) will make the server fall back to default values without always throwing a visible error in console.

SandboxVars = {
    ZombieConfig = {
        PopulationMultiplier = 2.0,
        RespawnHours = 72,
        RespawnUnseenHours = 16,
        RespawnMultiplier = 0.1,
        RedistributeHours = 12,
    },
    Loot = {
        LootRespawn = 1,
        SeenHoursPreventLootRespawn = 24,
    },
    XpMultiplier = 1.5,
    NightLengthModifier = 1,
    WaterShutModifier = 14,
    ElecShutModifier = 14,
}

Every value in this block is a direct lever on pacing. Getting the Project Zomboid server config right here is mostly about understanding the relationship between RespawnHours, RedistributeHours and PopulationMultiplier rather than copying a random preset — those three numbers interact, and tuning only one without the others usually produces either an empty map or an unplayable horde density.

Zombie Population, Loot Respawn and Mod Load Order

This is where most communities either get a satisfying survival loop or end up with players complaining the world feels "dead" or "unfair."

Zombie population and respawn logic

Variable	Effect	Typical range
PopulationMultiplier	Base zombie density on map load	1.0 – 3.0
RespawnHours	In-game hours before new zombies spawn in cleared cells	24 – 168
RespawnUnseenHours	Hours a cell must remain unvisited before respawn applies	16 – 48
RedistributeHours	Frequency at which existing zombies migrate toward sound/activity	6 – 24

A high PopulationMultiplier with a short RespawnHours turns any cleared town into a recurring meat grinder, which some PVE groups want but most PVP communities find exhausting. Push RespawnUnseenHours up if players report zombies reappearing in bases they thought were secured — it forces the engine to wait longer before repopulating a visited cell.

Loot respawn without breaking scavenging balance

LootRespawn controls whether containers refill at all (0 = never, 1 = enabled). SeenHoursPreventLootRespawn is the real tuning knob: it defines how long a container stays "seen" and therefore excluded from respawn. Communities running long-term saves usually raise this to 48–72 hours to avoid turning every house into an infinite loot farm.

Mod load order

Project Zomboid loads mods in the exact order listed in the Mods= and WorkshopItems= lines of servertest.ini. Dependencies must load before the mods that require them, or you'll get missing-texture errors and script errors in the console log at startup.

WorkshopItems=2434187449;2440879983;2458566834
Mods=BrianGMA_MoreTraits;ImprovedWeapons;FirearmsB41

Check the mods/ folder names inside each Workshop ID directory to get the correct internal mod name for the Mods= line — the Workshop numeric ID and the mod's internal string are not the same thing, and mismatching them is the single most common reason a mod "installs" but never actually loads. The official Source documents the full modding structure if you're packaging your own.

Save Folder Structure and Admin Practices

Understanding where data actually lives matters as much as the ini values themselves, especially before restoring a backup or migrating a world.

Zomboid/
├── Server/
│   ├── servertest.ini
│   ├── servertest_SandboxVars.lua
│   └── servertest_spawnregions.lua
├── Saves/
│   └── Multiplayer/
│       └── servertest/
│           ├── map_p.bin
│           ├── map_meta.bin
│           ├── players.db
│           └── world_database.db
└── db/
    └── servertest.db

world_database.db and players.db are the files that actually matter for a rollback — copying only the ini files back after a bad config change won't restore player state, only behavior going forward. Before testing any risky sandbox change, stop the process cleanly and snapshot the whole Saves/Multiplayer/servertest/ folder rather than relying on in-game autosave alone.

systemctl stop pzserver
tar -czf zomboid_backup_$(date +%F).tar.gz Zomboid/Saves/Multiplayer/servertest/
systemctl start pzserver

On a VPS used to run this kind of process yourself, keep SSH access locked to key-based authentication, restrict the game and RCON ports with ufw, and schedule the backup script above as a cron job rather than trusting manual exports. If you manage the process through a panel instead, Pterodactyl exposes the same Saves and Server folders through its file manager, which avoids touching the filesystem directly for routine edits — see Pterodactyl VPS for that management layer.

Whitelisting trusted players via DenyLoginOnOverloadedServer and keeping an admin password separate from the RCON password are both worth doing before opening a world publicly. For reference on other survival titles using a similar ini/sandbox approach, DayZ server and Project Zomboid server share comparable file-based tuning philosophies.

Conclusion

A working Project Zomboid server config comes down to three things: understanding what servertest.ini actually governs versus SandboxVars.lua, testing zombie and loot respawn values together rather than in isolation, and knowing exactly which save files to back up before experimenting. Get those right and the rest is just iteration.

FAQ

Why does loot stop respawning even though LootRespawn is enabled?

Check SeenHoursPreventLootRespawn — if it's set too low or containers are visited frequently, the engine keeps marking them as seen and skips the respawn cycle. Raise the hour value and avoid revisiting the same containers during testing.

How do I fix a mod that shows in the Workshop list but never loads?

The WorkshopItems ID and the Mods= internal name are separate values. Open the downloaded mod folder and use the exact internal mod ID (not the Steam Workshop number) in the Mods= line of servertest.ini.

What's the safest way to test a sandbox change without risking the save?

Stop the process cleanly, copy the entire Saves/Multiplayer/<servername>/ folder as a backup, then edit SandboxVars.lua and restart. If the new values break pacing, restoring the copied folder reverts everything instantly.