Move a Rust Server to a New Host Without Losing Progress
Move a Rust PC server between hosts using a verified data manifest, compatible destination and controlled player-address cutover.
You will need
- Access to the current Rust server account and its export or file options
- The active server identity, build, map, framework, plugin, and custom asset inventory
- Written import requirements from the destination host
- An independent recovery location and permission to test a private destination
To move a Rust server to a new host without losing the progress you care about, confirm that the source can export the active server identity, that the destination accepts the same data and build, and that an isolated restore passes before players switch. Rust stores world, player, configuration, framework, and Rust+ data separately, so “the save file” may not be a complete move. This runbook gives you a source manifest, compatibility checks, a private rehearsal, and a controlled cutover. It covers PC Rust and does not promise every provider can import every setup.
Define which Rust server state must move#
Write down what your group expects to find after the migration. A saved world can mean the map and bases, learned blueprints, player records, admin access, plugin data, a custom map, or Rust+ notifications. Those parts are stored and licensed separately; ask about each one instead of assuming a folder copy preserves the whole service.
Facepunch documents the usual server.identity contents in its server file reference. The .sav file contains world state such as entities, buildings, and deployables; .map contains map terrain and monuments; blueprint and other player data have separate files; and cfg holds settings and admin-related files. Rust database files can also have SQLite -wal companions. A custom map, plugin database, server image, or panel-managed setting may sit outside the paths your provider exports.
| State to keep | Include in the inventory | Ask the hosts to confirm |
|---|---|---|
| World and map | Active identity, .sav, .map, seed, size, and custom-map name |
Which exact files and map assets are included and accepted |
| Players and blueprints | Current player and blueprint database files, plus related database files | Whether these are exported together and supported by the destination build |
| Settings and access | cfg, server configuration, admin and ban lists, launch settings |
Which values move and which must be recreated in the destination panel |
| Framework and plugins | Framework/version, plugin list, plugin data, permissions, and licenses | Whether the same versions and data format are supported, and who performs the import |
| Rust+ and custom assets | companion.id, signs/images, custom maps, and any service-specific files |
How restricted identities, licenses, and map dependencies are handled |
| Credentials | RCON secrets, API keys, FTP/SFTP credentials, and private tokens | A safe way to rotate or re-enter secrets without including them in a public archive |
Use this list as a scope check, not an instruction to copy every file blindly. Keep companion.id private: Facepunch says it represents the server’s Rust+ identity and should not be shared or used by multiple servers. Confirm the active identity rather than using a similarly named test folder. If you need help classifying backup, restore, wipe, and migration work, start with the Rust data management guide.
Inventory the source identity before choosing a destination#
Record the source before you pay for another plan or cancel your current service. Capture the exact identity name and provider path, current server build or protocol, map name and seed/size, operating system, framework and plugin versions, custom-map dependencies, effective configuration, public address, and the date your export access ends. Remove passwords and private tokens from screenshots or notes.
Rust can run more than one identity from the same installation, which makes a stale test server an easy mistake. Compare the active server’s startup configuration and provider view with the identity directory that actually contains its current save. Record both the literal identity and the provider’s export path, then ask support to confirm that the archive comes from that identity.
Check the current Facepunch server setup reference for the way identity and configuration are selected. A destination panel may map settings to different controls or start arguments. Keep a redacted copy of the effective values, including map and framework details, so the receiving operator can tell you what must be recreated instead of uploaded.
Also ask how long you can download the source archive, whether support has to prepare it, whether there is an export fee, and whether transfer access changes when the account is canceled. The pre-signing Rust host checklist helps compare those written answers before you commit. Do not rely on a button labeled “backup” until you know which identity it contains and whether you can retrieve it.
Confirm destination compatibility and the import route in writing#
The destination should answer with a specific import plan for your recorded source, not a generic statement that Rust is supported. Ask which build/protocol it will run, whether it can load the current save, what server identity and directory it will use, and which map, database, configuration, and framework files it accepts. Ask for its required archive format, maximum upload size, staging options, who performs the work, expected downtime, and any extra charge.
| Destination question | Evidence to save |
|---|---|
| Which Rust build/protocol will load this save? | Version/build response and any update timing restrictions |
| Which identity path and files will be imported? | Accepted file list, destination identity, and excluded items |
| Can the custom map and framework/plugin versions run there? | Version support, dependency notes, and license or creator permission |
| Can you test in a private, isolated instance first? | Rehearsal appointment, test identity, and cleanup/retention terms |
| Who updates the address and panel settings? | Written owner for each action and the new endpoint details |
Do not infer compatibility from another host’s tutorial. Panel-specific paths and upload promises describe that provider’s service, not a universal Rust import route. Windows-to-Linux path case, framework state, paid content, and custom-map entitlements can require separate decisions. If either host cannot explain how a required item will be exported or recreated, mark the migration no-go until the owner resolves it.
Avoid promising zero downtime. The destination may need the same build, an additional setup step, or a provider-assisted import. You can plan a short handover window only after both sides explain the sequence and your group knows which server is authoritative while the test runs.
Rehearse the restore with one isolated destination identity#
Do a rehearsal before the final maintenance window. Restore a copy into an isolated destination identity that players cannot mistake for the live world. Use the same supported build the providers approved, preserve a separate recovery copy, and never run a duplicate live Rust+ identity. If the source host or destination cannot offer a private test path, record that limitation and decide whether the added risk is acceptable before authorizing the cutover.
The data management guide’s stopped-state restore checklist explains why a clean stop and complete identity matter. In its documented local test, the complete stopped identity matched across source, backup, and restored folders, and the restored same-build instance logged that it spawned saved entities before startup completed. That proves one isolated restore scenario; it does not prove a third-party panel import, another operating system, plugin recovery, or a production player’s experience.
Prepare the test copy
Keep the source live only if the rehearsal uses a known consistent backup. Give the test instance a distinct identity and private address, and make sure it cannot send public listings or Rust+ notifications as the production server.
Start privately and inspect expected state
Check the agreed map and seed, representative buildings, expected player/blueprint records, admin access, required plugins, and custom assets. Treat an item as unverified if the provider cannot show it in the staging test.
Record the acceptance result
Save the build, identity, import scope, startup result, checks passed, and exceptions. A green panel indicator or a running process is not enough if the world, player data, or permissions your group needs are missing.
If the test loads a fresh map, misses expected data, or reports a protocol problem, stop the rehearsal. Preserve the source and recovery set; do not rename an old save to try to force compatibility. Facepunch’s file guide says the numeric suffix identifies the protocol and warns that using a renamed old .sav to bypass a forced wipe is dangerous and ill-advised. Check the latest Rust update and forced-wipe announcement before trying again.
Freeze the source and capture one final consistent set#
Only take the final copy after the rehearsal and the source/destination plan pass. Tell players when the source will stop accepting changes. Pause scheduled jobs or automated tasks that could write to the identity, stop the server cleanly, and confirm the process has exited before making the final export. Keep the whole agreed identity and related dependencies together, then verify the archive against the source manifest before upload.
Rust uses database journaling, so copying a database while it is active can leave its current data split between the main file and a -wal companion. Facepunch documents these WAL files and the separate identity contents; it does not promise that every hosting panel’s live backup is application-consistent. Use a cleanly stopped source for a manual final export, or get the provider to explain how its backup captures active databases. Avoid selective file cleanup or deletion during a host move.
Store the verified archive somewhere independent from both server accounts, protect it with appropriate access controls, and redact secrets from any support ticket or public troubleshooting post. Record the capture time, source identity, build, included paths, excluded items, and the destination operator who received it. If verification fails, recapture from the source before cutover instead of continuing with a partial set.
Verify the destination before players follow it#
Keep the imported destination private while you compare it with the agreed acceptance sheet. Check the build/protocol and map first, then inspect representative buildings and world state, expected player and blueprint information, admin/ban lists, configuration, framework/plugin behavior, and custom map dependencies. Have the person responsible for each item sign off. If a feature was not included in the import or could not be tested, tell the group plainly and decide whether the difference is acceptable.
Rust+ needs its own check. Facepunch documents companion.id as a unique server identity and says not to reuse it on multiple servers. Keep it protected and ask the destination provider how it handles the file, pairing, and notifications. Test the expected Rust+ behavior on the destination before reopening admission; do not assume that moving the game world also preserves every pairing or push notification.
Before players join, check that the destination has the intended access and connection settings, that the correct public endpoint is available, and that a licensed PC Rust client can reach it if your acceptance plan includes a client test. Do not describe a server start as proof that players, plugins, or Rust+ work. If the group cannot confirm a required item, keep the destination private and hold cutover.
Cut over once and keep a rollback point#
Choose a single authoritative server for the group. Once the destination passes acceptance, tell players the agreed time to use its new endpoint and update any invitations or community instructions. Keep the source stopped and retain the verified recovery point until the owner signs off; do not let players continue on both worlds, because their progress can diverge immediately.
| Decision | Action |
|---|---|
| Required world and player checks pass | Announce the destination endpoint and allow players to join there |
| A required file, plugin, or permission is missing | Keep the destination private and return to the provider with the recorded evidence |
| The destination cannot load the accepted source format | Keep the source and recovery set intact; stop the migration until a compatible route is confirmed |
| The group accepts a known limitation | Record what will not transfer, who approved it, and when the source may be retired |
If rollback is needed, stop the destination first and agree which copy is authoritative before restarting the source. Any progress made after the destination opens may not exist in the old copy, so communicate the rollback boundary before players resume. Retire old address forwarding or source access only after acceptance and the agreed recovery period; if the move started on a home server, Rust port-forwarding guidance covers the separate network changes.
For a managed Rust PC destination, we recommend Game Hosting’s Rust hosting with an integrated panel and free backups. Confirm the import access and exact files required, then test the destination before ending the original service. Do not assume migration assistance is included. Console Edition worlds are not PC server imports.
Quick answers
How does a Rust server transfer work?
Inventory the active identity, confirm what the destination accepts, rehearse a private restore, capture one final consistent copy, and open the new address only after the group accepts the result.
Which Rust files preserve a server?
Rust stores map, world, player, configuration, and companion data separately under the server identity. Confirm the active file set with Facepunch’s current reference and both hosts.
Can I keep the same IP when I switch Rust hosts?
Do not assume it. Ask both providers what address changes, test the destination endpoint, and send players the new connection details after acceptance.
Can I reuse a Rust save after a forced wipe?
Check the current build and save protocol. Facepunch warns against renaming an old save to bypass a protocol change.