Make your Rust server privateServer password, whitelist plugin and bans

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

The simplest way: a server password

Rust comes with a server password. It is set in the server.cfg:

server.password "yourPassword"

After that, the client asks for the password when connecting. Alternatively, your fellow players append it directly to the connect command in the F1 console.

• Advantage: no plugin needed, effective immediately, easy to change.
• Disadvantage: a password everyone knows is quickly passed on - and you do not notice when it happens.
• Note: a server with a password behaves differently in the server list and is not shown at all to many players.

For a fixed group of friends, that is completely sufficient. For a clan server with changing members, it is less suitable.

The clean solution: a whitelist via plugin

Rust has no built-in whitelist like Minecraft. For that, you need a plugin based on Oxide/uMod or Carbon.

A whitelist plugin works with Steam IDs instead of a shared password. That is the decisive difference: access can be granted and revoked individually, without everyone else needing a new password.

• Players are added via their Steam ID - how to find it is explained in Add admins & moderators.
• The list can be maintained while the server is running via the console or RCON.
• After every force wipe, check whether the plugin still matches the current framework version.

The last point is important: a whitelist plugin that does not load after the wipe makes your server public unintentionally - or unreachable, depending on how it fails.

Bans: lock out individuals

For the opposite case - the server is open, but certain individuals should stay out - the built-in tools are enough. Via the console or RCON:

banid <SteamID> "Name" "Reason"
unban <SteamID>
banlistex

The bans are stored on the server side and survive a restart. They also remain in place after a wipe - unlike game progress.

For community servers with several moderators, a plugin that logs bans with reason, duration and the admin who issued them is worth it. Without one, after three months nobody can tell why someone was banned.

Which way fits when?

A practical note for the last case: really remove the password after the testing phase. A forgotten server.password is a common reason why a freshly launched public server stays empty - see also Get listed in the server list.

How your fellow players connect

A private server should be found - but only by the right people. Because a server with server.password set does not appear in the list at all for many players, your group gets in via the direct connection. For that, everyone needs the fixed server address made of IP and port, as shown in the web interface. In the game's F1 console:

client.connect 123.123.123.123:28015

The port is not set in stone: 28015 is the usual starting value, but what counts is always the port number shown in the web interface. The client then asks for the password. Anyone who has been on the server once can find it again via the history in the server browser - the detailed steps, including favorites, are in Connect to the server.

Joining directly has a practical side effect: it works independently of the server list. If you are unsure whether a problem is with the server itself or only with the listing, it is the fastest test. If you get in via IP and port, the server is running perfectly and everything else is a matter for the server list or for Server name & description.

The wipe day checklist for private servers

Access protection via plugin has a weak spot that has nothing to do with the plugin itself: the monthly force wipe. The Rust update overwrites the framework, and until a matching version of Oxide or Carbon is installed, the server runs without plugins - and therefore without a whitelist. These four steps prevent a nasty surprise:

1. Back up the access list first. Depending on the plugin, it lives in its data or configuration file. With us, backups are self-service across the board via WebFTP or SFTP, see Create backups.
2. Set a password until things are cleared. server.password is the fallback that works without a framework - the only access protection that is guaranteed to survive a wipe day.
3. After the update, check whether the plugin is actually loaded - not whether the file is in the folder. The difference decides whether your server is open, see Install & configure plugins.
4. Remove the password again as soon as the whitelist takes effect. Otherwise you have both hurdles at once, and your fellow players face a prompt nobody expects anymore.

And the limit of the method should be said too: a whitelist decides who gets in - not how someone behaves afterwards. Against an invited player who empties the shared box, only kicking them out helps. For that, at least one other person should have moderator rights, so that not every decision depends on you being there.

Frequently asked questions