A whitelist is the single most effective way to keep a Project Zomboid server private, stop griefers from wandering in, and make sure only the people you invited can spawn into your Knox County save. The whole system hinges on one setting in your servertest.ini file and a small family of admin commands — but the way Project Zomboid handles player accounts is genuinely different from most survival games, and that’s where people get tripped up. This guide walks through exactly how the whitelist works, the difference between an open server and a whitelist-only server, how the per-account password system relates to the server-wide join password, and how to flip an already-running open server over to whitelist-only without locking out your existing players.
Everything here applies to Build 41 (B41.78), which remains the stable default branch on Steam, and carries forward unchanged into the Build 42 unstable branch (opt-in beta as of mid-2026). The whitelist, the config-file layout, the account database, and the admin commands are identical across both builds, so you don’t need to worry about which branch you’re on for this particular task.
How Project Zomboid handles player accounts
Before touching any settings, it helps to understand the account model, because Project Zomboid has two completely separate passwords and confusing them is the most common reason whitelist setups fail.
- The server join password (
Password=inservertest.ini) — a single shared password every player types once to connect to the server at all. It’s empty by default, meaning anyone who can reach the server can attempt to join. - The per-account password — each individual player has their own username and their own password, tied to their character. This is what makes the whitelist work: the server remembers who you are between sessions.
These are independent. A server can have a shared join password, a whitelist, both, or neither. The per-account credentials are what we manage when we build a whitelist. Those accounts (username plus per-account password) live in the server’s player database — the same SQLite store that holds character data — so once an account exists, that player can return to their character on every future login.
Where the configuration lives
A dedicated server is configured by files inside your Zomboid/Server/ folder. On Windows that’s C:\Users\. The default server name is servertest, so the files are named servertest*. There are three core files (PZwiki also lists a fourth, servertest_spawnpoints.lua):
| File | Controls |
|---|---|
servertest.ini | Main server settings: networking/ports, player cap, PVP, passwords, public listing, mod lists, map, spawn point, RCON, anti-cheat — and the Open whitelist toggle. |
servertest_SandboxVars.lua | The world ruleset: zombie population, loot rates, XP multipliers, day length, and (in Build 42) animal/basement/darkness settings. |
servertest_spawnregions.lua | The cities/regions offered on the spawn selection screen. |
For this guide we only need servertest.ini. If you want a full key-by-key breakdown of that file, our companion post on the servertest.ini settings explained goes through every line. You can edit the file in any text editor while the server is stopped, and if the server is already running you can apply changes live with the reloadoptions command rather than restarting.
The Open setting: open vs whitelist-only
The entire whitelist mechanism is controlled by a single boolean key in servertest.ini:
Open=trueOpen=true — an open server
This is the default. When Open=true, any client may join, and an account (username plus password) is automatically created on the player’s first connection and stored in the player database. There’s no manual approval step. The first time a new player connects with a username and chooses a password, that becomes their permanent account. It’s the easiest mode to run, but it means anyone who knows your server address (and your server join password, if you set one) can create an account and play.
Open=false — whitelist-only
Set this and the server becomes whitelist-only:
Open=falseNow accounts are no longer auto-created. An admin must pre-create each account before its owner can log in, and any username that doesn’t already exist in the player database will be refused. This is the locked-down mode you want for a private group, a community with an application process, or any server where you’ve had trouble with uninvited players.
The trade-off is administrative overhead: every new member needs an account created for them. The commands in the next section make that quick.
Creating whitelist accounts with /adduser
The core whitelist command is /adduser. It creates a whitelist account by setting a username and a password for it:
/adduser "PlayerName" "theirPassword"You can run admin commands three ways, depending on where you are:
- In-game chat with a leading
/(you must hold admin access). - In the server console directly — type the command without the
/prefix. - Over RCON — also without the
/prefix.
So in the server console you’d simply type adduser PlayerName theirPassword. The password you set here is that player’s per-account password — the one they’ll type on the connection screen along with their username. Hand each player their username and password (privately), and they’re in. They can usually change it themselves later from the in-game options.
Quotation marks around the username and password are good practice and required if either contains spaces. To remove someone from the whitelist, Project Zomboid provides a removal command — most commonly written as /removeuserfromwhitelist , though some builds and guides use the shorter /removeuser. Because the exact spelling has varied, run /help on your server (or check the current PZwiki Admin commands page) to confirm which form your build accepts before relying on it in a script.
For the full command set — banning, kicking, granting access levels, spawning items — see our dedicated Project Zomboid admin commands reference.
Admin access levels
To run /adduser and other whitelist commands from in-game chat, your account needs admin access. Project Zomboid has five access levels, highest to lowest:
- admin — full control
- moderator
- overseer
- gm (game master)
- observer — lowest
You set a player’s level with:
/setaccesslevel "PlayerName" moderatorUse none as the level to strip a player’s access entirely. The built-in admin account password is set the very first time you run the dedicated server — the console prompts you for it on first launch, so set something memorable and secure. The server console itself always has admin rights, which is why you can manage the whitelist from the console even before any in-game admin exists.
Flipping a live open server to whitelist-only
This is the scenario most server owners actually face: you’ve been running Open=true, you have a group of regulars with characters they care about, and now you want to close the doors to newcomers without forcing your existing players to recreate their characters.
The trick is that on an open server, accounts are only auto-created the first time someone joins. Those accounts already exist in the player database. So the safe migration path is to make sure every regular has connected at least once (so their account is saved), then switch the server to whitelist-only. Here’s the workflow:
- Get everyone online. Ask all your regular players to log in while the server is still
Open=true. The moment they join, their account (username + chosen password) is created and stored in the database. - Capture the connected players into the whitelist. Project Zomboid offers a convenience command, commonly
/addalltowhitelist, which converts every currently-connected player into a whitelist account in one step. This is exactly what it’s designed for — confirm the command on your build with/help, since its availability has varied. If it isn’t present, you can/addusereach player manually instead. - Edit the config. Stop the server (or prepare to hot-reload) and change
Open=truetoOpen=falseinservertest.ini. - Apply the change. Restart the server, or if it’s still running, issue
reloadoptionsin the console to apply the edited.inilive. You can runshowoptionsfirst to confirm the current value before and after.
After the switch, your existing players log in exactly as before with their established username and password, while anyone new is rejected until you create an account for them with /adduser. No characters are lost, because the underlying database rows are untouched — you’re only changing whether the server will create new accounts on the fly.
Where accounts and characters are stored
Both the whitelist accounts and the character data live in the same place: a SQLite database inside your multiplayer save folder.
Zomboid/Saves/Multiplayer//players.db On Windows that’s C:\Users\. Per-player rows live in the NetworkPlayers table inside that file. You normally never touch this directly — the whitelist commands manage it for you. But it’s worth knowing it exists, because it’s the same database you’d open if you ever needed to surgically reset a single broken character.
If you ever do edit players.db by hand, treat it as destructive. Always stop the server and back up the file first. Deleting a player’s row in NetworkPlayers (using a tool like DB Browser for SQLite) zeroes that character permanently — it cannot recover the pre-break state, and a wrong row deletion is irreversible. The full safe procedure is covered in our guide on resetting a broken character without affecting other players. For routine whitelist work, though, you should be using commands, not editing the database.
Whitelist-relevant servertest.ini settings at a glance
These are the keys most directly tied to access control. Defaults are the values Project Zomboid ships with where confirmed.
| Key | Default | What it does |
|---|---|---|
Open | true | true = anyone can join, accounts auto-created; false = whitelist-only. |
Password | empty | Shared server join password — separate from per-account passwords. |
Public | false | Whether the server appears in the in-game public browser. |
PublicName | string | Name shown in the public browser. |
MaxPlayers | 64 (often set to 16/32) | Player cap. |
DefaultPort | 16261 | Primary game port (UDP). The companion port 16262 is assigned automatically. |
RCONPort | 27015 (some templates use 12345) | RCON listen port — only relevant if you manage the whitelist over RCON. |
RCONPassword | empty | RCON password; RCON stays disabled until you set one. |
A note on combining controls: setting a Password= alone gives you a soft gate (anyone with the shared password can still create their own account if Open=true). For real access control, Open=false plus per-account whitelisting is the proper lock. Many private communities run Open=false with no server-wide Password at all, relying entirely on the whitelist.
Managing the whitelist over RCON
If you’d rather not be in-game or watching the console to add players, you can run the same commands through RCON. Set RCONPort (the real-world value is 27015; some host templates use 12345) and a non-empty RCONPassword in servertest.ini, then connect with any RCON client. Send commands without the / prefix — for example adduser PlayerName theirPassword or setaccesslevel PlayerName admin. This is handy for managing access from a web panel or a Discord bot rather than the live console.
Verifying it worked and reading the logs
After flipping to Open=false, the fastest confirmation is to run showoptions in the console and check that Open reads false. To watch connection attempts in real time, look at the live console output file, server-console.txt, which sits in your Zomboid/ folder one level up from Server/. It logs the startup sequence, mod loading, and every player connect and disconnect — so a rejected whitelist attempt will show up there. On restart, older logs are moved into the timestamped Zomboid/Logs/ folder. Our walkthrough on checking Project Zomboid server logs covers which file to open for which problem, including chat and PVP moderation logs.
If you’re configuring all of this on managed hosting, our Project Zomboid documentation shows where the config files and console live in the panel, and you can spin up a ready-to-run box on our Project Zomboid server hosting plans if you’d rather skip the manual SteamCMD setup entirely.
Frequently asked questions
What’s the difference between the server password and the account password?
They’re two different things. The server join password (Password= in servertest.ini, empty by default) is one shared password everyone types to connect to the server. The account password is unique to each player, tied to their username and their character, and stored in the server’s player database. A whitelist is built from per-account credentials — the shared join password is optional and independent.
Do I need Open=false to use a whitelist?
Yes, in the practical sense. While Open=true, accounts are auto-created for anyone who joins, so there’s effectively no gate. Setting Open=false turns the player database into a true whitelist: only usernames that already exist (created by an admin via /adduser) are allowed in, and everyone else is refused.
How do I switch my existing open server to whitelist-only without wiping characters?
Have all your regulars log in once while the server is still Open=true so their accounts get saved, optionally run /addalltowhitelist to capture the currently-connected players in one go, then change Open=true to Open=false in servertest.ini and apply it with reloadoptions (or a restart). Existing characters and accounts are untouched; only new account creation is blocked. Confirm /addalltowhitelist exists on your build with /help, and fall back to manual /adduser calls if it doesn’t.
Does the whitelist work the same in Build 42?
Yes. Build 41 (B41.78) is the stable default and Build 42 is the opt-in unstable branch as of mid-2026, but the Open setting, the three-file config layout, the players.db account database, and the admin commands are identical across both. Note that multiplayer only rejoined the Build 42 unstable branch in late 2025, so verify any other B42-specific behavior against current documentation — but the whitelist itself is unchanged.
Where are the whitelist accounts actually stored?
In the SQLite file Zomboid/Saves/Multiplayer/, in the NetworkPlayers table — the same database that holds character data. You manage it through commands, not by editing the file. If you ever do open it directly (for example to reset a broken character), stop the server and back up players.db first, because row deletions are permanent.
How do I remove someone from the whitelist?
Use the removal command, commonly /removeuserfromwhitelist (some builds use the shorter /removeuser). Because the exact spelling has varied between versions, run /help on your server or check the current PZwiki Admin commands page to confirm which form your build accepts. If you also want to keep them out for good, follow up with a ban using /banuser .
That’s the complete picture: one config key (Open), a handful of account commands led by /adduser, a clear separation between the shared join password and per-account passwords, and a safe migration path for servers that started out open. Set it up once and your Knox County survival run stays exactly as private as you want it.
Ready to play?
Run your own Project Zomboid server with XGamingServer
Spin up an always-on Project Zomboid server your friends can join in minutes — no port-forwarding, no tech headaches.
