How to add an admin to your Rust server

The two admin roles

Granting a player admin access on your Rust server lets them run every admin command in game: banning, muting, kicking, teleporting and the rest. There are two roles, and the only difference between them is who else they can promote.

That distinction is the entire security model, so it is worth taking seriously. An ownerid can promote themselves a friend, or remove you. A moderatorid cannot. For everyone who is not you or a co-owner, moderatorid is the right answer.

Adding an admin

1. Open your RCON client

   Connect to your server with an RCON tool. If you do not have one yet, our Rust server admin tools guide compares the free and paid options.

2. Run the command

   The syntax is three parts, space separated:

   (ROLE) (STEAM64ID) (REASON/NAME)

   Replace each part:

   • (ROLE) with ownerid or moderatorid.
   • (STEAM64ID) with the player's 64-bit Steam ID.
   • (REASON/NAME) with their username, or a note about why they have it.

   In practice:

   ownerid 76561198000000000 "Alex"

3. Check the confirmation

   Press enter and the console returns a message telling you whether the assignment succeeded or failed. Read it rather than assuming: a mistyped Steam ID fails quietly enough to be missed.

4. Save with writecfg

   Run:

   writecfg

   This writes the change to the server config. Skip it and the admin is gone at the next restart.

Finding a Steam 64 ID

The command needs the 64-bit Steam ID, which is a 17 digit number beginning 7656119. It is not the player's display name and it is not their custom profile URL.

Two reliable ways to get it:

• From your RCON client. The connected players list shows the Steam 64 ID next to each name. This is the easiest route when the person is currently online.
• From a Steam ID lookup site. Paste their profile URL in and it returns the 64-bit ID. Useful for adding someone before they have ever joined.

Why writecfg matters

Rust holds admin changes made over RCON in memory. They take effect immediately, which is why it looks like the job is done, but they are not written to disk until you tell them to be.

The result is a specific and confusing failure: the admin works perfectly all evening, the server restarts overnight, and in the morning they have no permissions and nobody can explain why. There is no error, because nothing went wrong. It was simply never saved.

Make writecfg a habit after every permission change, including removals. It costs nothing and it is the difference between a change and a temporary one.

Removing an admin

Same pattern in reverse, matched to the role they hold:

removeowner 76561198000000000
removemoderator 76561198000000000

Then writecfg again. This one catches people out more than the addition does, because an unsaved removal means a person you deliberately demoted quietly regains full access at the next restart.

Who to actually give it to

The technical part is one command. The part that causes problems is the decision behind it.

Start with moderatorid

Almost nobody needs to manage the admin list. Give ownerid only to people who would still be running the server if you disappeared.

Record why

Use the name field for something meaningful. Six months later, "Sam, mod since July" is more use than a bare Steam ID.

Review it periodically

Admin lists accumulate. Anyone who has not played for months should not still be able to teleport into a base.

Remove promptly

When someone steps back from the team, demote them the same day rather than when you next think of it.

For what those permissions actually let people do once granted, our Rust server admin commands guide lists the full set.