Project Zomboid whitelist and accounts

A Project Zomboid server has accounts, not just players. Each person joins with a username and a password of their own, and the server keeps those accounts in a SQLite database at Zomboid/db/<servername>.db. Whether strangers can create an account is decided by one line in the ini: Open=true lets anyone register on first join; Open=false makes the server whitelist-only, so only accounts you created - or that already existed - get in. To close a server cleanly, have your regulars join once, run /addalltowhitelist, set Open=false and restart. To add someone afterwards, run /adduser "name" "password" and hand them the password.

This guide covers how accounts and the whitelist work, every setting involved, adding and removing people, resetting a forgotten password, the Steam ID binding that stops account sharing, permadeath whitelists, and running sign-ups through Discord. The admin account and the command list in general are covered in Project Zomboid admin commands.

Two passwords, and why both exist#

New admins mix these up more than anything else on a Zomboid server.

• The server password is Password= in <servername>.ini. Everybody types the same one in the connect screen. It keeps out people who only found your address, and nothing else.
• The account password belongs to one account. It is set when the account is created - by the player on first join if the server is open, or by you with /adduser if it is not - and it proves that the person logging in as "Bob" is Bob.

A server can use either or both. A server password with Open=true means anyone who knows the shared password can make an account. Open=false without a server password means only listed accounts can join, and the server password adds nothing. Both together is belt and braces, and mainly useful while you are changing from one model to the other.

Where accounts live#

Zomboid/  Server/servertest.ini              Open, Password and the other keys below  db/servertest.db                   accounts: usernames, password hashes, access levels, bans  Saves/Multiplayer/servertest/    players.db                       characters

The database holds the account; the save holds the character. That split has three useful consequences:

• Wiping the world does not wipe accounts. Delete the save and everybody logs in with the same name and password to a fresh world. Project Zomboid server reset goes through the kinds of wipe.
• Deleting the database removes every account, including admin, every access level and every ban. Do it only when you mean to start the roster from scratch.
• Copying the database moves your roster. To set up a second server or move to a new host with the same people, copy db/<servername>.db across, renamed for the new server name. Nobody has to register again.

Back the database up with the save. Losing it does not lose the world, but it does mean re-creating accounts and re-applying every ban from memory.

The ini keys that control access#

Defaults vary slightly by build, and the generated ini comments each key. A few of these deserve more than a line.

AutoCreateUserInWhiteList is for the transition from open to closed. Run the server open for a launch weekend with it on, and everyone who registered is already on the whitelist when you switch Open to false.

MaxAccountsPerUser matters on Steam servers. Accounts are tied to the Steam ID that created them, so a limit of 1 or 2 stops one person registering a stack of alternate accounts to dodge a ban or to hoard. On a friends' server it does not matter; on a public one, set it.

DropOffWhiteListAfterDeath is the permadeath switch, covered below.

Closing a server that is already running#

The common situation: the server ran open for a while, there is a group of regulars, and it is time to stop strangers.

1. Ask everyone who should keep access to log in once, so their account exists.
2. As admin, run /addalltowhitelist. It adds every account the server knows about.
3. Stop the server.
4. Set Open=false in the ini.
5. Start the server, and try to join with a new name to confirm it is refused.

Open=falsePassword=AutoCreateUserInWhiteList=falseMaxAccountsPerUser=1

/addalltowhitelist adds everybody, including the stranger who made an account last night. Look through the account list in the in-game admin panel afterwards and remove anyone who should not be there.

Open is also one of the options /changeoption can set on a running server, followed by /reloadoptions. That is convenient, but write it into the ini as well, so a restart does not quietly reopen the server.

Adding, removing and banning#

The commands, run in the console or in chat as an admin:

/adduser "Bob" "temporary-password-42"/addusertowhitelist "Bob"/removeuserfromwhitelist "Bob"/addalltowhitelist/banuser "Bob" -ip -r "griefing the Muldraugh bakery"/unbanuser "Bob"/banid "76561198012345678"/unbanid "76561198012345678"/setaccesslevel "Bob" "moderator"

Names are account names, not character names, and the quotes matter when a name has a space. On a whitelist server, /adduser is how people get in: create the account, then send them the name and password privately. Tell them to change the password, which a player can do in chat with /changepwd "old" "new" on builds that include it; /help lists the commands your build has.

Banning an account on an open server is easy to evade - the player registers a new name. A ban on the Steam ID is the one that sticks. The Steam ID is in the server's connection logs for every login, which is also how you find it after the fact. Server rules, moderation and staff covers writing bans down and handling appeals.

Steam ID binding and shared accounts#

On a Steam server, an account is bound to the Steam account that first used it. Someone who knows Bob's username and password still cannot log in as Bob from a different Steam account. That is a quiet, useful protection: shared passwords do not lead to shared characters, and a leaked password is less of a disaster than it sounds.

It also explains two support questions. A player who buys the game on a new Steam account cannot use their old Zomboid account without an admin removing it and creating a new one. And brothers sharing a PC with two Steam accounts need two Zomboid accounts.

Servers started with the -nosteam option run without Steam, for players on non-Steam copies of the game. There is no Steam ID to bind to, so the account password is the only protection and /banid has nothing to act on. Use a server password and a whitelist on any non-Steam server that faces the internet.

Resetting a forgotten password#

There is no "forgot password" link. Three ways to fix it, from easiest to most manual.

1. The admin panel. Logged in as admin, the in-game panel has a database view listing accounts, where an admin can change an account's details. This is the quickest route on builds that offer it.
2. Remove and re-create. /removeuserfromwhitelist "Bob", then /adduser "Bob" "new-password". If the server refuses because the name still exists, delete the row directly as in the third method. On Build 41 multiplayer the character is stored separately in the save, linked by account name, so re-creating the same name gets Bob back to his character. Try it on a test account first if your server is modded.
3. The database directly. With the server stopped, the account table can be edited with any SQLite tool. Back up the file first.

$ cp Zomboid/db/servertest.db Zomboid/db/servertest.db.bak$ sqlite3 Zomboid/db/servertest.db ".schema whitelist"$ sqlite3 Zomboid/db/servertest.db "SELECT id, username FROM whitelist;"$ sqlite3 Zomboid/db/servertest.db "DELETE FROM whitelist WHERE username = 'Bob';"

The table holding accounts is called whitelist even on open servers, which surprises people. Read the schema before changing anything; column names have changed between builds, and passwords are stored hashed, so you cannot simply type a new one into the table. Deleting the row and re-creating the account with /adduser is the safe use of direct access.

Permadeath whitelists#

DropOffWhiteListAfterDeath=true removes an account from the whitelist when its character dies. Combined with Open=false, a death means the player is locked out until an admin lets them back in.

Some roleplay and hardcore servers use this to make death matter: every return goes through a staff member, who might require a new character application, a waiting period, or simply a conversation about how it happened. It works best with a clear written policy - how long the wait is, what a new application needs - because otherwise every death becomes a negotiation. It also makes staff availability part of the game: a death at 3am with no staff awake is a locked-out player until morning. Decide whether that is acceptable before switching it on.

Sign-ups through Discord#

Most communities that run whitelists take applications in Discord. The pattern that works:

1. An applications channel, with the questions in a pinned message: name, age if your rules need it, timezone, how they found the server, and agreement to the rules.
2. A staff member reviews it and, if approved, runs /adduser with a generated password.
3. The password goes to the applicant by direct message, never in a public channel, with an instruction to change it.
4. The applicant gets a Discord role, so staff can see at a glance who is whitelisted.

This keeps the whitelist meaningful without much effort. The weakness is the manual step: someone has to run the command. Giving moderators the access level to do it, rather than sharing the admin password, is the right fix - see subusers and least privilege for the general reasoning.

Project Zomboid also has a built-in Discord chat bridge, configured in the ini:

It relays chat between the game and a Discord channel. It does not manage the whitelist or create accounts, and the token is a credential: keep the ini out of screenshots, and if the token ever leaks, regenerate it in the developer portal. Bots that handle applications automatically exist as separate projects; Discord webhooks for server status covers the lighter-weight ways to connect a server and a community.

Troubleshooting#

New players are refused after closing the server. That is the whitelist working. Add them with /adduser.

A whitelisted player cannot join. Check the account name, not the character name. Then check they are using the Steam account the Zomboid account was created with.

The server reopened after a restart. Open was changed with /changeoption but not in the ini file. Set it in the file.

Everyone had to register again. The database was deleted or replaced, or the server is running with a different -servername and a different database. Restore the file from backup.

A banned player keeps coming back. They are making new accounts. Ban the Steam ID with /banid, and set MaxAccountsPerUser.

A player died and cannot rejoin. DropOffWhiteListAfterDeath=true. Re-add them with /addusertowhitelist if your rules allow it.

FAQ#

How do I make a Project Zomboid server whitelist-only?

Set Open=false in the ini and restart. Only accounts that already exist can join. Run /addalltowhitelist first if people have been registering while it was open, and add new people with /adduser.

Where are Project Zomboid accounts stored?

In the SQLite database at Zomboid/db/<servername>.db, in a table named whitelist. Characters are stored separately in the world save, which is why a world wipe does not remove accounts.

Can a player reset their own password?

On builds that include it, /changepwd in chat changes a player's own password if they know the current one. A forgotten password needs an admin.

Do I need a server password if the server is whitelisted?

No. Open=false already restricts who can join. A server password adds a second barrier, which is useful while moving from an open server to a closed one.

Why can my friend not log in on my account from his PC?

Accounts on Steam servers are bound to the Steam account that created them. That is a protection against shared and stolen passwords. Make your friend his own account.

Can I move my player list to a new server?

Yes. Copy Zomboid/db/<servername>.db to the new server, renamed to match its server name if that differs. Accounts, access levels and bans come with it.