A Rust dedicated server is configured with console variables (convars) such as server.hostname or server.worldsize. You can set them in three places: on the start line, in a server.cfg file, or live from the console or RCON. This guide covers the convars that matter when you set up a server, their defaults, which place wins when two disagree, where the save files live, how map and blueprint wipes work, custom maps, Oxide plugins, and which ports to forward.
Which version this covers. Everything here was checked against Facepunch's own server documentation on wiki.facepunch.com/rust and the official Oxide documentation, and on a real server: the October 2026 build (Steam build 25681086), installed with SteamCMD (app 258550, anonymous login) on Linux. Where we write "in our test", we started that server and looked at what it did. Rust changes every month, so a default can move; the find command in the server console prints any convar's current value.
The server program is RustDedicated.exe on Windows and RustDedicated on Linux. Facepunch's server guide starts it like this (one line):
Two kinds of arguments are mixed here. Ones that start with - (-batchmode, -logfile) are program options: -batchmode runs the server without a window and -logfile writes the console output to a file. Ones that start with + set a convar. Values with spaces need quotes.
The defaults below are what our test server reported when the setting was not given. "Not checked" means we did not read that default on a real server, so we don't state one.
| Convar | Default | What it does |
|---|---|---|
| +server.hostname "My server" | not checked | The name in the server browser. |
| +server.identity "server1" | my_server_identity | The name of the folder that holds this server's saves and config files (see below). Give each server on one install its own identity. |
| +server.port 28015 | 28015 | The game port players connect to. UDP. |
| +server.queryport 28017 | 0 (automatic) | The port the server browser queries, UDP. If you don't set it, it is one above whichever is higher, server.port or rcon.port. It can't be the same port as server.port. |
| +rcon.port 28016 | same as server.port |
The remote-admin (RCON) port, TCP. In our test, with no rcon.port given, RCON listened on TCP 28015. |
| +rcon.password "..." | – | The RCON password. Set a long one if you set any. |
| +rcon.web 1 | 1 | 1 is WebSocket RCON, 0 is the old Source-engine RCON, which the server's own help text calls deprecated. |
| +app.port 28082 | port + 67 | The Rust+ companion port, TCP: server.port + 67 or rcon.port + 67, whichever is higher. Must be 10000 or higher. |
| +server.level "Procedural Map" | Procedural Map | The map type. In our test, Barren and HapisIsland no longer load ("Failed to load level"). For anything other than a generated map, use a custom map (below). |
| +server.seed 1234 | 1337 | The seed the map is generated from, 0 to 2147483647. The same seed and size give the same map. |
| +server.worldsize 4000 | 4500 | The map's edge length in metres. Facepunch suggests 1000 to 6000. A bigger map needs more memory and disk. |
| +server.maxplayers 10 | not checked | How many players can be connected at once. |
| +server.saveinterval 600 | 600 | Seconds between automatic saves (10 minutes). |
| +server.tickrate 10 | 10 | Server simulation ticks per second. Higher costs more CPU. |
| +server.description "..." | No server description has been provided. |
The text on the server's info panel. |
| +server.url "https://..." | empty | A website link on the info panel. Optional. |
| +server.headerimage "https://..." | empty | A banner image shown for the server. Optional. |
Two more you will see in many start lines: +server.ip (the address to listen on; by default all addresses) and +server.gamemode. Facepunch's game-modes page warns against setting vanilla: leave server.gamemode empty for normal Rust.
Facepunch's advice is to keep only the essentials, such as ports and RCON, on the start line and put everything else in a server.cfg file. It lives in the identity's cfg folder, server/<identity>/cfg/server.cfg, which you create yourself. One convar per line, with no +:
The server reads server.cfg when it starts, and the console command server.readcfg reads it again while the server runs. The server never writes to it, so your edits stay.
server.cfg takes priority over the command line. That's not what we saw: with server.hostname and server.maxplayers set in both places, the server started with the start-line values. Running server.readcfg afterwards switched them to the server.cfg values, and a setting that was only in server.cfg applied at startup as expected. The safe rule: set each convar in one place only.
Next to it the server keeps its own file, serverauto.cfg. In our test it was created at the first start and held about 400 gameplay convars with their current values. The server writes that file itself, so put your own settings in server.cfg. Some convars only work live: Facepunch notes that the weather _chance convars must be set while the server is running, from the console or RCON.
Everything a server keeps lives in server/<identity>/ inside the server's install folder. Without +server.identity that's server/my_server_identity/. After a short run of our test server (identity guidetest, size 1000, seed 12345) the folder held:
Read the save file's name as proceduralmap.<size>.<seed>.<save version>.sav. The .db files are SQLite databases; each one has a -wal journal file next to it, and the two belong together. The server keeps older saves as .sav.1, .sav.2 (server.savebackupcount, default 2).
The two numbers in the names matter. In our build, the world and most player data carry save version 289, but the blueprint file carries 18. Facepunch's server notes explain why: the number goes up when a forced wipe needs it, so the server starts a new file and ignores the old one. A forced map wipe raises the world's number; blueprints only reset when their own number changes or you delete the file.
Keep companion.id with your server and its backups. Facepunch's Rust+ page says it is your server's identity in the Rust+ app; delete it and a new one is made, and players have to pair again.
Find a player's SteamID64 with the users command, then give the rank from the server console or RCON:
ownerid is the full admin rank, moderatorid the lower one. The player has to reconnect to get it. There is no need to save: in our test the line was in cfg/users.cfg right away, in this format:
The last quoted field is a note. You can also add these lines to users.cfg by hand, but Facepunch says to do that only while the server is stopped. Bans go to cfg/bans.cfg. On a Linux server the console doesn't take typed commands, so you do this over RCON.
| Wipe | What resets | What stays |
|---|---|---|
| Map wipe | The world: every base, item and entity. Players start fresh on a new (or the same) map. | Learned blueprints, admins, bans, Rust+ pairings, your config. |
| Blueprint wipe | Every player's learned blueprints, so the tech tree starts over. | Usually done together with a map wipe. |
Facepunch releases the monthly update on the first Thursday of the month. Recent ones came out on Thursday 1 October, 3 September and 6 August 2026. The update raises the save version, so every server's world starts over: that is the forced wipe. Facepunch gives the time as 19:00 London time (for example "January Patch + wipe released on January 1st @ 1900GMT"), and the server's wipe timer, which drives the in-game countdown and the end-of-wipe events, defaults to the first Thursday at 19:00 Europe/London.
A forced wipe usually resets the map only. Blueprints carry over unless the update also resets them or you wipe them yourself. In its November 2025 update notes Facepunch wrote that most servers, its own included, don't wipe blueprints, and that month the update did ("Today, we're wiping all Blueprints"). Read each month's update notes before wipe day.
If your server wipes on a different schedule, the wipe timer can follow it: wipetimer.wipedayofweek (0 = Sunday, default 4 = Thursday), wipetimer.wipehourofday (default 19), wipetimer.wipetimezone (default Europe/London), or wipetimer.wipecronoverride / wipetimer.wipeunixtimestampoverride for anything else. The printwipe command shows the result.
quit command (console or RCON). In our test it wrote a final save before it exited.proceduralmap.*.sav file and its .sav.1, .sav.2 backups. Or change server.seed or server.worldsize: the save name contains both, so the server starts a new world and leaves the old file alone. In our test, changing the seed did exactly that.player.blueprints.*.db and its -wal file.cfg folder (admins, bans, server.cfg) and companion.id.app_update 258550), and reinstall Oxide if you use it (below)..sav to get around a forced wipe dangerous and ill-advised. After the update the server simply looks for a file with the new save version and starts a fresh world.
To run a custom map, start the server with +server.levelurl "https://.../my.map" and remove +server.worldsize and +server.seed, which only apply to generated maps. According to Facepunch's custom-map page:
file:///path/to/your.map URL works for testing, but other players can't connect.
Oxide is the modding framework most Rust server plugins are written for; plugins are single C# .cs files. In short, from the Oxide documentation:
Oxide.Rust.zip for Windows, Oxide.Rust-linux.zip for Linux. The zip holds a RustDedicated_Data folder; extract it over the server's install folder and overwrite the files.oxide.version in the console shows that Oxide loaded..cs files into oxide/plugins. Oxide compiles and loads them automatically, also while the server runs. Plugin settings appear as oxide/config/<Plugin>.json; after editing one, run oxide.reload <Plugin>.
A common setup is +server.port 28015 +rcon.port 28016. In our test, that server listened on:
| Port | Protocol | What for |
|---|---|---|
| 28015 | UDP | Game (server.port). Players need this one to connect. |
| 28016 | TCP | RCON (rcon.port) |
| 28017 | UDP | Server-browser queries (server.queryport, automatic: the higher of the two ports + 1) |
| 28083 | TCP | Rust+ companion app (app.port, automatic: the higher of the two ports + 67) |
If you don't set rcon.port at all, RCON shares 28015 (on TCP), the query port becomes 28016 and the Rust+ port 28082. Facepunch's guide: forward the game port first and get that working; the game and query ports both have to be reachable for the server to appear in the server browser; RCON and Rust+ are optional. For Rust+, the server also needs to reach companion-rust.facepunch.com, and if its connectivity test fails it turns Rust+ off and logs "Rust+ companion server connectivity test failed! Disabling Rust+ features."
Only forward RCON if you need to administer from outside your network. WebSocket RCON is a plain ws:// connection; our test client connected without any encryption, so the password crosses the network in the clear.
The save file name contains the size and the seed. Change either and the server generates a new map and starts an empty world; the old one is still on disk but no longer loaded. Change them only when you mean to wipe.
Blueprints live in their own file with their own version number. Deleting the .sav or changing the seed leaves everyone's blueprints as they were. Delete player.blueprints.*.db and its -wal file for a blueprint wipe.
After the monthly update the server looks for a save with the new version and starts a new world. Your old world can't be loaded, and renaming the file to fool it is what Facepunch warns against.
In our test the start line won at startup, contrary to Facepunch's guide, and server.readcfg flipped it to the file's value later. Set each convar in one place.
+rcon.web 0 switches to Source-engine RCON, which the server calls deprecated. Keep rcon.web 1, and use a WebSocket RCON client.
Facepunch says not to use vanilla: leave the convar empty for normal Rust. Switching game mode during a wipe resets all players and their inventories, with no way back.
The Rust+ backend can't reach a companion port under 10000, and the connectivity test then switches Rust+ off.
A SteamCMD update puts the vanilla files back. Reinstall the matching Oxide release after every update, or your plugins silently stop loading.
A link to a download page instead of the file itself makes the map download fail. And if the host goes offline, new players can't join.
The identity folder holds saves, admins and bans. Two servers on one install with the same server.identity use the same files; give each its own.
NodeMesh runs your Rust server on your own PC or server, and its Config tab sets the start-line convars for you as form fields: server name, description, website, header image and browser tags; map size and seed; PvE mode, game mode (normal, softcore or hardcore) and max team size; radiation, building stability, fall damage, global chat, the player-list privacy setting and idle kick; tick rate and save interval; decay scale and upkeep period; twig frame lifetime; and the RCON port and password. Fields that start a new map say so. You save, then restart from the same page.
The Mods tab searches umod.org plugins and installs them into oxide/plugins. The first plugin you install sets up Oxide after one confirmation, and NodeMesh puts Oxide back after every Rust update, so the pitfall above doesn't apply. Plugins on the Mods tab need a Linux host.
NodeMesh doesn't change server.identity, so the saves and cfg/users.cfg are in server/my_server_identity inside the server's folder.
Host Rust on your own hardware. NodeMesh's Config tab sets the convars, and its Mods tab installs Oxide plugins.
Start hosting with NodeMesh