Change a Rust Server Seed Safely at Wipe Time: Keep the Scope Clear
Change a Rust server seed at wipe time with recorded map inputs, a stopped full backup, and a new-world check that avoids unsupported retention claims.
You will need
- Rust PC server administrator access
- Access to the active identity and startup configuration
- Independent storage for a complete recovery copy
- A compatible isolated destination for a restore check
- Agreement about blueprint and plugin data
To change a Rust server seed at wipe time, record the new procedural map inputs, back up the stopped server identity, and verify the new world before removing any old files. A seed change selects a different generated map; it does not automatically decide whether blueprints, plugin records, or other player data should reset. This reference covers Rust PC procedural maps and a cautious verification path. It does not prescribe a universal file deletion list or claim that every player or plugin record survives.
Confirm that the server uses a procedural map#
Confirm the map type and actual launch inputs before planning a seed change. A custom map uses a map URL and has a different configuration path; changing a procedural seed does not replace that workflow.
Facepunch’s server setup guide uses +server.level “Procedural Map”, +server.seed, and +server.worldsize for a procedural world. Its documented ranges are 0–2147483647 for the seed and 1000–6000 for world size. The custom map guide says to remove procedural seed and size parameters when using a custom map URL.
Read the values from the real process configuration and the correct server.identity, not from a note or an old panel screenshot. If the panel writes a config file while the service starts with command-line arguments, record both and confirm which values the running server reports. Facepunch documents server.identity as the folder that contains the server’s files.
| Record before changing anything | Why it matters |
|---|---|
| Map type and source of the setting | Prevents editing a procedural seed when the server actually uses a custom map. |
| Current seed and world size | Gives you a baseline for the old world and a rollback record. |
| Exact identity and data-folder path | Prevents backing up or changing a neighboring server. |
| Rust server build and startup time | Helps distinguish a new map from a stale process or mismatched save. |
If the process inputs do not match the values you expected, stop here and resolve the configuration source first. A new seed in an unused file is not a changed running server.
Agree on the new map and data policy#
Write down the new seed, world size, map type, and planned change window before editing the server. Ask the group whether it wants a new terrain layout only, a deliberate blueprint wipe, or a plugin-specific reset. Those are separate choices.
Facepunch’s Map Data reference says procedural map generation uses map type, size, and seed. The seed is not a map preview or a guaranteed improvement: review the candidate terrain before committing your group to it. If you are still choosing a seed or comparing travel layouts, use the Rust server map-size guide for that selection step; this page covers applying a choice.
If the group also needs to choose a wipe date, check the Rust wipe schedule guide. A calendar does not decide whether blueprints or plugin records should reset.
Keep a small change record:
| Field | Example record |
|---|---|
| Old inputs | Procedural Map, current seed, current world size |
| New inputs | Procedural Map, approved new seed, approved world size |
| Reset decision | Map change approved; blueprint/plugin decision stated separately |
| Acceptance owner | Administrator responsible for checking the new world and data policy |
If nobody can say what should happen to blueprints or plugin state, do not infer the answer from the word “wipe.” Agree on those outcomes first. For broader backup and operation decisions, see Rust server data management.
Back up the stopped identity before the change#
Create a complete recovery copy while the server is stopped, then verify that the copy can be used on a compatible isolated server. A list of files or a green backup status is not a restore test.
Pause other maintenance jobs
Record the maintenance window and pause any separate wipe, update, restart, or backup job that could touch the same identity. Keep the exact identity and folder path with the change record.
Stop the intended server cleanly
Use the server provider’s supported stop path. Confirm that the intended Rust server process has exited before copying files. If the process does not stop, do not treat a live folder copy as a consistent recovery point.
Copy the complete identity and record its build
Copy the whole identity folder to independent storage rather than selecting files by a guessed filename pattern. Record the Rust build, map inputs, copy time, and any external plugin database that needs its own backup.
Restore the copy in isolation
Use a separate test identity and compatible Rust build. Confirm that it loads the intended old world before proceeding. Keep the production copy untouched if the restore fails.
If you prefer an integrated panel and recovery controls, Game Hosting’s Rust PC service includes a game panel and three backup slots. The slots provide recovery options; they are not proof of a selective seed reset or a guaranteed restore, so check the current backup scope and verify a restore before relying on it.
Change the Rust server seed at wipe time without renaming old saves#
Change only the approved procedural inputs in the startup source you identified. Do not rename an old save to make it look compatible, and do not use a broad delete command as a shortcut for a new map.
For example, the relevant launch values can look like this:
+server.level "Procedural Map"
+server.seed 4321
+server.worldsize 1000The example seed and size are valid values, not a recommendation for your group. Substitute the approved seed and size, then review the complete launch command before starting the server. Facepunch documents the procedural map file pattern as MapType.Size.Seed.map; the old and new seed values therefore identify different generated map filenames. That pattern explains file naming, not which files an administrator should delete.
Leave the old files in place while you validate the new world. If startup still reports the old seed or the map type is wrong, stop the process and inspect the real launch source. Do not keep changing folders until the server happens to load something.
Verify the new map before reopening the server#
Check the active startup values, generated map filename, and server startup result before inviting the group back. A changed config line alone does not prove that the new world loaded.
After the new server starts, capture the actual identity, map type, seed, world size, build, and startup log. Facepunch’s file reference describes .map as terrain and monuments and .sav as map data, entities, buildings, and deployables. Check for a map filename matching the approved procedural inputs, then inspect the world in a private or otherwise controlled session if your setup supports it.
The current disposable test used Rust Dedicated build 25681086, protocol 2634.289.1, a copied identity, seed 4321, and size 1000. The server logged those launch values, generated proceduralmap.1000.4321.289.map, and reached Server startup complete. An authenticated loopback server.save then wrote a seed-4321 .sav; the copied seed-1234 .map and .sav remained in the test identity. No player joined, and no player or plugin retention was tested. This is evidence for that build and isolated test, not a benchmark or a promise about another host’s panel.
| Check | Pass condition | If it fails |
|---|---|---|
| Running identity | It matches the path you backed up and the approved server. | Stop and identify the actual process before touching files. |
| Map type, seed, and size | They match the approved procedural inputs. | Stop, fix the startup source, and review the command again. |
| Generated map | The filename and visible terrain correspond to the new inputs. | Keep the server closed to players and investigate which files or map source loaded. |
| World save | A save for the new map appears after a confirmed save operation. | Do not remove the old recovery set; inspect startup and save logs. |
Only tell players the map is ready after the agreed acceptance check passes. A server can start successfully and still use the wrong identity or the wrong map.
Keep blueprints and plugin data as separate decisions#
Treat map generation and player or plugin resets as separate approvals. Facepunch documents player.blueprints as a separate file and warns that renaming an old protocol-suffixed save to bypass a forced wipe is dangerous. Those file roles do not establish that every player, Rust+ token, database, or plugin record is compatible with every map or update.
| Data | What the available evidence says | What you still need to verify |
|---|---|---|
| Terrain and monuments | Stored in the .map file; procedural inputs include type, size, and seed. | That the new map loaded from the approved inputs. |
| World entities and buildings | Stored in the .sav file with map data and deployables. | Which world progress your group intentionally gives up and how rollback works. |
| Blueprints | Facepunch lists a separate player.blueprints file. | Verify a known player’s blueprint state in game if retention matters. |
| Plugins and external services | Not covered by the native map filename pattern. | Follow each plugin/database’s backup, compatibility, and reset procedure. |
The October 1 Facepunch update notice schedules a mandatory server and client update for October 22, 2026; it does not itself specify a seed change or blueprint reset. Read the current Facepunch update notes near the maintenance window and make a separate update decision. A required update is not permission to delete or rename old data.
Keep the rollback copy until the group accepts the world#
Retain the old recovery set until an administrator confirms the intended identity, map, save, and player/plugin policy. Record the new map inputs and acceptance time next to the backup location so another admin can tell which set is old and which one is active.
If the new seed loads the wrong map, the save is missing, or expected player data is absent, stop before cleaning up old files. Use the compatible recovery copy and investigate the startup source or plugin behavior first. Do not restore a save across an incompatible forced-wipe protocol by renaming it; follow Facepunch’s current compatibility guidance.
This procedure is for Rust PC dedicated servers. It does not describe Console Edition hosting or promise that a provider panel performs the same steps. Keep the record, verify the recovery path, and reopen only after the administrator responsible for the change accepts the result.
Quick answers
Does changing a Rust server seed wipe everything?
A new procedural seed selects a different map. Facepunch documents separate map, world-save, and blueprint files, but that does not prove every player or plugin record survives; verify the data your group needs.
Can I change a Rust seed without changing the map?
No. A procedural map is generated from its map type, size, and seed. Changing the seed requests a different generated map, so plan a map change and recovery point.
Should I delete the old Rust save before starting the new seed?
Do not delete or rename old files until the new map passes your acceptance checks and the recovery copy is verified. The filename pattern is not a safe deletion list.
Is changing a seed the same as a forced wipe?
No. A seed change is an operator-selected map change. Check Facepunch’s current update notes separately; a mandatory update notice alone does not define your server’s wipe policy.