How to Host a Rust Server and Manage Wipes: Complete Guide
Quick answer
To host a Rust server, download RustDedicated with SteamCMD (app ID 258550) or rent a managed server, then launch it with a server.identity, a world size from 1000 to 6000, a seed, max players, a hostname and RCON settings; players join on UDP port 28015 by default. Add Oxide or Carbon for plugins. The monthly update forces a map wipe on the first Thursday of each month. To wipe manually, stop the server and delete the .sav and .map files, plus the player.blueprints files for a blueprint wipe.
What do you need to host a Rust server?
You need the Rust dedicated server files, a machine that stays online, and enough RAM for the map size and player count you plan to run. The server software is free: Facepunch distributes it through SteamCMD under app ID 258550 for both Windows and Linux, and players join with their normal copy of Rust. The executable is called RustDedicated, and the world is controlled through startup parameters and console variables rather than a settings menu.
Hardware priorities differ from most games. Rust simulates the entire world, every wall, door, box, NPC and dropped item, and much of that work runs on a single main thread, so strong single-core CPU performance keeps server FPS stable. Memory use starts at several gigabytes on a mid-size map and climbs as players build. Fast NVMe storage shortens world saves and startup, which you will notice on busy servers that save at regular intervals.
- SteamCMD and the Rust dedicated server, app ID 258550
- Game port 28015 over UDP (server.port)
- An RCON port over TCP, 28016 in Facepunch's example
- A query port, which defaults to one above the higher of the game and RCON ports
- At least 8 GB of RAM, more for large maps and busy servers
- Your SteamID64, so you can make yourself owner
How do server identity and the folder structure work?
The server.identity parameter names a folder, and everything that belongs to one world lives inside it, under the server directory. Launch with +server.identity my_server and Rust creates server/my_server, holding the save files, the map file, the player databases and a cfg folder. Change the identity and you get a completely separate world, which is handy for running a test copy next to your live server.
Inside the identity folder, files ending in .sav are the world save, with numbered backups kept beside the newest one, and the .map file is the generated terrain. Blueprint progress lives in files starting with player.blueprints, while other player databases hold data such as identities and states. The cfg folder contains server.cfg for your console variables, users.cfg for owners and moderators, and bans.cfg. Facepunch notes that the server never writes to server.cfg itself, so your edits there stick.
Which startup parameters matter most?
Rust reads its settings from the command line at launch, with each console variable prefixed by a plus sign, and the same variables can go into cfg/server.cfg without the plus. A typical Windows launch starts with RustDedicated.exe -batchmode followed by the parameters in the table below; on Linux the binary is simply RustDedicated. Values that shape the world, such as size, seed and level, are read before the map is generated, so keep them on the startup line.
Two settings need extra care. Leave server.gamemode empty for standard gameplay: Facepunch's wiki advises against setting it to vanilla explicitly and warns never to switch game modes mid-wipe, because doing so resets all players and their inventories with no way back. And fill in server.tags honestly. Players filter the browser by wipe schedule, difficulty, game type and region, the list includes Oxide and Carbon markers for modded servers, and you may pick only one tag per group.
| Parameter | What it controls | Example or note |
|---|---|---|
| server.identity | Folder name for this world's saves and configs | my_server; a new identity means a new world |
| server.port | Game port players connect to (UDP) | 28015 by default |
| server.level | Map type | Procedural Map, the standard generated map |
| server.worldsize | Length of one side of the map in meters | 1000 to 6000; bigger needs more RAM and disk |
| server.seed | Seed for map generation | Any number from 0 to 2147483647 |
| server.maxplayers | Maximum concurrent players | Match it to your RAM and map size |
| server.hostname | Name in the server browser | Stating wipe day and style helps players choose |
| server.description / server.url / server.headerimage | Connection-screen text, website and banner image | URL and image are optional |
| rcon.port / rcon.password / rcon.web | Remote console access | Use rcon.web 1 and a long, unique password |
| server.tags | Server browser filter tags | For example monthly and vanilla; one tag per group |
How do you choose the world size and seed?
Pick the world size from your expected player count, not your ambitions: a map that is too big for its population feels empty and wastes RAM. Facepunch accepts values from 1000 to 6000, and the size decides how many monuments and resources fit on the island. Smaller community servers are usually happiest around 3000 to 3500, while high-population servers go to 4000 and beyond. The RAM table further down ties sizes to player counts and memory.
The seed is any number from 0 to 2147483647, and together with the size it determines the terrain, so the same seed and size produce the same layout on the same game version. Community map preview websites let you inspect a seed before committing a whole wipe to it, which helps you avoid islands with awkward monument spacing. For a hand-made custom map, host the .map file at a direct download link and point server.levelurl at it instead of using a seed.
Oxide (uMod) or Carbon: which modding framework should you use?
Oxide, distributed through uMod, is the long-established framework, while Carbon is a newer, self-updating loader built on Harmony that runs most Oxide plugins unchanged. Both load plugins written in C#, and you should install only one of them. Choose Oxide if you want the most widely documented option; choose Carbon if you value a built-in in-game management interface, its own permission and user system, and automatic updates.
With Oxide, you extract the release for your server's operating system over the server files, which creates an oxide folder with plugins, config, data and lang subfolders. Drop a plugin's .cs file into oxide/plugins and it compiles and loads automatically; edit its JSON file in oxide/config and run oxide.reload with the plugin name to apply changes. Every Rust update replaces game files, so Oxide must be reinstalled after each patch, including forced wipe day, or your plugins quietly stop loading.
Permissions follow the same logic on both. On Oxide, oxide.grant user gives a permission to one SteamID, oxide.grant group admin applies it to a group, and oxide.usergroup add puts a player into a group. Carbon offers equivalent commands and lets you manage permissions from its in-game panel as well. Check each plugin's page for the exact permission names it registers.
| Aspect | Oxide (uMod) | Carbon |
|---|---|---|
| Plugin compatibility | The main target for most published Rust plugins | Runs most Oxide plugins without changes |
| Updates | Reinstalled manually after every Rust update | Updates itself through its preloader |
| Built-in management | Admin tools come from plugins | In-game interface, permission and user system |
| Plugin folder | oxide/plugins | carbon/plugins |
| Best for | Owners who want the familiar, best-documented setup | Owners who want automation and built-in tools |
Which admin plugins do most Rust servers run?
Most servers build their plugin list from the same handful of categories, and the strongest lists are short. Every plugin hooks into server events, so twenty well-chosen plugins beat eighty overlapping ones for both performance and stability. Test new plugins on a separate identity first, read the config file each one generates, and keep a written list of what you run, so updating on wipe day takes minutes instead of an evening.
Whatever you add, stay within Facepunch's Community Server and Hosting Guidelines. They explicitly allow monetizing a server through entry fees or subscriptions, donations, selling cosmetic items, effects or enhancements, a server currency and advertising, but they forbid giving Facepunch DLC to players who have not bought it and presenting your server as official. Read the current text before you open a store.
- Moderation: vanish, spectate and admin radar tools, kick and ban helpers
- Logging and reports: combat logs, forwarding F7 reports to Discord
- Rates and balance: gather multipliers, stack sizes, smelting and crafting speed
- Quality of life: kits, homes and teleports, backpacks, remover tools
- Teams and anti-grief: team size limits, clan systems, raid rules
- Communication: chat formatting, automated messages, Discord bridges
- Wipe helpers: countdowns, scheduled announcements, data resets
When is forced wipe day, and what does each wipe reset?
Forced wipe arrives with Rust's monthly update on the first Thursday of every month, and Facepunch's wipe timer documentation lists that monthly schedule at 19:00 UK time. The update makes existing world saves unusable, so every server starts a fresh map that day whether it planned one or not. Blueprints are a separate decision: they are normally up to you, and when an update does require a blueprint reset, Facepunch says so in its announcement. Many servers run a full wipe on forced wipe day anyway.
Between forced wipes you set your own rhythm, usually weekly, biweekly or monthly, and advertise it with the matching weekly, biweekly or monthly tag. Fast wipes suit high-population PvP servers where the map fills quickly; monthly wipes suit builders and smaller groups who want time to progress. The wipetimer console variables let you define a time zone, day and hour, or a cron expression, so the server knows when your next wipe is due.
| Wipe type | What resets | Files involved | When |
|---|---|---|---|
| Map wipe | World, buildings, loot, player inventories and positions | The .sav files with their numbered backups, and the .map file | Weekly, biweekly or on forced wipe |
| Blueprint (BP) wipe | Learned blueprints | Files starting with player.blueprints | Your choice, or when an update requires it |
| Full wipe | Map and blueprints together | Map and save files plus the player.blueprints files | Most often on forced wipe day |
| Forced wipe | At minimum the map | Mandatory after the monthly update | First Thursday of the month, 19:00 UK time |
How do you perform a map wipe or a blueprint wipe?
A manual wipe means deleting the right files while the server is stopped. Announce the time in advance, stop the server cleanly so the last save completes, and back up the entire identity folder before touching anything. For a map wipe, delete the .sav files, including their numbered backups, and the .map file. For a blueprint wipe, also delete the files beginning with player.blueprints. Leave the cfg folder alone, because it holds your admins, bans and server settings.
Before restarting, decide whether to keep the seed or roll a new one; a fresh seed or size keeps the new wipe from feeling like a rerun. Update the server through SteamCMD, reinstall Oxide or let Carbon update itself, then reset plugin data that should not carry over, such as kit cooldowns, clan rosters or shop balances, usually found in the framework's data folder. Start the server, watch the console until the map finishes generating, and join to confirm plugins loaded before announcing the wipe.
Doing this by hand every week gets old, which is why many owners script it or use a panel scheduler. TheCrewHost also offers a separate Rust Autowipe server type for owners who want wipes automated; its product page explains how the schedule works.
Which RCON tools can you use to manage the server?
RCON lets you run console commands without being in game, and on Rust you should enable the WebSocket version with rcon.web 1, as Facepunch recommends. Set rcon.port and a long, unique rcon.password, because anyone with that password effectively owns your server. Facepunch publishes a browser-based WebRCON client, desktop tools such as RustAdmin add player lists, chat and scheduled commands, and Discord bots can relay chat or alerts. On a managed server, the control panel's web console does the same job.
The commands you will use most are status for the player list, say to broadcast a message, kick, ban and banid for moderation, and server.writecfg to save changes to users.cfg. To make yourself owner, run ownerid with your SteamID64 and a name, save with server.writecfg and reconnect so the new auth level applies; moderatorid works the same way for staff. The serverinfo command reports server framerate, entity count and memory, which helps you spot trouble early.
How much RAM does a Rust server need as the map grows?
Plan for at least 8 GB, then scale with world size and population, because Rust's memory use is driven by the number of entities in the world. Every wall, door, box, furnace and dropped item is an entity, so a server that starts a wipe comfortably can use noticeably more RAM a few weeks later. Treat the table as a starting point, then watch memory and entity count in the second half of a wipe, when bases are at their largest.
Upkeep and decay are your main defense against runaway entity counts, so avoid disabling them on long wipes. Scheduled restarts help reclaim memory, and trimming heavy plugins often helps more than adding RAM. Rust server hosting at TheCrewHost runs on Ryzen 9 9950X processors with DDR5 memory and NVMe storage, with Rust plans from 8 GB to 32 GB that you can upgrade mid-wipe if your population grows, and the İstanbul location keeps latency low for players in Türkiye.
| World size | Typical players | Suggested RAM | Good for |
|---|---|---|---|
| 1000–2000 | Up to 10 | 8 GB | Testing, build servers, small private groups |
| 2500–3000 | 10–50 | 8–10 GB | Small communities, solo, duo and trio servers |
| 3500 | 50–100 | 10–12 GB | Classic community server with monthly or biweekly wipes |
| 4000 | 100–150 | 12–16 GB | Busy vanilla or lightly modded servers |
| 4500–5000 | 150–250 | 16–32 GB | High-population servers with many plugins |
| 5500–6000 | 250+ | 32 GB | Very large maps, long wipes, heavy modding |
Set up a Rust server and run your first wipe in 8 steps
- 1
Install the server files
Install SteamCMD, log in anonymously and download app 258550 into an empty folder, or rent a managed Rust server that arrives with the files already installed.
- 2
Choose identity, size and seed
Pick a server.identity name, a world size that fits your expected player count and a seed you have previewed, then set server.maxplayers and server.hostname.
- 3
Secure RCON
Add rcon.web 1, an rcon.port and a long, unique rcon.password to the startup line, and never reuse that password anywhere else.
- 4
Start the server and claim ownership
Launch with -batchmode, wait for the map to generate, then run ownerid with your SteamID64, save with server.writecfg and reconnect to get admin rights.
- 5
Describe and tag the server
Set server.description, a header image and server.tags for your wipe schedule, difficulty and region, so the right players find you in the browser.
- 6
Add a modding framework
Install Oxide or Carbon, add plugins one at a time, review each generated config file and grant the needed permissions to your admin group.
- 7
Plan backups and the wipe schedule
Back up the identity folder regularly, choose weekly, biweekly or monthly wipes, and configure the wipetimer variables to match that schedule.
- 8
Handle forced wipe day
On the first Thursday of the month, stop the server, back up, update Rust and your framework, delete the save and map files, plus blueprints if planned, then restart.
Frequently Asked Questions
How often should I wipe my Rust server?
Wipe as often as your community's pace demands, but never less than once a month, because the monthly update forces a map wipe anyway. High-population PvP servers often wipe weekly, since the map fills up and late joiners fall hopelessly behind. Mid-size communities tend to wipe biweekly, while PvE, building and small friend-group servers usually stick to monthly. Whatever you choose, keep it predictable and state it in the server name and tags.
Does forced wipe reset blueprints?
Forced wipe always resets the map, because saves from the previous version cannot be loaded after the monthly update. Blueprints are normally the owner's choice, and when an update does require a blueprint reset, Facepunch states it in the announcement. Many servers still run a full wipe on forced wipe day so everyone restarts on equal terms. If you want to keep blueprints, simply leave the player.blueprints files in place when you clean up.
How do I make myself admin on a Rust server?
In the server console or over RCON, run ownerid followed by your SteamID64 and a name, then save it to users.cfg with server.writecfg. The new auth level only applies after you reconnect. Use moderatorid the same way for staff. While the server is stopped, you can also add these lines directly to users.cfg in the cfg folder. Oxide and Carbon plugins use their own permission groups on top of this.
What world size should I pick for my player count?
As a rough rule, 2500 to 3000 works for up to 50 players, 3500 for 50 to 100, and around 4000 for 100 to 150, while busier servers go to 4500 and beyond. Build and test servers are fine at 1000 to 2000. Larger sizes also raise RAM use, disk use and startup time. A map that is too big for its population feels empty, so if in doubt, start one step smaller.
Why does my Rust server use more RAM every day?
Because the entity count grows as players build, and every building block, box and furnace takes up memory. That is normal, and usage usually peaks toward the end of a wipe. Keeping upkeep and decay enabled, scheduling restarts and removing unnecessary plugins all slow the climb. If memory hits its limit at the end of every wipe, upgrading to a bigger plan or reducing the world size is the cleanest fix.
How do players connect to my Rust server?
Once the server is listed, players can find it by searching its name in the in-game server browser. To connect directly, they press F1 to open the console and type client.connect followed by the server IP and port, such as 28015. If the server does not appear in the browser, check that the game and query ports are open and that map generation has finished; newly started servers can take a little while to show up.
