Project Zomboid Server Password: Set and Rotate Access
Rotate a Project Zomboid server password safely, separate player and admin credentials, and verify which values work before sharing access.
You will need
- Permission to manage the active server configuration
- A private way to contact the people who should keep access
- An authorized client connection for post-change checks
A Project Zomboid server password is a shared admission setting, not the same thing as a player’s account password or an administrator’s RCON secret. The official API lists a server-level password option and a separate rconPassword, while the server record also has player accounts. It does not specify a universal settings path, when every host applies a change, or what happens to players already connected. Use the current procedure for your server, then test new, previous, and deliberately wrong values before sending the replacement to your group.
Separate the shared server password from other credentials#
First decide which secret you intend to change. Project Zomboid’s ServerOptions API declares a string option named password and a separate string option named rconPassword. The Server API models account records separately from the server’s password-protection state, and the Account API lists player account fields. Those references identify different roles; they do not provide a password-rotation walkthrough.
| Credential or control | What it applies to | Keep it separate from |
|---|---|---|
| Shared server password | The server-level password option used for admission | A player’s account and an administrator login |
| Player account | The account record a player uses on the server | The shared admission secret and RCON |
| RCON password | Remote console access when the operator has configured it | Ordinary player access |
People sometimes choose the same text for two different fields. That does not make the fields interchangeable. Change only the shared server option when you mean to rotate group admission; do not alter account records or RCON while following a join-password checklist.
If a player is seeing “Wrong Server Password Given” or a similar rejection, start with the credential-role diagnostic. It helps establish which credential or connection stage is involved. This page covers the next task: changing the shared server value after the owner has decided a rotation is appropriate.
Decide who should keep access before changing anything#
Write down who should receive the replacement and who should no longer be admitted. Do this before editing settings so the person who controls the server can coordinate the change. A shared secret is convenient for a private group, but it does not identify each person who knows it.
Choose a cutover time when the owner can check the server and reach retained members. If someone must lose access urgently, do not assume a password change will disconnect that person or invalidate every saved account. Check who is online and use the current server’s supported account or moderation controls for individual access decisions. The official documentation cited here does not establish one universal active-session outcome.
Record the facts needed to recognize the intended server: its current build and branch, server name, and the profile or settings source that the operator normally manages. Keep the actual password out of this note. The goal is to coordinate one change on one server without confusing a similarly named profile or changing an administrator credential by mistake.
Confirm the active settings source and its apply method#
The game exposes a password server option, but the official API does not tell every operator where to edit it. A self-hosted server, a provider panel, and a host-managed settings file can have different control paths. Use the current instructions for the environment that actually runs your world. Do not copy a file path from another provider or edit a second profile just because it has a familiar name.
If you are unsure which profile is active, use the server INI and profile checks before editing. If you already know the active settings source, record its name and the host’s documented apply or restart procedure. The current 42.21 Stable release confirms the current branch baseline, but it does not describe a password field path or a restart rule.
Before you touch the setting, check that you can recover the existing configuration through your normal backup process. A password edit is not a reason to copy, rename, or migrate the world. If your provider generates settings from a control panel, follow that provider’s current instructions rather than editing a file that the panel may overwrite. If you cannot identify the active source, stop and ask the person who manages the server.
Replace only the shared value through the supported control#
Use the control that owns the active server setting. Change the server-level password value only; leave the player account list, administrator account, RCON option, profile name, and world settings alone. Do not paste credentials into a public support ticket, stream, screenshot, or group channel while doing the edit. Public discovery text is separate from admission access; use the server name and description guide for a listing update, and never include a credential in public copy.
There is no verified universal menu path, filename, or restart timing to give every Project Zomboid operator. If the current procedure for your server says to stop it before editing, stop it. If it says to use a panel field, use that field and confirm it saved. If it specifies a restart or another apply action, follow that instruction and wait for the server’s normal ready state before asking anyone to reconnect. The exact steps belong to the current host or installation, not a path copied from an unrelated setup.
Keep the old value private until the change is verified. Do not include it in a public log or before-and-after screenshot. If the control rejects the value, silently restores the previous setting, or shows a different active profile, pause rather than repeatedly editing multiple files. Record the visible error without the secret, return to the host’s documented settings path, and make sure you are changing the source the running server reads.
Test new, previous, and incorrect values with fresh connections#
Saving a value proves only that the settings source contains it. It does not show that the running server applied it or that a fresh player connection accepts the intended value. The official API describes the option but does not publish an acceptance matrix, so treat the checks below as tests for the server owner to perform, not results this guide claims to have observed.
| Fresh connection attempt | What to record | What the result tells you |
|---|---|---|
| The intended new shared value | Whether the authorized test player reaches the expected next join stage | Whether the new value appears to work for this tested route |
| The previous shared value | Whether it is accepted or rejected | Whether the old value still works for this tested fresh connection |
| A deliberately incorrect value | The exact response, without saving or sharing the value | Whether this attempt is rejected and what message the client shows |
| The player’s own account credentials | Check separately through the normal account flow | Whether account access is distinct from the shared server setting |
Use a fresh connection attempt after the server’s documented apply action; a saved favorite or already authenticated session may not prove which value was checked. Test only with an authorized account and a safe plan for reconnecting. Do not ask a former member to try the old password, and never record any of the passwords in the result table. Note the server name, build, branch, time, and whether each attempt was fresh.
If the new value is rejected, stop distributing it. Reconfirm the active profile and apply procedure, then compare the error with the wrong-password diagnostic. If the old value still succeeds, record that fact and investigate whether the server loaded the intended source; do not tell the group that the rotation worked until you can verify it.
Check online players and individual access separately#
A fresh-connection test and an existing session answer different questions. The current official references do not say whether a password change automatically removes connected players, so do not promise that it does. Check the operator’s live player list before the cutover and confirm the result afterward using the controls available to that server.
If a specific player must be removed, handle that as an individual access action through the server’s supported account or moderation workflow. Rotating a shared value can be part of a group-wide change, but it is not proof that a particular account was removed, an active session ended, or a saved player credential stopped working. Keep any account approval or whitelist policy separate and verify it using the current server procedure.
The same caution applies to players who are already connected when the owner changes a setting. If the result matters for an immediate removal, plan and verify the session action separately instead of relying on an undocumented side effect. Afterward, the owner can compare the online roster with the group list and tell retained members what they need to do next.
Share the replacement privately and keep a redacted record#
Send the new shared value only to the people who should retain access, through a private channel the group already uses. Tell them which server entry to use and when the change was applied. Do not send the value with a public server description or attach a complete .ini file; settings files can contain other credentials.
Keep a short record with the date, time zone, server name, build and branch, settings source changed, and the result of each fresh-connection check. Record “accepted” or “rejected” without recording the secret itself. Note separately whether online players were checked and whether an individual access action was needed. This lets another operator understand what was verified without being handed the credentials.
For a rotation meant to invalidate the previous shared secret, call it complete only after an authorized fresh connection works with the new value and the previous value is rejected. If either result differs, keep the new instruction private, revisit the active settings source, and ask the host or server operator to resolve the apply issue.
Quick answers
Is the Project Zomboid server password the same as my player password?
No. The game documents a server-level password option separately from player account records. Do not assume changing one resets the other.
Does changing the server password disconnect players who are already online?
The current official API does not describe that behavior. Check the connected-player list and test your own server before relying on a rotation to remove an active player.
Do I have to restart a Project Zomboid server after changing its password?
There is no universal restart instruction in the official API. Follow the current procedure for your server or host, then verify with fresh connections.
Can I use a password to remove one former player?
A shared password affects group admission, not an individual access decision. Check account, approval, and active-session controls separately.