Rust wipes: schedule, blueprints and keeping your players

Rust forces a map wipe on the first Thursday of every month, when Facepunch ships the monthly update, the save format changes and old worlds stop loading. That is the only wipe you do not choose. Everything else - whether blueprints go with the map, what happens in the three weeks between, and what your players are told about it - is yours, and getting it wrong empties a server faster than any amount of lag.

This is the whole job: what the forced wipe actually breaks, which files each kind of wipe deletes, how to pick a cadence you can keep, a runbook for the day itself, and what to do about the plugins that will not load until their authors catch up.

What the forced wipe actually forces#

On the first Thursday of the month, usually some time around 19:00 UTC, Facepunch pushes a client and server update together. Three things change at once and it helps to keep them separate in your head.

• The network protocol. Clients on the new build cannot join a server on the old one, and vice versa. Until you update, every player sees a connection protocol error and concludes your server is down.
• The save version. The world save is written with a version number in its file name, and the new build will not load the previous one. This is the part that makes the map wipe compulsory rather than merely encouraged.
• Procedural generation. Map generation changes most months. The same seed and the same world size produce a different map after a forced wipe, so "keeping the map" is not an option even if you liked it.

Blueprints are not touched by any of that. A forced wipe is a map wipe; the blueprint database is a separate file that survives unless you delete it. Every argument you have ever seen about "full wipe" versus "map wipe" is an argument about one file.

Map wipe and blueprint wipe are different files#

Everything a Rust server remembers lives under the install directory in server/<identity>/, where <identity> is whatever you passed to +server.identity. Learn this folder and wiping stops being mysterious.

server/  main/                                      the identity folder    cfg/      server.cfg                             convars executed at startup      users.cfg                              ownerid, moderatorid, bans    proceduralmap.3500.1934572.248.map       the generated terrain    proceduralmap.3500.1934572.248.sav       everything built on it    player.blueprints.3.db                   what players have learned    player.deaths.3.db    player.identities.3.db    player.states.3.db    player.tokens.dboxide/  plugins/  config/  data/  logs/            if you run Oxide

The map file name is proceduralmap.<worldsize>.<seed>.<version>.map, which is genuinely useful: you can read the world size and seed of a running server straight off the disk, and you can see at a glance that the version number moved after an update.

A few notes that save arguments later. Deleting only the .sav and keeping the .map gives you the same terrain with nothing built on it, which is a legitimate choice for a server with a map people like - until the next forced wipe invalidates the file anyway. oxide/data is where plugins keep clan membership, balances, cooldowns and home locations, so a "full wipe" that leaves it alone will hand everybody their old clan and their old bank balance on a fresh map. Decide that deliberately rather than by accident.

Choosing a cadence, and sticking to it#

There are four cadences that work, and one rule that matters more than which you pick: keep it. A server that wipes every Thursday at 19:00 UTC for a year builds a habit in the people who play it. A server that wipes "when it feels stale" has no returning players, because nobody can plan an evening around a feeling.

The population curve is the thing to design around. On most community servers the first forty-eight hours after a wipe carry the majority of the cycle's playtime, and by day five the server is running at a fraction of its peak. A weekly cycle keeps you near the peak most of the time and burns out builders. A monthly cycle gives builders what they came for and leaves you with three quiet weeks and a queue on wipe day. Biweekly is the common compromise for a reason.

Blueprint wipes are the second dial. Keeping blueprints makes returning cheap - a player who missed a week is not starting behind - and makes the first day a race for resources rather than for scrap. Wiping them makes everybody equal at the cost of turning day one into the tech-tree grind that some people play Rust specifically to avoid. Neither is wrong. What is wrong is changing it without saying so, because the players who organised their evening around a BP wipe will find out when they log in.

Seed, world size and what they cost you#

A new map means a new seed, and possibly a new size. Both are set on the launch line and both have consequences beyond scenery.

$ ./RustDedicated -batchmode -nographics \    +server.identity "main" \    +server.hostname "Longship | Biweekly | Next wipe Thu 2 Oct 19:00 UTC" \    +server.port 28015 \    +server.level "Procedural Map" \    +server.seed 1934572 \    +server.worldsize 3500 \    +server.maxplayers 100 \    +server.saveinterval 300 \    +server.tickrate 10 \    +rcon.web 1 +rcon.port 28016 +rcon.password "a-long-random-string" \    +app.port 28082

World size is the single biggest lever on resource usage, and it is not linear: going from 3000 to 4500 roughly doubles the terrain the server holds and the entities that can exist on it. Pick the size that matches your realistic population, not your ambitious one. A hundred players on a 3000 map is a brutal, busy server; twenty players on a 4500 map is a walking simulator with occasional gunfire.

Two things about that table surprise people. The first is that Rust's memory use is lowest on wipe day and highest on the day before the next one, because bases and deployables accumulate - so a server sized by how it looks on Friday will be short by Wednesday. The second is that map generation itself is the heaviest moment in the server's life: the first start after a wipe builds the whole world in memory before it writes the .map file, and a server can run out of memory during generation on a plan that would have hosted the finished map perfectly well. If your wipe fails at startup and works on the second attempt after you shrink the map, that is what happened.

Ports and remote administration#

If your host allocates a separate query port, set server.queryport explicitly rather than relying on the default. RCON is the tool you will actually run a wipe with, through the web console at Facepunch's RCON page or a desktop client, and it authenticates with a password over a connection you should not expose more widely than you need to - using RCON safely covers what that means in practice. Game server ports explained has the background on why the query port exists at all.

The commands worth knowing before wipe day are short. server.save forces a save. server.writecfg persists users.cfg and ownership changes to disk - skip it and your moderator list disappears on the next restart. quit is a clean shutdown that saves first; anything that kills the process instead loses up to server.saveinterval seconds of world.

The wipe-day runbook#

1. The day before, take a backup of the whole identity folder and lock it against rotation. Post the reminder. This is the backup you will want if you delete the wrong thing, and you have one chance to take it.
2. At the wipe hour, stop the server cleanly. Use the console quit command or the panel's Stop button. A kill loses the last few minutes, which does not matter on a map you are about to delete but matters a great deal if you decide to roll back.
3. Update the server. steamcmd +force_install_dir <path> +login anonymous +app_update 258550 validate +quit. Anonymous login works; validate is slow and is the only reliable fix for a partial update. SteamCMD explained has the rest.
4. Wait for your mod framework. Do not skip this. See the next section.
5. Delete the save files. *.sav and *.map for a map wipe, plus player.blueprints.*.db for a BP wipe, plus whatever else your plan calls for. The file manager or SFTP is the tool; a scheduled task cannot delete files for you.
6. Set the new seed and world size on the startup line, and check they are what you announced.
7. Start it and watch. Map generation takes several minutes on a large map with no output that looks like progress. Wait for the startup-complete line before you tell anyone.
8. Republish the details: hostname, description, Discord, wipe trackers. The server is only wiped once other people know.

The whole sequence is thirty to sixty minutes if nothing goes wrong, and it goes wrong roughly one month in four, which is the argument for doing it at a fixed hour you are awake for rather than at midnight.

Oxide, Carbon and plugins on wipe day#

If your server runs Oxide (uMod) or Carbon, the monthly update breaks it. Not sometimes - every month, by design, because the frameworks hook into game code that just changed. The build for the new protocol usually appears within hours, and starting the server before it exists gets you a server running with no plugins at all: no permissions, no kits, no clan system, no anti-cheat, and players quietly exploiting whatever your plugins were preventing.

The habit that avoids it: after the SteamCMD update, check that the framework has published a build for the new version before you start. If your server auto-updates on boot, that means turning auto-start off on wipe day.

• Plugins live in oxide/plugins as .cs files and are compiled at load; a plugin that fails to compile prints the error in the console and the others carry on.
• Configuration is in oxide/config, data in oxide/data, and the two get confused constantly. Wiping data resets player-facing state; wiping config resets your settings.
• Permissions survive wipes unless you clear them. oxide.grant group default kit.use and friends are stored, not derived.

Keep a copy of the working oxide folder from before the update, and a note of which plugin versions you were on. What to do when a mod update breaks is the general version of this problem, and keeping a modded server clean covers the hygiene that keeps a plugin list from becoming unmaintainable across a year of wipes.

Announcing it where people will actually read it#

Most wipe announcements fail because they are made somewhere only the people already paying attention will see.

• The server name is the announcement. server.hostname is the one field in the browser that everyone reads. Put the cadence and the next date in it: Longship | Biweekly | Next wipe Thu 2 Oct. Update it the moment the wipe finishes, not the day before the next one.
• `server.description` and `server.url` appear on the server info panel. The description takes several lines and is the right place for the rules, the cadence and the Discord invite.
• Wipe trackers list you automatically. They detect a new map from the query data, so you do not have to submit anything. What you control is whether the name and description tell a player arriving from a tracker when the next wipe is.
• In-game, a day ahead and an hour ahead, not five minutes ahead. say over RCON works; a countdown plugin is better because it repeats.
• Discord, scheduled. A message you have to remember to send is a message you will forget on the month everything else goes wrong.

The reason to over-communicate is not politeness. A player who logs in to find their base gone and no warning concludes the server was reset by accident or by a hostile admin, and they do not come back to find out which. A player who knew it was coming logs in on wipe day at the hour you told them. Growing a game server community is about the rest of that loop.

Backups, and what survives a wipe#

A wipe and a mistake look identical the morning after, so the pre-wipe backup is the only thing standing between "we wiped" and "we lost the wrong server". Take it before every wipe, keep it until the next one, and take it off the machine that holds the original.

On RE:NODE the Schedules tab runs a cron expression with ordered tasks - a backup, a console command, a power action - so the pre-wipe backup and the stop can happen at a fixed hour whether or not you are awake; cron expressions explained covers writing the expression, and scheduled tasks worth having covers what else belongs in there. Backup slots are on every plan, backups are stored off the machine they protect, and a backup can be locked so rotation does not delete it - which is exactly what a pre-wipe snapshot wants. Deleting the save files is still a file manager or SFTP job; the schedule cannot do that part for you.

What it cannot do is prove the backup works. Backups that actually restore makes the case at length; the short version is that restoring one onto a test server once, in a quiet week, is worth more than a year of taking them. A Rust world is a handful of files and restoring it is fast, which is precisely why nobody ever checks.

Memory is the other thing to watch across a cycle. A Rust server's usage climbs as bases go up, and a server that hits its memory limit is stopped and restarted rather than left to swap - clean, but it loses whatever was not saved. Shorten server.saveinterval on a busy server, and read restart schedules that help before adding a nightly restart that nobody asked for.

Troubleshooting#

Players get a connection protocol error after the monthly update. The server has not been updated yet. Run SteamCMD with validate and restart.

The server generated a new map even though you did not wipe. The seed, the world size or the save version changed. Check the .map file name against your startup arguments - the numbers in the file name are the world size and seed it was generated with.

The world came back after a wipe. The .sav was deleted but the server loaded a .sav.old or a file in a different identity folder. Check server.identity and list the folder rather than trusting the file manager's search.

No plugins loaded after the update. The framework has not been rebuilt for the new protocol, or it was rebuilt and not installed. The console says which on startup.

Moderators lost their rights on restart. ownerid and moderatorid changes were never written to users.cfg. Run server.writecfg after granting.

The server ran out of memory on the first start after a wipe. Map generation, not gameplay. Reduce server.worldsize, or run the generation once on a larger plan and keep the .map file.

FAQ#

When exactly is the Rust forced wipe?

The first Thursday of every month, when Facepunch ships the monthly update, generally in the evening UTC. The update changes the save format, so the previous map cannot be loaded regardless of what you would prefer.

Do I have to wipe blueprints when the map wipes?

No. Blueprints live in player.blueprints.*.db, which a forced wipe does not touch. Deleting it is a separate, deliberate choice, and it is the single biggest decision about how your server feels.

How often should a Rust server wipe?

Whatever you can keep. Weekly maps with monthly blueprints suit busy servers, biweekly suits most communities, and forced-only suits builders and roleplay. Consistency matters more than the interval.

Can I keep the same map across a wipe?

Between forced wipes, yes - delete the .sav and keep the .map and everyone starts fresh on familiar terrain. Across a forced wipe, no: generation changes, so the same seed produces a different map.

Why is my server using more memory than it did last week?

Because players have been building. Rust's memory use tracks entity count, which climbs through a wipe cycle and resets when you wipe. Size for the day before the wipe, not the day after.

Do I need to tell players before a wipe?

Yes, and earlier than feels necessary. A day in-game, a week in the server name. An unannounced wipe is indistinguishable from an accident, and players treat it as one.