To admit only an agreed group, control admission with Open=false, maintain individual player accounts, and set a separate joining password if you want a shared extra barrier. Public=false changes discovery; it does not make a reachable server private.
This guide covers an existing Steam-enabled dedicated server. As of 26 October 2026, the developer lists Build 42.21 as Stable. Build 41 installations kept on legacy41 have older account behaviour, so keep the settings generated by your actual build rather than replacing them with an old template. The in-game Host/invite workflow is outside this procedure.
Separate the four access decisions#
| Layer | What it controls | What it does not establish |
|---|---|---|
Public | Listing in the game's public browser | Who can authenticate through a known address |
Password | A shared joining secret | Which individual player account is approved |
Open and whitelist | Admission of player identities/accounts | Administrator privileges |
| Account access level | Administrative powers after authentication | Permission for everybody who knows the join password |
A server can be absent from a browser and still accept direct connections. A player who knows the joining password can still fail account authentication. An approved player should normally remain an ordinary player.
Edit the settings used by the running instance#
Record the operating-system user, its home, the launch command, the selected -servername, and any explicit -cachedir. A default layout uses Zomboid/Server/<servername>.ini under that user's home. A custom data root changes where you must look. Editing your SSH user's servertest.ini will achieve nothing if a service runs another named instance.
Arrange a short maintenance window. Save and quit through the existing server console, wait for the process to finish, and take an independent copy of the entire persistent Zomboid root, including account databases, settings and multiplayer saves. Preserve the current working administrator login. Do not delete the account database to “clear the whitelist”: that can discard credentials, roles and identity associations.
Edit these existing keys in the selected .ini:
Public=false
Open=false
Password=REPLACE_WITH_A_UNIQUE_JOIN_SECRET
Replace the marker before starting. The join password is stored in configuration, so restrict file access to the service account and authorised operators. Keep the account login password different from this shared secret.
If the file generated by your build contains AutoCreateUserInWhiteList, its historical purpose is automatic enrolment on an open server. AutoCreateUserInWhiteList=false by itself is not a closed-server policy. Do not add legacy keys absent from your current settings or open admission temporarily to get a whitelist populated. Also inspect DropOffWhiteListAfterDeath: an intentional account-removal policy can prevent an approved player from returning after death.
Restart through the existing supervisor. If a panel regenerates configuration at startup, change its corresponding setting too; inspect the resulting file after launch before assuming your edit survived.
Add player accounts through the supported interface#
Use the server's local console or its existing authorised administration interface. Start with help and confirm the account commands offered by that build. The ordinary username/password creation command is:
adduser "PLAYER_LOGIN" "REPLACE_WITH_A_UNIQUE_ACCOUNT_SECRET"
Replace both markers and run the command once for each approved account. This is a server-console command, not a Linux shell command. In authenticated administrator chat, commands have a leading /; the local console form above does not. A secret typed here may remain in console logs, panel history or transcripts, so use a private operator session and protect retained logs.
Give each player their own server login and password privately. The login is not automatically their Steam display name or character's first and last name. Preserve an existing login when the player expects an existing character: inventing a replacement account is not a repair for a rejected password.
Build 42 also has Steam identity admission state. Keep that distinct from username records, particularly after migrating a Build 41 account database. A historical developer-support thread initially discussed required Steam IDs, but its author later reported that new adduser accounts worked; the affected entries were old migrated ones. It does not justify running both account and SteamID commands for every new player.
If logs specifically identify a Steam identity rejection, confirm the player's actual SteamID64 and inspect the current build's help/administration tools for its Steam allowlist controls, including addsteamid where available. Repair only the identified entry and retest. Do not paste somebody's profile nickname into an identity field, hand-edit SQLite tables, or import an old database schema as a general solution. Servers running without Steam need their own identity procedure.
Verify admission without sharing administrator access#
Keep at least one trusted administrator route working throughout the change. Adding a whitelist account does not require making that account an administrator. Use a separate staff login if someone actually needs moderation tools; never distribute the existing administrator credentials to the whole group.
Test both sides of the policy:
- An approved ordinary account joins using its own credentials and the correct shared secret, then reconnects after a restart.
- An unapproved identity is denied even when it knows the shared joining password. Do not test this using an already allowed Steam identity or an administrator account.
- A wrong shared secret is rejected before normal play begins.
- An existing player returns to the expected character and world.
A connection timeout calls for network checks; a version mismatch calls for matching client/server builds. Neither is a reason to set Open=true. If a rejected account is the only symptom, compare the exact login, identity and loaded instance before changing wider settings.
For a group maintaining its own VPS, Nexardo can help organise infrastructure administration; whitelist rules and in-game acceptance still need checking in the actual Project Zomboid instance.
