How to Update Your Rust Map to a New Version Without Losing Player Progress

The author of the map on your server has released a new version. Bridges fixed, a monument rebuilt, a cave that finally has a way out. You want it on the server, and you do not want two hundred players to log in and find they have to learn every blueprint again.

A map update replaces the world, not the players. Upload the new map under a new file name, point +server.levelurl at it, delete the old world’s files from the server folder and keep the player databases. Blueprints, clans, names and Rust+ pairings stay exactly where they are. And when the update leaves the ground alone, renaming the old save to the new map’s name keeps the bases too.

This guide is for anyone running a custom map who has to move to a newer version of it: which files in the server folder hold what, which ones to replace and which to leave alone, why the new map needs a new name, and how renaming the save carries even the bases over. The file names are the ones a Rust server writes today, in October 2026.

What “progress” means on a Rust server

Players use the word for two different things, and the server keeps them in two different places.

• What they built. Bases, the loot in their boxes, turrets, vehicles, the team they formed. All of it exists at a position on the map, and all of it lives in one file: the world save.
• What they earned. The blueprints they learned, their clan, their name, their Rust+ app pairing, the contacts they marked. None of it has a position. It lives in small databases next to the world save, and it does not care which map is loaded.

That split is the whole trick. A map update has to throw away the first kind, because the terrain under it is changing. It never has to touch the second kind. When people talk about a “map wipe that keeps blueprints”, this is all it is.

What every file in the server folder holds

Everything below is in the server’s identity folder: server/<identity>/ inside your Rust server directory, where <identity> is whatever +server.identity is set to. On a server running a map called MapX-v1-0 it looks like this.

The server folder during a map update: the left column is the old world and goes, the right column is what players earned and stays.

The old world: replace these

• MapX-v1-0.289.sav and its backups .sav.1 and .sav.2: every entity in the world. Bases, deployables, boxes and their contents, vehicles, sleeping players and their inventories, and the teams.
• MapX-v1-0_<number>.map: the server’s own downloaded copy of the old map. The number is worked out from the download address.
• MapX-v1-0_<number>_occlusion_3.dat: visibility data the server calculated for the old map.
• MapX-v1-0.289.navmesh: the paths NPCs walk, baked for the old terrain.
• player.states.289.db: per-player data tied to the old world, such as map markers, pings, the death marker and how much of the map each player has uncovered.
• sv.files.289.db: the pictures painted on signs and held in photo frames. Their signs are in the old save, so the pictures have nowhere to go.

What players earned: keep these

• player.blueprints.18.db: every blueprint every player has learned. This is the file the whole guide is about.
• player.identities.18.db: Steam IDs and the names that go with them.
• player.deaths.18.db: the history of who died and when.
• player.tokens.db: the pairing between each player and the Rust+ companion app.
• clans.289.db: clans and their members.
• relationship.289.db: the contacts each player has met and marked.

Every .db file has a partner ending in -wal, for example player.blueprints.18.db-wal. It holds the most recent changes that have not been folded into the main file yet. Treat the pair as one file: keep both or remove both. Deleting only the -wal next to a file you keep can lose the last blueprints people learned before you stopped the server.

The numbers in the names are not part of the map. 289 is the save format of the current Rust build and 18 is the version of the player databases. Facepunch raises them when an update changes the format, so look at what is in your own folder rather than at these examples.

Before you touch anything

1. Announce it. A day or two ahead, in your Discord and on the server. Say that the map is being updated, that bases will not carry over and that blueprints will. People forgive a wipe they were told about.
2. Stop the server cleanly. Run server.save in the console, wait for the save to finish, then shut the server down. Never edit the folder while the server is running: it keeps the databases open and writes to them.
3. Back up the whole identity folder. Copy or zip server/<identity>/ somewhere else. If anything goes wrong, putting that folder back puts the server back exactly as it was.

Step by step: moving from MapX v1.0 to v1.1

1. Upload the new map under a new name

Put the new file on your web host next to the old one, with the version in its name: MapX-v1-1.map, not a second MapX.map over the top of the first. The next section explains why this matters more than anything else here. Leave the old file online for now.

2. Point the server at it

Change the startup line, or server.cfg if your host uses it:

+server.levelurl "https://yourhost.com/maps/MapX-v1-1.map"

Keep the quotes. If you are setting up a custom map for the first time rather than updating one, the custom map installation guide covers the hosting side in full.

3. Remove the old world

In server/<identity>/, move these into a folder of their own (moving is safer than deleting, and costs nothing):

• MapX-v1-0.289.sav, .sav.1, .sav.2
• MapX-v1-0_<number>.map and MapX-v1-0_<number>_occlusion_3.dat
• MapX-v1-0.289.navmesh
• player.states.289.db and player.states.289.db-wal
• sv.files.289.db and sv.files.289.db-wal

Do not touch player.blueprints, player.identities, player.deaths, player.tokens, clans or relationship, nor their -wal partners.

4. Clear plugin data that holds positions

If the server runs Oxide or Carbon plugins, some of them store coordinates on the old map: home teleports, zones, custom spawn points, saved loot positions. Their data files in oxide/data (or carbon/data) would send people to places that no longer exist. Reset those plugins’ data the way each plugin documents. Plugins that store nothing about the world can be left alone.

5. Start the server and watch the console

On this first boot the server downloads MapX-v1-1.map, finds no save for it and builds a fresh world. It also has to bake the NPC paths and the visibility data for the new terrain, so this start takes noticeably longer than usual. That is normal. Once it is up, join, open the crafting menu and check that your blueprints are there.

Sea Skull from the air. Every building down there is part of the map file; every player base would be in the world save, and goes when the terrain under it changes. Sea Skull.

Why the new map needs a new file name

Two things about how a Rust server handles +server.levelurl decide this, and both are easy to miss.

It names the world save after the map file. A map downloaded from …/MapX-v1-1.map gets the save MapX-v1-1.289.sav. Rename the map and the server looks for a save that does not exist yet, so it starts a fresh world. Keep the old name and it finds the old save.

It does not download a map it already has. The server keeps its copy as Name_<number>.map, where the number comes from the full download address. At start-up it checks for that file first. If you upload a new version over the old one at the same address, the copy is already there, nothing is downloaded, and the server carries on running the old map with the old save on top of it. Everyone joins, nothing has changed, and you spend an evening wondering why.

Same address and name: the old copy and the old save are used again. New name: a fresh download and a fresh world, with the player databases untouched.

A new name per version avoids both problems at once, and it tells everyone, you included, which version is running. Map authors who version their files are doing you this favour on purpose.

Stuck with a map that only ever comes as MapX.map? Rename it yourself before uploading: MapX-2026-10.map works just as well. The name inside the file does not matter to the server, only the name in the address.

Keeping the bases too: rename the save

Everything so far keeps what players earned and gives them a fresh world. When the update leaves the ground where people build untouched, you can keep the world as well: every base, every box and every vehicle. It is done by renaming files.

It works because of the rule from the previous section: the server looks for a save named after the map file. On MapX-v1-1.map it looks for MapX-v1-1.289.sav. Give the old world that name and the server loads it on the new map.

When it is safe

A Rust server does not check that a save belongs to the map it is loading. It loads it, and every entity goes back to its exact coordinates, whatever the terrain there looks like now. So this is safe when the update fixed things like loot, lights, a monument interior or a broken road, and the author says the terrain where players build has not moved. It is not safe when the update reshaped hills, moved roads or rebuilt a monument in a different place: bases end up floating, buried in rock or inside the new building, and the monument’s own pieces can end up doubled or missing.

The steps

1. Save and stop the server, and back up the whole identity folder, exactly as before.
2. Upload MapX-v1-1.map and point +server.levelurl at it, exactly as before.
3. In server/<identity>/, rename the world save to the new map’s name:

   MapX-v1-0.289.sav    →  MapX-v1-1.289.sav
   MapX-v1-0.289.sav.1  →  MapX-v1-1.289.sav.1
   MapX-v1-0.289.sav.2  →  MapX-v1-1.289.sav.2

   Change only the part before .289. The number stays as it is.

4. Remove the files that were calculated from the old terrain: MapX-v1-0_<number>.map, its _occlusion_3.dat and MapX-v1-0.289.navmesh. The server makes them again for the new map.
5. Keep every .db file this time, player.states and sv.files included: the markers still point at the same places and the pictures still have their signs.
6. Start the server, join and walk round the bases nearest whatever the update changed.

Try it on a copy of the server first, with the backup at hand. If something is wrong, stop the server, move the renamed .sav files out and start again: you are back to the normal update, with a fresh world and every blueprint kept. Players accept a planned map wipe far more easily than a base that has sunk into a cliff.

One server, one map name: never rename a save from a different map onto a new one. The coordinates only mean something on the map they came from.

Forced wipe day: the easy moment

On the first Thursday of most months Facepunch releases an update that changes the save format. The number in the save’s name moves on (289 today), the old .sav no longer matches it, and every server gets a fresh world whether it wanted one or not. That makes it the cleanest moment to bring in a new version of your map: the world was going anyway.

Blueprints are a separate matter. The blueprint database keeps its number until Facepunch decides on a blueprint wipe, and when it does, the patch notes say so. A newer build then opens a new, empty player.blueprints file under a new number, and the old one stops being read. Check the notes before a forced wipe so that you can tell players in advance whether their blueprints are going.

The dome on Sea Skull. A monument this size is exactly the kind of thing an update rebuilds, and exactly why bases near it cannot simply be carried over. Sea Skull.

When it goes wrong

The server still runs the old map

The new file went up under the old address. The server found its cached copy and never downloaded anything. Use a new file name, or as a last resort delete the cached _<number>.map and its .dat so the server has to download again.

Players lost their blueprints

Either the player.blueprints file or its -wal was removed, or the update was a blueprint wipe and the server opened a new file under a new number. Put the files back from your backup with the server stopped. If the number changed because of a Facepunch blueprint wipe, the old blueprints cannot be carried into the new file.

Bases are floating or buried

An old save was loaded on top of a map whose terrain changed: either the save was renamed to the new map’s name on an update that moved the ground, or the map kept its old name and the .sav was not removed. Stop the server, move the .sav files out and start again for a fresh world. Blueprints are not affected.

The map markers point at nothing

player.states was kept from the old world. Remove it together with its -wal while the server is stopped; players lose only their markers.

Nobody can join after the update

The new address is not a direct download, or the file did not finish uploading. Paste the address into a private browser window: it should start downloading the .map straight away.

The checklist

• Players were told the date, and that blueprints stay
• The server was saved and stopped, and the identity folder is backed up
• The new map is online under a new file name, and pasting its address starts a download
• +server.levelurl points at the new address, in quotes
• Fresh world: the old .sav files, cached .map, occlusion .dat, .navmesh, player.states and sv.files are out of the folder. Keeping the bases: the .sav files are renamed to the new map’s name and only the cached .map, .dat and .navmesh are out
• player.blueprints, player.identities, player.deaths, player.tokens, clans and relationship are still there, each with its -wal
• Plugins that store positions have been reset (unless you renamed the save to keep the bases)
• Someone other than you has joined and found their blueprints

Maps that are made to be updated

Every update to a map I sell ships under a new file name with the version in it: the server above was running SeaSkull-Badgyver-v1-3-7. Updating is the process in this guide and nothing more, and your players keep everything they learned.

The snow outpost on Sea Skull. Sea Skull.

I build custom maps, monuments, prefabs and plugins for Rust servers, and every map is a single .map file that drops straight into the steps above.