Project Zomboid admin & server commandsAdmin password, access roles & RCON

Published on August 4, 2026 · last updated on October 21, 2026

The admin account

At the first start of the server, you set an admin password (with us via the server setup in the panel). The associated username admin has full rights. If you log in in the game with these credentials, you get access to the admin menu and all server commands.

Further admins & roles

You appoint further players in the chat with /setaccesslevel:

/setaccesslevel "PlayerName" admin

Besides admin, there are graded roles such as moderator, overseer, gm and observer - that way, you give your team exactly the rights it needs without sharing the admin password.

What matters is what the role is tied to: the server account, not the Steam account. Every player creates their own username with a password on the server when they first join - see Join a server. If you assign a role, it applies to exactly this name. If someone later logs in under a new name, they are an ordinary player again and you assign the role once more. So write down which account name belongs to which person; with a team of several moderators, that saves a surprising amount of back and forth - and it prevents someone from using the admin account after all out of convenience.

Important chat commands

• /kickuser / /banuser - remove or ban players.
• /additem / /addvehicle - spawn items or vehicles.
• /save - save the world manually.
• /players - show connected players.
• /quit - shut the server down cleanly (saves first).

Remote control via RCON

For management without being in the game, you activate RCON in servertest.ini via RCONPort and RCONPassword. Management tools and Discord bots then connect through it to send commands, save the server or schedule restarts. The server commands are the same as in the chat, just without the leading slash.

The detailed setup including the choice of client and error patterns is described under Set up & connect RCON.

The roles at a glance

Project Zomboid grades rights more finely than most servers make use of. Moderators rarely need full access - and a team without the admin password is considerably more relaxed to manage:

The role is stored per account and is kept across restarts. You can take it back with /setaccesslevel "PlayerName" none.

In practice: the three most common cases

A player has built themselves in or is stuck in the map. The quickest solution is a teleport instead of a rescue mission:

/teleport "PlayerName" "TargetPlayer"
/godmode "PlayerName" true

Something has been lost. With /additem, you give items back - for that, you need the internal item name, not the displayed one:

/additem "PlayerName" "Base.Axe"

The server should restart. Use /save, then /quit. The way via the panel alone is more convenient, but /quit writes the state away cleanly - especially important before you work on mods or the SandboxVars.

Everything you risk in the process calls for a backup: backups are self-service with us throughout, you fetch the save folder via WebFTP or SFTP, see Create backups.

In the game or remotely?

Both ways send largely the same commands - in the chat with a leading slash, via RCON without. Even so, they are not equivalent, and the distinction decides which way you choose in which situation:

• In the game, you have a character, a position and a field of view. Only then do commands make sense that refer to your location: bring someone to you, check on the spot what is left of a base, hand over an item directly. You also see immediately whether the measure has worked.
• Remotely, you do not need to start the game. That pays off for everything that concerns the server as a whole - saving, announcing, shutting down - and when you are sitting at a computer without the game installed. But the console has no character in the world: you always have to name targets here.

For daily moderation, the way in the game is therefore usually the faster one and the one with fewer mistakes. Remote control pays off where regularity is called for - for example with announced restarts at fixed times. How to set it up, which tools are suitable and which error patterns occur is explained under Set up & connect RCON. One point should be kept in mind: remote access knows no roles. Whoever has it has everything - so it does not replace graded permissions, but stands next to them.

Handling incidents without blowing up the group

The tools are quickly explained; the order is what really matters. On a server where characters die and bases represent weeks of work, a wrong decision weighs heavily. This sequence has proven itself:

1. Look instead of believing. Two contradicting accounts are best cleared up with your own eyes. That is exactly what the more reserved roles are for: observe without intervening and without the whole server immediately noticing that moderation is happening.
2. Talk to them. A message in the chat resolves more cases than you would expect - much of it is a misunderstanding about agreements, not ill intent.
3. Separate. /kickuser ends the connection, nothing more. Whoever wants to is back seconds later. It is meant as a pause for thought, not as a punishment.
4. Ban. /banuser is the last step. The ban survives restarts and can be lifted later - both belong in the announcement when you issue it.

What none of these measures achieves is repairing the damage done. A demolished base stays demolished. For that, you need a backup - and this is where it pays off that Project Zomboid stores world and player data separately: you can bring back yesterday's world state without taking their characters away from everyone involved. The procedure for this is under Create backups.

And if someone still cannot get in after a ban has been lifted, it is usually not the ban at all. Different mods, a different build or a full server all look the same to the person affected - the order for narrowing it down is under Fix connection problems.

Frequently asked questions