The first Thursday: what a force wipe actually does
Facepunch ships a client and server patch on the first Thursday of every month, usually around 19:00 UTC, though they do not commit to a fixed minute. The patch bumps the network protocol, so patched clients cannot connect to an unpatched server and vice versa. There is no grace period. In almost every month the save format also changes, and that is what makes the wipe forced rather than optional: nothing deletes itself, the update simply makes the old save unusable.
Two wipes exist and they are independent. A map wipe clears the world and every base on it. A blueprint wipe clears what players have learned to craft. Blueprints live in their own database file and survive a map wipe unless you delete them, so the standard community pattern is a full wipe (map plus blueprints) on force-wipe Thursday and map-only wipes in between.
The other half of force wipe day is your modding framework. The game update overwrites the managed assemblies that Oxide and Carbon patch into, which silently removes the framework. Reinstall it after updating the game, never before.
- Force wipe lands the first Thursday of every month, typically around 19:00 UTC
- Map wipe and blueprint wipe are separate operations on separate files
- Every game update strips your Oxide or Carbon patch; reinstall the framework afterwards
- Patched and unpatched clients cannot mix, so plan for downtime rather than a rolling update
Running the wipe: exact files, exact order
Everything lives under server/<identity>/. The map save is in save/ as a .sav file plus rolling backups .sav.1 through .sav.3, alongside a cached map file named like proceduralmap.4500.1785296.226.map. Delete both the .sav set and the .map file. Leaving the cached map behind is the classic reason a server regenerates the same world you just wiped.
Blueprints are player.blueprints.<n>.db in the identity folder. The number in the filename bumps when Facepunch changes the schema, so match by pattern rather than memorising a name. Leave it alone for a map-only wipe.
Plugin data is what people forget. Clan rosters, kit cooldowns, economy balances and backpack contents sit in oxide/data or carbon/data and do not wipe with the map. Well-written plugins implement the OnNewSave hook and clear themselves; plenty do not. Decide per plugin what should survive.
A sequence that works: announce, stop, back up the whole identity folder off-server, update the game, reinstall the framework, delete saves and any blueprint or plugin data, change server.seed, start, watch the console through map generation, confirm plugins loaded, then confirm the server appears in the browser.
- Delete save/*.sav, the .sav.1-3 backups, and the cached proceduralmap.*.map
- player.blueprints.*.db only comes out when you want a blueprint wipe
- oxide/data or carbon/data holds plugin state that survives a map wipe by default
- Back up the entire identity folder first; rollback is only possible if you kept one
- Change server.seed in the same maintenance window or you regenerate an identical map
Choosing a cadence, and why the hour matters
Three cadences dominate. Weekly, almost always Thursday, suits modded and high-gather servers: churn is high, progression is fast, and you repopulate from zero every week. Monthly, meaning force wipe only, suits low-population community servers where people want to keep a base, but weeks three and four go quiet and a single dominant clan can end the wipe early. Biweekly is the usual compromise and is what most mid-size servers settle on.
Timing is underrated. On force-wipe Thursday every server on the planet wipes at the same moment, and a new server with no history loses that fight badly. Off-schedule wipes are how small servers get discovered, so pick an hour that matches your own region's evening and then never move it. Players plan their night around a wipe time; an inconsistent one costs you regulars faster than any balance decision.
Advertise the cadence in server.tags, not only in server.description. The in-game browser filters read tags, so a player filtering for a biweekly server will never see you if the tag is missing.
- Weekly means constant repopulation; monthly means a quiet back half; biweekly splits the difference
- Wiping at exactly 19:00 UTC on force-wipe day puts you against every other server at once
- server.tags drives the browser filters; the description alone is not enough
- Fix the hour permanently and announce twice, a week out and an hour out
Map size and seeds: worldsize is area, not width
server.worldsize accepts values from 1000 to 6000 and defaults to 4000. The number is the map's edge length in metres, so cost scales with the square, not linearly. 3000 gives you 9 km squared, 4000 gives 16, 4500 gives roughly 20, and 6000 gives 36. Moving from 3000 to 4000 is nearly double the world to simulate and to populate, not a third more. Below about 3000 monument density thins out and seeds start dropping the large monuments players log in for.
Seeds are set with server.seed, and you do not have to gamble on one. RustMaps generates and previews any seed and size combination for free, including the full monument list, before you commit a single wipe to it. That is the entire honest answer to "how do I find a good seed": look for a complete monument set, a usable ring road, and enough coastline for boats.
Custom maps load through server.levelurl with a direct download link, which overrides both seed and worldsize and makes every joining client download the file. Save that for your third wipe, not your first.
- worldsize 3000 = 9 km2, 4000 = 16 km2, 4500 = ~20 km2, 6000 = 36 km2
- Under 3000 you lose large monuments; over 4500 you need real population to fill it
- Preview seeds free on RustMaps before committing; you do not need to buy a map
- server.levelurl overrides seed and worldsize and adds a client-side download to every join
How much RAM a Rust server actually needs
Rust memory is driven by entity count, not player count. A fresh map is cheap. The same map three weeks in, carrying a hundred bases and their deployables, is not. That is why servers fall over in week three and then boot cleanly again on Thursday morning.
Rough steady-state figures from real servers, with plenty of variance: worldsize 3000 with under 20 players sits around 3 to 5 GB fresh and 5 to 7 GB late wipe. 3500 to 4000 with 40 to 50 players runs 5 to 6 GB fresh and 8 to 10 GB late. 4250 to 4500 at 100-plus needs 7 to 9 GB fresh and 12 to 16 GB late.
Two traps. Procedural generation on the first boot after a wipe peaks roughly 1 to 2 GB above steady state, so an undersized server dies during map gen rather than during play. And RAM does not fix server frame time. Rust's simulation is bound to one main thread, so stutter in big fights is a CPU clock and plugin-count problem. Buying memory to fix lag is the most common wasted upgrade in Rust hosting.
- 3000 / under 20 players: about 2-3 GB fresh and 3-4 GB late wipe on a light plugin set, climbing past 4 GB at 20 players or with a heavy plugin stack
- 3500-4000 / 40-50 players: about 5-6 GB fresh, 8-10 GB late wipe
- 4250-4500 / 100+ players: about 7-9 GB fresh, 12-16 GB late wipe
- Map generation spikes 1-2 GB above steady state; size for the spike, not the average
- Single-SKU Rust plans, Puranode's 4 GB included, genuinely cover a 3000 map with friends and genuinely do not cover 4500 at high pop, so arrange the resize before wipe day rather than after
Oxide (uMod) versus Carbon
Both are C# plugin frameworks that patch the server's managed assemblies. You run one or the other, never both at once.
Oxide, distributed as uMod, is the incumbent. Close to every plugin published online is written and tested against its hook API, so if a plugin page does not say otherwise, assume Oxide. Files sit in oxide/plugins, oxide/config, oxide/data and oxide/lang, and permissions run through oxide.grant and oxide.revoke with groups.
Carbon reimplements the same hook API in its own carbon/ tree with c-prefixed console commands, so most Oxide plugins load unmodified. What you actually gain is much faster plugin compilation, quicker startup, hot reload that behaves, and a built-in profiler that names the plugin eating main-thread time. That profiler is the genuine reason to switch: on Oxide, tracking down a plugin causing a 40 ms frame spike is guesswork.
What breaks on Carbon are plugins that reach into Oxide internals instead of the documented hooks. Migration is mostly copying plugins and configs into the carbon/ equivalents and testing each one. Neither framework can start on a freshly patched game until its own build lands.
- Never run Oxide and Carbon together; they patch the same assemblies
- Oxide is the compatibility default; Carbon is faster to compile and ships a real profiler
- Plugins using Oxide internals rather than hooks are the ones that break under Carbon
- On patch day, hold the game update until your framework build is out
- If the framework fails to load, the server boots vanilla and plugins are silently absent
Your first wipe: the minimum that actually matters
Ports come first, because this is where most first servers quietly fail. 28015/UDP carries game traffic, 28016/TCP is RCON, the Steam query port defaults to 28017 in current builds, and 28082/TCP serves the Rust+ companion app. If the query port is closed, players can still connect by direct IP but your server never appears in the browser, and that failure looks exactly like nobody finding you.
Then identity. Set server.hostname, server.description, server.url and server.headerimage, which must be a direct link to a 512x256 image. Add your own account with ownerid <steamid64> and then run server.writecfg, or your admin rights vanish on the next restart. Drop server.saveinterval to 300; the 600-second default leaves more rollback after a crash than players will forgive.
Plugins: run three to five on your first wipe. Every plugin is a hook on the main thread and another wipe-day failure mode, and servers that die on day one usually died with forty plugins rather than four. Admin tooling, a chat relay and whatever sets your gather rate is enough. Add features once you have population to justify them.
- 28015/UDP game, 28016/TCP RCON, 28017 Steam query, 28082/TCP Rust+
- A closed query port means invisible in the browser but reachable by direct IP
- ownerid <steamid64> followed by server.writecfg, or admin resets on restart
- server.headerimage needs a direct link to a 512x256 image
- Three to five plugins on wipe one; expand when you have players, not before
When you should just self-host
Rust has no singleplayer and no listen server, but the dedicated server is free. SteamCMD app 258550, no second copy of the game required, Windows or Linux. If you and four friends want a private 3000 map, a spare desktop with 8 GB free and a wired connection genuinely does the job, and nobody should sell you anything for that. The real costs of self-hosting are port forwarding, a residential IP that changes, and the box needing to stay on while you sleep if anyone else is going to play.
Paying starts to make sense at three specific points. When strangers join and uptime stops being something you personally want to be responsible for. When ping starts mattering, because Rust fights turn on one bolt-action shot and hit registration degrades noticeably past roughly 80 to 100 ms. And when you get popular enough to attract UDP floods on 28015, which happens to Rust servers more than most games. Puranode runs Rust on EPYC nodes in EU-Central with DDoS filtering in front, which addresses the last two. For five friends on one small map, keep the money.
- RustDedicated is free via SteamCMD app 258550; you do not need a second game licence
- A spare machine with 8 GB free handles a private 3000 map for a handful of players
- Self-hosting costs you port forwarding, a dynamic IP, and a machine that must stay awake
- Pay for hosting when uptime, EU-wide ping, or DDoS filtering start to matter, not before