Rust Server Admin Commands and How to Use Them (PC Dedicated Servers)

On a PC Rust dedicated server, you become an administrator by granting your SteamID64 an owner or moderator auth level from the server console or RCON, then reconnecting. Owners (auth level 2) have full administrative access; moderators (auth level 1) have the lower permission tier. Once authenticated, you can use the in-game F1 console for player moderation, teleportation, testing, world controls and server maintenance. This guide lists the practical commands, explains where each one works, and shows how to avoid the most common permission and syntax mistakes.

The examples cover the PC dedicated-server command model. Rust Console Edition uses different permission names and should not be administered with these PC commands.

What are Rust admin commands, and where can I run them?

Rust admin commands are server-console instructions that let an authorized operator manage players, inspect entities, test a build, change the environment and control server operations. They are available through three interfaces, but the interfaces do not have identical authority.

• Dedicated-server console: The local console has server authority and is the safest place to grant owner or moderator access and run high-impact controls.
• RCON: A separate remote-console program connects directly to the server so you can monitor it and send commands without being in the game. A documented example uses server port 28015 over UDP and RCON port 28016 over TCP; these are example defaults, so verify the ports configured by your host.
• In-game F1 console: An authenticated owner or moderator can open F1 and issue commands while connected. Commands intended only for the server console can sometimes be run from F1 by adding the sv prefix, such as sv say or sv quit.

Command availability and spelling can change with Rust updates. If you know only part of a command, use find [text] in the live console to search the server’s current command list.

What must be ready before you administer a server?

You need a running PC dedicated server, access to its local console or an authenticated RCON account, and the SteamID64 of each person who should receive access. A self-hosted machine also needs the CPU, RAM, disk space, network connectivity, open server and RCON ports, and a working configuration. A managed Rust server supplies much of that infrastructure, but you still need to confirm which ports, console method, backups and RCON options the provider actually gives you. Do not assume that every host uses the documented example ports.

Keep the RCON endpoint and password private. RCON is remote control of the live server, not merely a chat tool: a leaked credential can be used to grant ownership, ban players, change the world or shut down the process. Limit access to trusted staff, use the host’s secure connection options, and remove credentials from screenshots and public logs.

How do I make myself admin on a Rust server?

Use the running server console or an authenticated RCON session. You need the player’s SteamID64, not merely the display name.

1. Run users. The server prints connected players and their SteamID64 values.
2. Grant full owner access with ownerid <SteamID64> "Name". Owner is auth level 2.
3. For the lower permission tier, run moderatorid <SteamID64> "Name". Moderator is auth level 1.
4. Disconnect from the server and reconnect. Facepunch’s instruction is that you must reconnect after adding a player to receive the auth level.

Owner and moderator changes are saved automatically. You do not need server.writecfg merely to make the permission change persist; that command is for writing server convars and settings to configuration files.

How do I remove an administrator?

Run removeowner <SteamID64> to remove owner access or removemoderator <SteamID64> to remove moderator access. Have the player reconnect after a change so the session reflects the new authorization state.

What if I do not know a player’s SteamID64?

Use users for connected users. status and players also expose identifiers; players includes the name and ping, which is useful when several players have similar names. For moderation, prefer the SteamID64 whenever a command accepts it because names can be ambiguous.

What is the difference between owner, moderator and an ordinary player?

Level	How it is granted	Practical meaning
Ordinary player	No auth command	Cannot use protected administrative commands.
Moderator (auth level 1)	moderatorid <SteamID64> "Name"	Lower administrative tier for approved staff.
Owner (auth level 2)	ownerid <SteamID64> "Name"	Full owner-level administrative access.

Grant the least privilege that fits the job. A helper who only needs to handle chat or routine moderation does not necessarily need owner access. Keep the server console or RCON credentials restricted because anyone who can run these commands can affect players and the world.

The distinction is operational, not cosmetic. Give the primary operator owner access, then use moderator access for trusted helpers whose duties are narrower. When a staff member leaves, remove the relevant ID rather than leaving an unused account authorized. After changing a person’s status, have that person reconnect; an already-open game session may continue to behave as though its old authorization is still active.

Which commands manage players and bans?

Identify the player first, then use a SteamID64 where possible. Quote a name or reason whenever it contains spaces.

Command	Example	What it does
status	status	Shows connected players and identifiers before moderation.
players	players	Lists connected players with SteamID64, name and ping.
kick	kick <SteamID64-or-name> "reason"	Removes a player; the player can rejoin.
ban	ban <SteamID64> "name" "reason" <duration>	Bans an online player, optionally for a specified duration.
banid	banid <SteamID64> "name" "reason" <duration>	Bans by SteamID64, including a player who is offline.
banlistex / bans	banlistex	Reviews bans and their recorded reasons.
unban	unban <SteamID64>	Lifts a ban.
mute / unmute	mute <SteamID64-or-name>	Applies or removes a chat mute; behavior can differ between local use and admin use.

Kick, ban, banid or mute: which should I choose?

Use kick for a temporary removal while you investigate; it does not prevent a later rejoin. Use ban for an online account when a persistent or timed restriction is justified. Use banid when the player is offline or when you want to act explicitly on the SteamID64 rather than a potentially ambiguous name. Use mute for chat behavior rather than removing the player from the server. Review the resulting record with banlistex, and use unban with the same SteamID64 if an appeal is upheld.

How do timed bans work?

Use the duration argument in the documented value-plus-unit format. The command reference supports units such as months, days and minutes; enter the value and unit exactly as the live server’s help output specifies. If a ban fails, run find ban and check the command’s current syntax rather than guessing a unit or omitting quotation marks around the reason.

Why should I avoid names for serious moderation?

Two players can have similar or changing names, while a SteamID64 uniquely identifies the account. A reliable workflow is to run players or status, copy the correct ID, and then use kick, banid, unban or mute commands with that identifier.

How do noclip, god and teleport work?

These commands affect the issuing administrator or immediately move a targeted player. Test them privately before using them during a live wipe.

Command	Example	Use
noclip	noclip	Toggles flight and collision bypass for the administrator.
god	god true / god false	Enables or disables damage, hunger and thirst immunity for the issuing player.
teleport	teleport <name-or-ID>	Teleports yourself to a player. With two arguments, it can move one player to another.
teleport2me	teleport2me <name-or-ID>	Brings a player to your position.
teleportpos	teleportpos "x, y, z"	Teleports to the supplied coordinates.
teleportlos	teleportlos	Teleports to the closest object in your line of sight.

Because teleportation and invulnerability can disrupt a raid, event or wipe economy, announce staff interventions in advance when your server rules require transparency. Noclip can also let an administrator pass through structures, so reserve it for inspection and support rather than ordinary play.

Remember which commands affect only you and which can move another player. god and noclip change the issuing administrator’s state; teleport2me changes another player’s position; the two-argument form of teleport can move one player to another. Confirm the target before pressing Enter, especially when using a name instead of an ID.

How do I spawn items, entities and inspect buildings?

Use the crosshair-based tools while looking directly at the target or surface.

Command	Example	Use
spawnitem	spawnitem <item>	Spawns an item where you are looking.
spawn	spawn <entity>	Spawns an entity where you are looking.
debug.lookingat	debug.lookingat	Reports the prefab or entity under the crosshair.
ent who	ent who	Returns the SteamID64 of the player who placed the targeted entity.

These tools can alter inventories, add entities and affect a player’s build immediately. Use a private test server for experiments, and take a world backup or schedule a save before destructive testing when your hosting setup supports it.

A practical inspection sequence is to reach the site with teleport or teleportpos, aim at the suspicious object, run debug.lookingat, and then run ent who if you need the placing player’s SteamID64. Turn noclip off when the inspection is complete. Spawning items or entities on a live server can change inventories and the build immediately, so reserve those commands for testing, events or an explicitly announced intervention.

Which commands change time, weather and decay?

World controls change conditions for everyone connected to the server, so use them during maintenance or an announced event.

Command	Example	Use
env.time	env.time 12	Sets the server’s time of day.
env.progesstime	env.progesstime false	Pauses or resumes time progression. The command is spelled progesstime in the documented command name.
weather.load	weather.load clear	Loads a named weather state.
decay.scale	decay.scale 0	Sets the decay multiplier; the official table lists 1 as the default.
sv say	sv say "Server message"	Broadcasts a message from the server.
server.save	server.save	Saves the world immediately where supported by the server command set.
restart	restart 60 "Restarting"	Schedules a restart with a countdown where supported.
perf	perf 1	Displays FPS and performance information to the issuing player.

Setting decay.scale 0 disables the decay multiplier rather than merely slowing it. Restore the value your rules require after an event, and verify the current convar help because command behavior can change between Rust updates.

Use sv say to explain a restart, weather event or other server-wide change before players are surprised by it. A command such as env.progesstime false can leave the world frozen until it is switched back, and a decay value of zero can change the expected upkeep of every base. Record the original setting before changing it and restore it after the event.

How do I use the F1 console correctly?

1. Confirm that your SteamID64 was granted owner or moderator access from the server console or RCON.
2. Disconnect and reconnect; without this step, the game session may still have ordinary-player permissions.
3. Join the server and press F1 to open the client console.
4. Enter a low-risk check such as perf 1 or use find teleport to confirm that commands are available.
5. Run the required command, preserving quotation marks around names, messages and reasons that contain spaces.

If a command works in the server console but not in F1, try the sv prefix for a server-only command. For example, sv say "Server message" sends a server broadcast. Do not assume every console command can be exposed safely to clients.

Common syntax pitfalls

Place arguments in the documented order. A quoted name or reason is one argument even when it contains spaces; leaving out the quotation marks can shift every later argument. Use the exact spelling shown by the live server, including the unusual env.progesstime spelling. For coordinates, retain the comma-separated format shown by the command help. If you are unsure whether a command is available to an authenticated client, search with find and run it from the server console instead of repeatedly guessing in F1.

What should I do when an admin command does not work?

• Permission error: Verify the exact SteamID64, confirm that you used ownerid or moderatorid, and reconnect. Authorization is applied to the new session.
• Unknown command: Run find with part of the command name. Rust updates can rename, remove or alter commands.
• Arguments rejected: Check the live help output, use the required order, and quote multi-word names, messages and reasons.
• Wrong target: Replace a display name with the SteamID64 from users, status or players.
• Command works only in the server console: Run it there or try the documented sv prefix from an authenticated F1 console.
• Unexpected world change: Review the command you ran, restore the intended convar or weather state, and notify players if the change affected gameplay.

Keep a short, server-specific runbook containing your RCON address, the authorized SteamID64 list, backup procedure and restart window. Never publish RCON credentials in chat or paste them into screenshots.

If a host’s control panel hides the local console, ask whether it exposes RCON and which TCP port it has assigned. A provider may use a port other than the documented example, and a firewall or incorrect protocol can make a valid command client appear broken. Test connectivity with a harmless read-only command such as players before attempting a restart or world change.

What are useful admin workflows for a new server?

Initial access setup

1. Start the dedicated server and connect through its local console or RCON.
2. Run users after joining so you can copy the correct SteamID64.
3. Grant owner access to the primary operator and moderator access to trusted helpers.
4. Reconnect each account and test with find or a harmless inspection command.

Handling a rule violation

1. Run players or status and identify the account by SteamID64.
2. Use kick for a temporary removal while you investigate.
3. Use banid for an offline or persistent account action, including a clear quoted reason and the documented duration format when appropriate.
4. Check banlistex to confirm the record, and use unban if an appeal is upheld.

Inspecting a suspected exploit or build

1. Move to the location with teleport or teleportpos.
2. Use debug.lookingat to identify the targeted prefab.
3. Use ent who to identify who placed the entity.
4. Use noclip only for inspection, then toggle it off before returning to normal play.

Preparing for a restart or event

1. Save the world with server.save where that command is supported.
2. Announce the change with sv say, including the reason and the countdown if you are scheduling a restart.
3. Record current time, weather and decay settings before changing them.
4. Run the event controls, then restore the recorded values and tell players when normal rules resume.

Self-hosted or managed server: what changes?

The command syntax is the same PC dedicated-server model, but the route to the console differs. With a self-hosted machine, you manage CPU, RAM, disk space, networking, firewall rules and configuration yourself. With a managed Rust server, the provider generally supplies the machine and a control panel, while you pay for the service and must verify its RCON, backup, port and restart features. There is no universal price to quote because plans and resource allocations vary; compare the resources, storage, port access and support you actually need rather than choosing on branding alone.

In either arrangement, keep an independent copy of important configuration and know how to reach the console if the game is unavailable. RCON is particularly useful for a remote operator, but it should be restricted just like a local console account.

Are these commands the same in Rust Console Edition?

No. This article’s commands apply to Rust on PC with a dedicated server. Console Edition community-server documentation uses a different authorization model with permission names such as global.god, global.teleport, global.spectate and global.vanish, assigned through different permission levels.

Do not paste PC commands such as ownerid, moderatorid or server.writecfg into a Console Edition workflow and expect the same result. Check the documentation for your exact platform and server type before granting access.

Frequently Asked Questions

Can I become a Rust server admin without joining the game?

Yes. Use the dedicated-server console or an authenticated RCON connection to grant your SteamID64 owner or moderator access. You still need to disconnect and reconnect to the game before the new auth level is applied.

Does Rust save owner and moderator permissions automatically?

Yes. Current server documentation says owner and moderator changes are saved automatically. The separate server.writecfg command writes server convars and settings, so it is not required just to persist an auth grant.

Why does my admin command work in RCON but not in the F1 console?

Some commands are designed for the server console only. If the command supports client use, prefix it with sv; otherwise run it from the dedicated-server console or RCON.

What is the safest identifier to use when banning someone?

Use the player’s SteamID64 from users, status or players. Names can be ambiguous, while the SteamID64 remains the reliable account identifier for commands such as banid and unban.

What is the difference between kick and ban?

kick removes the player temporarily and allows a later rejoin. ban or banid records a restriction, optionally with a duration, and banlistex lets you review the record.

Do I need to run server.writecfg after using ownerid?

No. Owner and moderator grants are saved automatically. Use server.writecfg when you need to write server convars or settings to configuration files, not as a required step for an auth change.

Why does env.progesstime look misspelled?

The documented command name is env.progesstime. Rust command names can be unusual and can change, so use find progesstime and the live help output to confirm the spelling on your server.

Can I use these commands on Rust Console Edition?

No. Console Edition uses a different permission model and names such as global.god, global.teleport, global.spectate and global.vanish. Follow documentation for that platform instead.

What should I check before using a high-impact command?

Confirm the target SteamID64, check the current syntax with find, save or back up the world when possible, and announce changes that affect everyone. Test spawning, teleportation and environment changes on a private server when practical.

The Bottom Line

For PC Rust dedicated servers, grant access with ownerid or moderatorid from the server console or RCON, then reconnect. Use SteamID64 values, verify syntax with find, and reserve teleport, spawning, god, weather, decay and restart controls for controlled, clearly communicated administration.