How to wipe a Rust server and keep blueprints

A wipe resets the world so everyone starts again on equal terms. What players care about is what survives it: the map almost never does, blueprints often should. This guide covers the kinds of wipe, the Facepunch forced-wipe schedule, running wipes on a schedule, picking the next map, and how to keep blueprints — including when a Rust update resets them anyway.

Map wipe, blueprint wipe, full wipe

A Rust server keeps its state in a few files in the server's save directory:

• The map and world save (*.map, *.sav) — terrain, every base, every box.
• Blueprints (player.blueprints.<N>.db) — what each player has learned.
• Player states (player.states.*) — map markers, chat mutes and similar per-player state.

Wipe types are named for what they delete:

• Map wipe: deletes the map, the world save and player states. Blueprints are kept. This is the usual weekly wipe.
• Full wipe (also called a blueprint wipe or BP wipe): a map wipe that also deletes blueprints. Everyone starts from nothing.
• Player wipe: deletes death markers only. The map stays.

A blueprint-only wipe that keeps the map is not something servers do in practice, and the panel does not offer one.

The Facepunch forced-wipe schedule

Facepunch ships the monthly Rust update on the first Thursday of each month. That update changes the map format, so every server has to map wipe that day — the "forced wipe". It wipes blueprints only when Facepunch says so in the update notes.

Most servers plan around that day. Weekly, biweekly and monthly servers all land a wipe on forced-wipe Thursday, and the cadence a server advertises (for example "Monthly | No BP Wipe") tells players what to expect in between.

Wipe now

In rustd.xyz, open your server and go to Wipe & maintenance. Wipes need SSH access to the game host, because they delete files: until it is set up, the page asks you to Configure SSH access to enable wipes in the server's Settings. RCON must be connected too. Oxide is not needed.

Click Wipe now…, choose Map wipe, Full wipe or Player wipe, pick the seed (the prepared next map, a random one, a specific seed, the current one, or an uploaded map file) and, optionally, a map size between 1000 and 6000. Then confirm. The panel then:

1. warns players in chat from 60 seconds out;
2. writes the new seed and size, and restarts the server;
3. takes a blueprint snapshot (map and full wipes), then deletes the files for the wipe type;
4. waits for the server to come back, and reports the outcome in the activity feed.

Scheduling wipes

The Wipe schedule card runs wipes for you:

• Cadence: Weekly, Biweekly or Monthly. Monthly is the first chosen weekday of the month, so Monthly on Thursday lines up with forced wipe. Biweekly is the first and third chosen weekday of the month, so it lands on forced wipe as well, rather than drifting the way a plain every-14-days schedule would.
• Day of week and Time: when the server goes down. Players are warned in chat from ten minutes before.
• Timezone (IANA): for example America/New_York or Europe/London, so the wipe keeps its local time across daylight saving.
• Wipe blueprints every Nth wipe: every Nth scheduled wipe is a full wipe and the rest are map wipes. Set it to 4 on a weekly server for a monthly BP wipe, or 0 never to wipe blueprints on schedule.

The panel also sets Rust's in-game wipe timer to match, and an hour before each scheduled wipe it checks that the wipe will succeed. If it will not (SSH unreachable, save directory not writable), the server's admins are emailed so there is time to fix it.

Choosing the next map

The Next map card shows the map the next wipe will switch to, rendered ahead of time with its monuments and biomes, so you can check it before players see it.

• Reroll… picks a different random seed. You get three rerolls per wipe.
• Use a map file… uploads a custom .map (up to 64 MB) for the next wipe to boot instead of a generated world. Its size comes from the file.

If you publish the server's public map page (Settings → Public map page), players get a page with a countdown to the next wipe and, from a set number of hours before it, the next map.

Keeping blueprints

A map wipe already keeps blueprints. Two things can still cost players their blueprints: a wipe you regret, and a Rust update that resets them.

Blueprint snapshots

Before every map or full wipe deletes anything, the panel copies the server's blueprints into a snapshot on the game host. The Blueprint snapshots card lists them. Choose Restore to put a snapshot's blueprints back: the server restarts after a 60-second warning, and only blueprints are restored — the map is left alone. That undoes a full wipe that should have been a map wipe.

When a Rust update resets blueprints

Rust keeps blueprints in a database file numbered by generation, player.blueprints.<N>.db. Some updates move to a new generation, and the new file starts empty: everyone has lost what they learned, even on a "No BP Wipe" server. The old file is still on disk.

Turn on Restore blueprints after a Rust blueprint-generation bump in the Blueprint preservation card. The panel then checks the save directory every ten minutes. When a new generation appears, it warns players, restarts the server and merges the previous generation into the new one — per player, keeping every blueprint from both, so anything relearned since the update is kept too. A backup of the new file is kept, and put back if the server does not come back. If the reset arrives with a map wipe, the merge happens during that wipe's restart.

The restore needs sqlite3 and python3 on the game host. Check now… runs the check immediately, and Restore anyway… runs the merge even when no reset was detected.

Merging by hand

The panel's merge is an ordinary Python script, and rustd.xyz keeps a by-hand runbook for it. That is only for when the panel cannot reach the host, or when a player needs a different rule than "keep everything" — ask us and we will walk you through it. With the server stopped, it merges the old generation's database into the new one and writes the result to a separate file. Keep a backup of the new generation, copy the merged file in with the same owner and permissions (the game cannot save to a file it cannot write), and start the server.