Add a Rust admin & moderatorownerid and moderatorid via SteamID64

Published on August 4, 2026 · last updated on November 8, 2026

Auth levels: owner vs. moderator

Rust knows two permission levels:

• ownerid (auth level 2): Full admin rights, including all F1 console commands, server convars and kick/ban.
• moderatorid (auth level 1): Moderation rights (kick, ban, teleport, noclip and more), but no access to security-critical server convars.

For yourself as the server operator, ownerid is the right choice; for helpers on your team, it is usually moderatorid.

Find the SteamID64

You need the 17-digit SteamID64 (it starts with 7656119…) of the player in question. You can look it up on services such as steamid.io or steamidfinder.com by entering the Steam profile. The name in quotation marks is only there for your own overview - what counts is the ID.

Add an admin or moderator via the console

Enter the commands in the server console (web interface) or in-game in the F1 console - as an owner who already has the rights:

ownerid 76561198XXXXXXXXX "YourName" "Server owner"
moderatorid 76561198YYYYYYYYY "Helper" "Moderator"
server.writecfg

server.writecfg matters: only this command writes the entries permanently to users.cfg so they survive a restart. The player in question then has to reconnect for the rights to take effect.

Revoke rights

To remove someone, use the counterpart commands and save again:

removeowner 76561198XXXXXXXXX
removemoderator 76561198YYYYYYYYY
server.writecfg

Alternatively, you can manage admins comfortably in users.cfg via FTP/SFTP or with admin menu plugins that offer groups and permissions.

server.writecfg: the step everyone forgets

At first, Rust only keeps admin rights in memory. Without server.writecfg, they are gone after the next restart - and since Rust servers usually restart several times a day, you notice that quickly.

ownerid 76561198XXXXXXXXX "Name" "Server owner"
server.writecfg

The command writes the list to users.cfg in the server directory, and Rust reads it from there on every start. If you add many admins at once, you can also edit the file directly via WebFTP or SFTP - but only while the server is stopped, otherwise Rust overwrites your changes at the next writecfg.

The same goes for bans: they only end up permanently in bans.cfg with server.writecfg. A ban that does not survive a restart is the most common reason why someone is "back on the server again".

Owner or moderator - what you should grant

The difference is bigger than the two terms suggest, and it determines how much trust you hand out:

• Owner (auth level 2) can do everything: fly, spawn items, shut down the server, change the configuration. This level belongs to you and at most one person you trust without reservation.
• Moderator (auth level 1) can kick and ban players, manage the chat and switch to spectator mode - but cannot spawn items or touch the server configuration. That is the right level for any moderation team.

When in doubt, grant moderator. An owner who accidentally interferes with the game using admin tools damages a community's trust more lastingly than a missing ban. If you want finer control - for example, rights per command - you need a permission system via Oxide or Carbon.

Admin rights do not take effect

In that case, it is almost always one of these three points:

1. Wrong SteamID. Rust needs the SteamID64 - a 17-digit number that starts with 7656. The display name or a custom URL does not work. For connected players, status returns the correct ID.
2. No reconnect. The rights only take effect once the player in question leaves the server and joins again.
3. No writecfg. See above - without this command, the entry was only temporary.

If you send the commands via WebRCON, pay attention to the quotation marks: name and note each need their own pair, otherwise Rust reads the command differently than intended.

Frequently asked questions