Rust is one of the most demanding games you can host. A busy server is simulating a large procedural map, hundreds of player-built bases, every deployable inside them and a full plugin stack, all at once. When a Rust server struggles, it usually struggles on wipe day, exactly when your player count peaks. Getting it right comes down to enough memory, the right framework for your plugins and a sensible wipe routine. This guide covers all three, then shows how to get a server online on GGHOST Cloud.
How a Rust dedicated server works
The Rust dedicated server is a separate program from the game client, downloaded through SteamCMD. It generates the map from a seed and a world size, loads it into memory and then keeps track of everything players build, place and drop. Each server has an identity folder under server/, which holds the saved map, the player blueprint database and the cfg folder with server.cfg.
Two things make Rust different from most survival games:
- Entity count grows all wipe. Every wall, door, box and turret is an entity. A fresh map is light; the same map three weeks later can be several times heavier.
- Facepunch ships a forced update once a month, on the first Thursday. It requires a server update and a map wipe, and it routinely breaks plugins until their authors catch up.
How much RAM does a Rust server need?
Memory is what decides whether your server stays smooth late in a wipe. These are the figures we size Rust servers at:
- Up to 50 players, Vanilla or a light plugin set: 8 GB. A community server with a handful of quality-of-life plugins runs comfortably here.
- 50 to 150 players, a typical modded server: 16 GB. This is where most modded community servers sit.
- 150+ players, a large map with a heavy plugin stack: 32 GB. Big maps and long plugin lists both need headroom.
Map size, player count and the number of plugins all push memory up, and so does how long it has been since the last wipe. Watch the memory graph in the panel in the days before a wipe: if it sits above about 80% at peak, size up; if it never passes half, you have room to spare.
On GGHOST Cloud you pay for memory, not player slots.
server.maxplayersis a setting you choose, not a line on the invoice.
Vanilla, Oxide or Carbon
We support three builds of the Rust server. You choose the build in the panel and can change it later with a restart.
Vanilla
The server exactly as Facepunch ships it. Choose it if you want a true vanilla experience that plays exactly like official servers. You can still adjust the map, seed and server settings, but no plugins run.
Oxide / uMod
Oxide (distributed through uMod) is the long-standing modding framework for Rust and has the largest plugin library: kits, teleports, clans, economy, zone management, admin tools and many more. Plugins are .cs files that go in oxide/plugins; their settings are created in oxide/config and any stored data in oxide/data.
Carbon
Carbon is a newer framework built with performance in mind. It loads most Oxide plugins, and its plugins go in carbon/plugins. If you are starting fresh and your plugin list is supported on Carbon, it is worth testing.
Settings that matter most
Rust settings are console variables. Startup settings are set as server flags; you can also put them in server.cfg in your identity’s cfg folder, which you can edit from the panel’s file manager.
server.hostnameandserver.description: what players see in the server browser. Add a clear wipe schedule to the description; it is the first thing Rust players look for.server.worldsizeandserver.seed: the size and layout of the procedural map. A larger map spreads players out but costs more memory and takes longer to generate. Pick a seed and size before wipe day and keep them in your notes.server.maxplayers: set it to what your memory can serve late in a wipe, not on day one.server.saveinterval: how often the world is saved. Saving very frequently on a large map causes noticeable hitches; leave it at a sensible interval rather than lowering it aggressively.
To make yourself an admin, run ownerid <your SteamID64> in the panel console, then server.writecfg so it persists across restarts.
Wipes: planning them properly
Wipes are part of Rust’s design, and a predictable schedule is one of the strongest reasons players return to a server.
- Pick a rhythm and publish it. Weekly, fortnightly or monthly map wipes are all common. Every server must wipe on the monthly forced update anyway, so plan around that date.
- Separate map and blueprint wipes. A map wipe removes the saved map from the identity folder. A blueprint wipe also removes the player blueprint database. Many servers blueprint wipe only on forced wipe day.
- Use the panel scheduler. A scheduled task can announce the wipe, restart the server and run your wipe routine on time, so nobody has to be online at the exact minute.
- Expect plugins to break on forced update day. Update the framework, then check the console for plugins that fail to compile. Remove or replace any that have not been updated yet.
Plugins: installing them safely
Upload plugins through the panel’s file manager or over SFTP into the framework’s plugins folder. Oxide and Carbon load new or changed plugins automatically, so you can watch the console to see whether each one compiles. A few habits help:
- Add plugins one at a time on a live server, so you know which one caused an error.
- Keep an eye on server performance after each addition. A badly written plugin that runs every tick costs more than a dozen well-written ones.
- Back up
oxide/configandoxide/data(or Carbon’s equivalent) before updates. That is where your kits, permissions and economy balances live.
Backups and saves
Your map, blueprint data and plugin data are all files, so they are all covered by backups. On GGHOST Cloud, backups run on a schedule you set and restore from the panel without a ticket. A daily backup plus a manual one before every wipe and every forced update is a good routine. If you are moving from another host, upload your identity folder and framework folders over SFTP and you can carry on the current wipe.
Launching your Rust server on GGHOST Cloud
- Pick a plan on the Rust page: choose the memory from the sizing above and the region closest to your players. Singapore and Europe (France–Germany border) are live today, with the United States (East, Central and West), the United Kingdom, India, Japan and Australia available on demand.
- Check out. Where a node in your region has room the server is created within seconds; in regions where we add capacity for you it is usually ready within 2 hours (24 hours at most).
- Set your options in the panel: build (Vanilla, Oxide or Carbon), hostname, world size, seed and max players. Then start the server and let it generate the map.
- Share the address. The address and port are shown in the panel. Players press F1 in Rust and type
client.connectfollowed by the address.
From there you have our Pterodactyl panel: a live console, file manager, SFTP, scheduled tasks for restarts, wipes and announcements, sub-users for your admins, and database access for plugins that need one. Every node is behind DDoS protection from our network providers, on every plan. There is no setup fee and no contract, and if something breaks you talk to the people who run the servers, on Discord or at hello@gghost.cloud.
The short version
Start at 8 GB for a community server and 16 GB once you run a full plugin stack. Pick Oxide for the widest plugin choice or Carbon if your plugins support it, publish a wipe schedule that lines up with the monthly forced update, add plugins one at a time, and back up before every wipe. Do those things and wipe day becomes the busiest day on your server rather than the day it falls over.
