Rust Server Admin Guide: Assign Access and Recovery Duties

Running a Rust server takes separate control of game roles, plugins, hosting accounts and recovery access. Giving someone an in-game admin role does not settle the other three. This Rust server admin guide helps you create a responsibility register: who can do each job, what proves it worked, and who takes over when that person disappears for the weekend. It covers PC Rust operators, not Console Edition administration. Allow about 30 minutes for the first draft; access tests and recovery drills need their own maintenance window. The result is a working handbook, not proof that every permission or backup is already safe.

Turn this Rust server admin guide into an access register#

Start with the systems people can reach, then assign a named custodian to each. A job title such as “admin” hides too much: the person answering player complaints may have no reason to download backups or change the subscription.

Use the table as a blank inventory. The capabilities are things to check in your deployment, not promises that your host implements each control.

For each row, add the primary person, a substitute, the reason access is needed and the next review trigger. Store references to secrets in an access-controlled password manager; do not paste passwords into the handbook. A register is useful precisely because it can be discussed without distributing every credential.

Separate policy from observation. “Only the owner may wipe the world” is a policy. A helper who can overwrite all server files might still have the practical ability to destroy it. Mark that mismatch as unresolved instead of treating the written rule as enforcement.

Your first check is simple: can another responsible person explain every account in the inventory? Unknown accounts, unexplained bots and inherited access from a former owner need investigation before adding more staff.

Assign duties before granting native or plugin privileges#

Describe the job in ordinary language before choosing the permission mechanism. “Collect evidence and answer appeals” is a different job from “replace plugin files” or “restore the world.” Granting the same access to all three makes mistakes harder to contain.

Native owner and moderator roles are privileged game roles. In our current-build check, the owner command’s help identified authentication level 2 and required that level from its caller; the moderator command’s help explicitly described granting the admin flag. Those observations do not establish a complete per-command permission matrix. Do not assume “moderator” means a narrowly restricted chat helper.

Consider a proposed division of work:

This is a planning example, not a tested permission preset. If your available controls cannot express the intended boundary, reduce the helper’s duties or explicitly accept the wider privilege. Do not disguise broad access with a reassuring group name.

uMod’s permission documentation distinguishes direct permissions, group grants and inheritance. It also documents automatic assignment of recognized native owners to the admin group. The systems can interact even though they have separate records. Review the effective result, not just the membership you last edited.

Keep plugin-specific grants with your plugin register and maintenance owners. A permission that belongs to one extension is not a universal Rust capability, and changing the installed stack can change what your staffing plan actually permits.

Verify role records survive changes and restarts#

Verify both persistent records and real account behavior before treating a role change as complete. A successful console response is useful evidence, but it does not demonstrate everything the affected player can now do.

On September 20, 2026, we checked native role persistence in a disposable Windows server using public build 25353106, protocol 2633.288.1. We used two synthetic identifiers with no connected players. The test added owner and moderator records, restarted, removed both records, and restarted again. Additions and removals were saved without an explicit configuration-save command; the final role file remained empty.

That establishes native record persistence for this test. We did not test authenticated player permissions, a hosting panel, Linux or plugin authorization. The current Facepunch administration instructions likewise document automatic saving and tell players to reconnect for their authentication level to apply. Old instructions that always require a separate save step should not replace a check of your actual build.

For your staff change, retain the server identity, build, timestamp, intended role and reviewer. Inspect the relevant role record, have the affected person reconnect, then test an intended action and an action they must not perform. After a planned restart, repeat the checks that matter to your policy. Do not run destructive actions merely to demonstrate a boundary; use a disposable environment and a harmless, representative test.

If records revert, investigate which identity or management system supplied them. Use the configuration ownership and restart worksheet to identify overrides. Repeatedly granting a role without finding the source of the reversal leaves both administration and revocation unreliable.

Restrict remote console access and preserve another way in#

Treat remote console access as a separate administrative capability with its own custodian. A person’s limited in-game role is not a reason to hand them a powerful console credential.

WebRCON uses a TCP endpoint; game access and browser queries use UDP endpoints. Record the assigned address and port instead of copying a tutorial’s example. Making player connections work does not prove the administrative path is restricted or recoverable.

Use a unique secret for the server and restrict the network route to the operators or private network that need it. Confirm the transport protection provided by your actual setup; do not assume a tool called a “web console” encrypts its connection. Never make credentials public in a troubleshooting screenshot or paste them into a third-party client whose handling you have not checked.

The Facepunch WebRCON project provides a websocket console and notes that its example client remembers passwords locally. Include operator browsers, saved client profiles and automation in your credential inventory. A shared secret is also a poor basis for distinguishing one human operator from another. If a gateway claims individual accounts or action logging, test those features instead of attributing them to the underlying console.

Before rotating a credential, confirm a separate recovery route with the responsible owner. Update the approved clients and bots during a maintenance window, verify the new route works, and confirm the previous credential no longer grants access. Keep the recovery route available until the change is accepted. This is a verification sequence, not a claim that a particular panel provides account delegation.

If remote access fails, preserve the error and endpoint details and use the dedicated-server failure-stage checklist. Broadly opening administrative access while guessing at the cause can create a second problem.

Make moderation decisions reviewable#

A consequential moderation decision should leave a record another person can understand. The goal is to reconstruct what happened, which rule applied and why the action was proportionate, even if the original moderator is unavailable.

For the exact native ban and unban commands, scope boundaries and connected-player behavior, follow this Rust player ban and unban process.

Use a restricted case record with fields like these. This is a proposed team template, not a built-in Rust log format.

Case reference:
Observed time and timezone:
Actor and affected SteamID, restricted to authorized reviewers:
Applicable server rule:
Evidence location and relevant timestamps:
Action taken and reason:
Operator who performed the action:
Independent reviewer and review outcome:
Appeal route and next review date:

Keep original evidence and later interpretations distinguishable. A player report, an operator’s recollection and a timestamped system event are different kinds of evidence. Record contradictions instead of silently editing them away. If the moderator is personally involved in the dispute, assign the review to someone else.

Facepunch’s report documentation describes console reporting and external report delivery, but its notes warn that targeted player reports may not reach the external endpoint. Receiving some reports therefore does not prove that all categories arrive. Test the categories you rely on with an authorized test report and record where each appears.

Player reports also do not establish a complete audit trail of privileged actions. Check what your actual console, panel and plugins record, how an actor is identified, and what happens when logging fails. An absent event can mean missing coverage; it is not automatically proof that an action did not occur.

Report payloads can contain identifiers, machine details and screenshots. Limit access to people reviewing the case, redact public explanations and choose a retention period that fits the community’s needs. Do not keep sensitive records forever merely because storage is cheap. The acceptance check is a second reviewer reconstructing one test case without receiving unrestricted credentials or unrelated players’ data.

Give backup custody an independent recovery path#

A backup helps during an access failure only if an authorized person can retrieve and use it. If the only copy and its credentials sit behind the same inaccessible owner account, the backup custodian has an unresolved dependency.

If you suspect unauthorized access or tampering, follow this Rust server compromise response runbook before choosing what to restore. Preserve the affected copy and close the suspected access path separately from the world recovery.

1. Identify the recovery set and its custodian

   Inventory the active identity, world and player data, configuration, installed extensions and required secrets. Record what each backup includes, where it is stored, who may retrieve it and which software versions it expects. Refer to the actual file inventory rather than assuming one archive contains every dependency.

2. Have the delegate retrieve an approved copy

   Use the documented recovery route without borrowing the owner’s personal login. Check that required decryption material and account recovery instructions are available through approved custody. Record missing access before a real outage forces rushed decisions.

3. Restore in isolation and record acceptance

   Follow the deployment’s restoration procedure at a separate destination. Verify the intended world, required progress and appropriate client access; check permissions as well as data. Prevent the test instance from impersonating the production service. Record failures and the person responsible for resolving them.

Use the Rust data-management recovery record to define the consistent file set and the checks appropriate to your server. A delegate locating an archive is one milestone; proving a usable restoration is another. Do not mark the second complete from the first.

Finally, specify who may authorize a production restore and who communicates the expected loss window to players. That decision should not fall accidentally to whoever happens to possess the archive. Review the drill after changes to the host, identity, authentication, plugins or backup process.

Finish onboarding, offboarding and ownership handover#

Make every staffing change a review of the complete access register. Adding or removing one native role is only one line of that work.

For departure, identify credentials the person knew as well as accounts bearing their name. Review direct plugin grants and inherited groups, stored client credentials, bot tokens, file-transfer accounts and active sessions using each system’s supported controls. Rotate shared secrets where needed, then verify that remaining operators and necessary automation still work. Do not assume a role removal terminates unrelated sessions or revokes access elsewhere.

For handover, keep a list of unresolved items with an owner and deadline. A missing export, an untested recovery address or an unavailable second administrator remains pending; a friendly verbal handoff does not resolve it. The outgoing owner should not be the only person capable of explaining the new owner’s recovery procedure.

Self-hosting can work well if your group can maintain these responsibilities and provide backup coverage. If that operational burden is why you are considering Rust PC hosting, ask which delegated controls, file access and support responsibilities the selected service actually provides. We have not verified Game Hosting panel roles or audit coverage here; a hosting subscription alone does not establish either.

Use the hosting comparison and purchase checklist to turn those requirements into questions before paying. Your final check is practical: with the usual owner unavailable, can the named substitute handle an ordinary incident through approved access, and can you review what they did afterward?