Project Zomboid Server Settings Guide: servertest.ini Explained

Two configuration layers, one server

A dedicated Project Zomboid server does not read all of its behavior from one file. Configuration is split across several files, and the two you will touch most are:

• servertest.ini, the server-level configuration: who can join and how the server presents itself, networking and public visibility, player and chat behavior, safehouse and faction server options, and the Workshop and mod declarations. This file lives in the server profile folder under the server name your instance runs with.
• The sandbox configuration (SandboxVars), which drives the world simulation itself: zombie population and behavior, loot abundance and respawn, and the rest of the world tuning that decides how the sandbox actually plays. These are sandbox variables, not servertest.ini settings, and they have their own configuration area on the server.

Keeping the layers straight matters in practice: if you toggle a servertest.ini option and the loot economy does not change, the setting was never in that file. Each section below names its layer so you edit the right file the first time.

Two habits separate calm long-term servers from weekly-reset chaos servers, and they apply to both layers:

• Back up the server configuration before batch-editing settings. A bad edit costs you a restart; a bad edit without a backup can cost players months of progress.
• Change a few variables at a time, then restart and playtest. Stacking ten changes at once means you never know which one caused the problem your players report on Friday night.

The settings that actually affect multiplayer play

These groups are the ones players feel in their first session, so review them deliberately instead of accepting every default. The chip on each card tells you which configuration layer owns the option:

Safehouse and faction considerations

The servertest.ini safehouse and faction options decide the mechanics: whether claims exist, what members can allow inside them, and how groups form. On any server where people build long-term, safehouse rules are the number one source of disputes: someone claims the warehouse, someone else raids it, and your admin queue fills up.

Both systems need matching written rules, enforced the same way for everyone. Publish your claim policy (inactivity windows, what happens to abandoned bases, how disputes are judged) before enabling the systems, not after the first fight. The Safehouse Rules Generator drafts that policy, including dispute templates, in a few minutes.

Whitelist and access control

servertest.ini carries the access switches: whether the whitelist is enabled, whether joining players are added to it automatically, and whether the server is open or invite-only. The approval flow around those switches, though, usually lives outside the game entirely: an application, a human review, then access.

That is the model QUESTPAUSE runs: applications and role-gated access happen through the community Discord bot, and the server only admits approved players. It is more work to set up than an open server, and dramatically less work to operate: your mods spend their time playing, not refunding stolen loot.

Settings that meet your mods

Settings and mods are not separate layers: they interact. Two examples from our own worlds:

• Out of the box, joining players see only basic server info. The QP Server Welcome & Rules mod adds configurable welcome, rules, and Discord info for every join, so your access rules reach players without an admin typing them out each time.
• Long-term progression benefits from persistent systems: the QP Survivor Reputation mod tracks survivor progression server-side across the whole life of a world, which pairs naturally with the slow-reset sandbox settings above.

Every QUESTPAUSE mod ships Build 41 and Build 42 support in one Workshop item with no required dependencies, so the mod list and the server configuration stay independent of each other.

Common configuration mistakes

• Editing servertest.ini in the wrong profile folder. Hosting panels and multiple instances each keep their own copy; if your change does nothing after a restart, you probably edited a file the server is not reading.
• Editing the wrong layer. If zombie population or loot respawn will not change no matter what you touch in servertest.ini, it is because those are sandbox variables: the option lives in the sandbox configuration, not this file.
• Skipping the restart. Configuration changes apply on server start, not live.
• Cranking sandbox zombie population on a small host. If the server struggles, population and peek settings in the sandbox configuration are the first suspects.
• Changing safehouse or PvP behavior mid-world without telling players first. These settings are social contracts; announce the change before it lands.
• Hand-editing long settings and mod lines until a typo slips in. Generate them, copy once, and keep a backup of the previous file.

A workflow that survives contact with players

1. 01Decide the community model first: open world, password, or application-gated. Everything else follows from it.
2. 02Start from a preset profile that matches your intent, not from a blank file.
3. 03Adjust the servertest.ini options your players will actually feel: access, pause behavior, PvP, safehouse and faction mechanics.
4. 04Tune the world simulation separately in the sandbox configuration: zombie pressure, loot economy, progression-related sandbox options.
5. 05Generate the server-level block with the Settings Helper, copy it into servertest.ini, and keep the previous version as a backup.
6. 06Restart, join, and check the things you changed, not the whole game.
7. 07Write down what you changed and when. Future-you, debugging at 1am, will need it.

Questions about a specific setting for your world? The QUESTPAUSE Project Zomboid hub links our worlds, mods, and tools, and the community Discord answers server-ops questions from people who run them daily.