Running a Rust server

Rust is one of the heaviest games you can self-host. It wants a fast CPU core and a lot of memory, and both demands grow through a wipe cycle as players build. Everything else about running one, the hardware you buy, the backups you take, and the night you set aside each month, follows from that cycle.

What a Rust server needs

The server binary is RustDedicated, a headless Unity build that Facepunch publishes free through SteamCMD. It runs on 64-bit Linux and needs no Rust licence of its own. See Installing a Rust server on Linux for the build.

Memory is the constraint most people hit first. Usage is not a fixed number you can look up: it scales with map size, player count, and the number of entities players have placed. A server that sits comfortably in memory on wipe day, with an empty map, can be a very different machine two weeks later when that map is covered in bases. Size the server for the end of a wipe cycle, not the start of one.

Measure it rather than guessing. On the server:

free -h
systemctl status rust

Watch the resident memory of the RustDedicated process across a full cycle and you will have a real number for your map size and population.

CPU matters differently. The main game loop is largely single-threaded, so one fast core does more for Rust than several slow ones. Entity count is what drives it, which is the same thing that drives memory: a busy late-wipe map with thousands of deployables and a lot of decay processing is far more work than a fresh one. If your server starts stuttering in week two on hardware that was fine in week one, that is the pattern, and it is normal.

Disk holds a large install plus a save file that grows with the map. Keep room for the install, the save, and at least one copy of the save you took yourself before a wipe.

The wipe cycle shapes everything

A wipe deletes server-side state so the world starts over. Rust is built around this happening regularly, which is why it drives the rest of your planning.

Facepunch ships a mandatory update on the first Thursday of each month. That update changes the network protocol, so clients update and old clients cannot connect, and the existing save does not carry across it. Every server on the game wipes its map that day, including yours. The exact hour the build lands moves around, so watch your server console and Facepunch's own announcement on the day rather than scheduling to a fixed clock.

Between forced wipes, the schedule is yours. Weekly, biweekly, and monthly-only are all common, and players choose servers partly on that schedule, which is why so many Rust server names carry it.

Three practical consequences:

• Your maintenance window is fixed for you. The first Thursday is when Rust updates, when Oxide or Carbon needs updating behind it, and when plugins break. Plan any other work you were going to do for the same evening.
• Population is a sawtooth. Peak load is the hours after a wipe. If your server is going to fall over, that is when.
• Backups matter most in the hour before you delete anything. Take your own copy of the save directory before every wipe, not after.

Wiping a Rust server covers exactly which files to delete for a map wipe and for a blueprint wipe, and in what order.

Ports

Set the query port explicitly in your start script instead of relying on whatever the default derives to. Rust answers Steam's server queries there, and if the port your server actually uses is not the one you opened, the server disappears from the in-game server list even though players who type the address in by hand still connect fine. That symptom is common enough to be worth recognising on sight.

RCON is the remote console. It is how admin tools, Discord bots, and web panels talk to the server, and it is a plain administrative channel, so treat it like SSH: a long password, and the port restricted to the addresses that need it.

To open these on a Clouduxe server, add a rule per port and protocol under Port rules. The Rust entry under Game presets opens the game port and RCON for you in one action; a query port and Rust+ need rules of their own on top.

Vanilla versus modded

Vanilla is the server as Facepunch ships it. No framework, no plugins, and an update is one SteamCMD command. If you do not need custom rules, kits, or admin plugins, this is much less work to run.

Oxide, also known as uMod, is the long-standing plugin framework. You extract it over the top of an existing Rust install, where it patches the game's managed assemblies so plugins can hook game events. Plugins are single .cs files you drop into the framework's plugins directory, and it compiles and loads them at runtime, so most changes do not need a restart. Config and stored plugin data sit in sibling directories next to it.

Carbon is a newer alternative that runs most Oxide-format plugins. It hooks the game through its own loader rather than by rewriting the shipped assemblies, which changes how you start the server. Install it from the project's own instructions, since its boot path is what makes it work.

Whichever you pick:

• Run one, never both. They patch the same game and will fight.
• Update order is Rust, then the framework, then start. Both frameworks are built against a specific Rust build. Start a freshly updated server before its framework has caught up and plugins fail to load or the server does not boot at all. This is the single most common reason a Rust server is down on the first Thursday of the month.
• Assume plugins break on update day and keep the list of what you run short. Every plugin is another thing that can fail after a Facepunch patch.
• Modded costs more. Plugins add memory and CPU on top of the base game.

Related