How to Wipe a Rust Server (Map, Blueprints, Full)

A Rust wipe is nothing more than deleting the right files from the server's identity folder while the server is stopped. The hard part is knowing which files. Delete too little and players log in to last month's bases. Delete too much and you lose your admin list, your bans or a plugin's data you wanted to keep.

This guide lists exactly which files each type of wipe removes, using the same patterns the Panelra agent uses on real hosts, checked against a live server identity folder on our Ubuntu test host. Then it walks through a manual wipe step by step.

The three kinds of wipe

• Map wipe. A new world: every building, deployable, sleeper and item on the map is gone. Players keep the blueprints they learned.
• Blueprint wipe. Everyone forgets every learned blueprint. It is almost always done together with a map wipe; a blueprint wipe on a map that stays makes little sense, and Panelra does not offer it on its own.
• Full wipe. Map and blueprints together. In Panelra this is the "full" wipe type; "map only" is the other one.

Facepunch forces a map wipe on every server once a month with the game update. Blueprint wipes are up to you, unless an update tells you otherwise.

The file matrix

Everything a running server writes lives in server/<identity>/ inside the install directory. This is that folder on our test host (Rust build 25581777), with what each wipe type does to each file:

How to read the patterns:

• The map wipe removes everything that belongs to the world: the save, its rotating backups (.sav.1, .sav.2, controlled by server.savebackupcount, at least 2), the map cache, the navmesh and occlusion caches, and sv.files, which stores the images on signs and photo frames by entity id. Without the save those images point at nothing, and the server never cleans them up.
• The full wipe also removes player.blueprints (learned blueprints) and player.states (per-player progress such as missions and explored map).
• "Side files" are the SQLite -wal, -shm and -journal files. They are deleted together with their database, so no stale side file is left next to the fresh database the server creates.
• Only the top level of the identity folder is scanned, and only regular files. Nothing in cfg/ or other subfolders is touched.

The numbers in the file names matter. 4000 is the world size and 1420068679 the seed. 289 and 18 are version numbers that Rust puts in the file names; 289 also appears on the clans, relationship and player state databases, and 18 on the other player databases. A server only loads files whose names match its current settings, so files from an old seed or an old version are simply left behind, which is why they pile up over months.

On a map wipe the .map file is deleted as well. For a procedural map with the same seed and size this only costs time: the server regenerates an identical map, which on our host took about 7 minutes instead of about 40 seconds with the cached file.

Wipe step by step with the server stopped

This assumes the layout from our Ubuntu install guide: install directory /opt/rust-servers/instance-1, identity my_server, and a systemd unit called rust-server.

1. Warn players and save. Send a few RCON messages ahead of time, then save:

say Map wipe in 5 minutes
save

The Panelra agent announces a wipe at 30, 10, 5 and 1 minutes and at 30 seconds before it stops (only the marks that fit in the warning time you set), saves at the 1 minute mark and saves once more right before it stops the server.

2. Stop the server and wait until it is really down.

systemctl stop rust-server
systemctl show -p ActiveState --value rust-server

Continue only when the second command prints inactive (or failed). deactivating means the process is still writing to disk. This is the most important step: a running server holds the world in memory and writes it back on its next autosave or on shutdown, so files you delete underneath it come back and the wipe silently never happens.

3. Back up the identity folder.

cd /opt/rust-servers/instance-1/server
tar czf /root/my_server-before-wipe-$(date +%F).tar.gz my_server

4. Delete the map files. First list what will go, then delete it. -maxdepth 1 keeps it to the top level, the same as the Panelra agent:

cd /opt/rust-servers/instance-1/server/my_server
find . -maxdepth 1 -type f \( -name '*.map' -o -name '*.sav' -o -name '*.sav.[0-9]*' -o -name '*.sav.new' \
  -o -name '*.navmesh' -o -name '*.navmesh.new' -o -name '*_occlusion_*.dat' -o -name 'sv.files.*.db*' \) -print

Check the list, then run the same command with -delete in place of -print. This takes the .sav.1 and .sav.2 backups too, so no old save stays around to be restored by mistake. The server rebuilds the map, navmesh and occlusion caches on the first start.

5. For a full wipe, delete blueprints and player progress too.

find . -maxdepth 1 -type f \( -name 'player.blueprints.*.db*' -o -name 'player.states.*.db*' \) -print -delete

6. Set the new seed or map (next section), then start the server:

systemctl start rust-server
journalctl -u rust-server -f

A fresh map is generated on this first start. On our 4 vCPU test host a new 4000 map took about 8 minutes until Server startup complete, so tell players to wait.

Change the seed or map on wipe

Save files are named after the world size and seed. A server started with a new seed finds no matching save and generates a new world, so changing the seed is the other half of most wipes.

Edit the seed line in server/my_server/cfg/server.cfg:

server.worldsize 4000
server.seed 1420068679

Use a positive whole number from 1 to 2147483647. Do not use 0. The server.seed and server.worldsize reference pages cover both settings in more detail. Panelra treats a seed of 0 or less as invalid: if one reaches the agent, it writes a random positive seed instead and reports which one, because a fixed seed is what lets you rebuild the same map from a backup and tell players in advance what map is coming. If you also pass +server.seed on the command line, change it there too, so the two never disagree.

Panelra schedules offer three seed modes on each wipe: keep current, random (a new seed is generated and saved as the server's seed) and custom (a seed you pick). Keeping the seed with a map wipe gives players the same terrain with nothing on it.

For a custom map, the server loads the map from a URL passed on the command line:

+server.levelurl https://example.com/maps/my-map.map

Add it to ExecStart in the systemd unit, run systemctl daemon-reload, and start. To go back to a procedural map, remove the argument; the seed and world size then apply again. Panelra writes and removes +server.levelurl in the unit as part of the wipe, after the files are deleted and before the server starts.

What not to delete

A wipe resets the world, not your server. Keep:

• cfg/: server.cfg is your configuration, users.cfg holds owners and moderators, bans.cfg your bans. Deleting bans.cfg unbans everyone.
• The other player databases: player.deaths, player.identities and player.tokens. No Panelra wipe type touches them. Deleting player.tokens breaks every player's Rust+ app pairing.
• clans and relationship databases (clans and player contacts), companion.id and anything else you cannot name. When in doubt, move a file into your backup folder instead of deleting it. player.states is safe even if you keep it on a map wipe: the server clears a player's state by itself when it belongs to a different seed or save.
• Oxide and Carbon data. Plugin data lives outside the identity folder, in oxide/data/ or carbon/data/ in the install directory. A map wipe never needs to touch these folders. Deleting them wholesale also deletes data you probably wanted to carry over, such as shop balances, and on Oxide the oxide.users and oxide.groups files that hold your permissions and groups.

Per-wipe plugin data resets

Most plugins with wipe-dependent data (teleport homes, kill stats, raid logs, map markers) reset themselves. Oxide documents the OnNewSave(string filename) hook as "called when a new savefile is created (usually when map has wiped)", and a new save file is created when none exists for the current map, which is exactly the state after a wipe. Carbon describes itself as fully compatible with Oxide plugins. Many plugins expose a config option such as "wipe data on new save"; check it on each plugin you care about.

When a plugin does not reset its own data:

1. Stop the server first. Plugins write their data files when they unload, so a file deleted while the server runs can be written back on shutdown.
2. Delete only that plugin's file, for example oxide/data/SomePlugin.json, not the whole folder.
3. Keep plugins that track long-term state (permissions, bans, economy you carry over) out of your reset list.

A side effect to know: because OnNewSave fires when the server has to create a new save file, restoring a server without its .sav file also looks like a wipe to your plugins.

Forced wipe day

Facepunch releases the monthly update on the first Thursday of the month at 19:00 London time, and every server needs a new map afterwards. The UK time stays fixed, so in UTC it moves with British Summer Time:

UK clocks go back on Sunday 25 October 2026, which is why the time shifts between the two. Rust's own wipe timer uses the same default: wipetimer.wipeTimezone is Europe/London and wipetimer.wipeHourofDay is 19.

On forced wipe day the order is: stop the server, update it with app_update 258550 validate, delete the map files, start. Update first, so your players' updated clients can connect. On Oxide, reinstall the Oxide build for the new Rust version before you start: the update replaces the game DLLs that Oxide patched. Carbon updates itself on the first start after the Rust update, as long as its self-update is on.

Let Panelra do this for you

Panelra runs this whole sequence for you on a schedule: weekly, every two weeks, on your own cron schedule, on specific dates or on forced wipe day. It warns players with an in-game countdown, saves, stops the unit and waits until it is inactive, deletes exactly the files in the matrix above, applies the new seed or map and starts the server again. It can take a backup and update plugins before the wipe. On forced wipe day it starts checking for the Facepunch patch at 16:00 UTC every 90 seconds. As soon as the new build is out, it runs a 5 minute in-game countdown, stops the server, updates it with SteamCMD and then wipes, with blueprint wiping as a separate per-server choice. See wipe scheduling.

Free during the open beta. Pricing will be announced before the beta ends.

Wipe checklist

• Announce the wipe time and type (map or full) to players.
• Warn in game, then save.
• systemctl stop, then confirm ActiveState is inactive.
• Back up the identity folder.
• Delete *.map, *.sav, the .sav.1, .sav.2 backups, *.navmesh, *_occlusion_*.dat and sv.files.*.db*.
• Full wipe only: delete player.blueprints.*.db* and player.states.*.db*.
• Set the new server.seed (1 to 2147483647, never 0) or +server.levelurl.
• Forced wipe day: update with SteamCMD, then reinstall Oxide (Carbon updates itself on start).
• Reset plugin data that does not reset itself, with the server still stopped.
• Keep cfg/, clans, relationship, the other player databases and oxide/data or carbon/data.
• Start, watch the log until Server startup complete, then join and check.