Rust Server Identity: Keep Each Instance’s Save Separate

server.identity selects the Rust PC server’s data folder. If you run a second instance, assign it a different identity and verify that each live process reads its own config, map and save before touching an existing world. This guide gives you a process-to-folder register and a safe check for two identities. It does not assume your hosting panel uses the same file root as a local install, or that one hosting plan includes multiple servers.

Find the identity the Rust process actually runs#

Read the value from the running Rust server, then match it to the command or service that started that process. A list name, panel label or server.hostname value can help you recognize an instance, but it does not prove which internal data folder the process uses.

Facepunch’s server setup guide uses the launch setting +server.identity and explains that its example creates a named directory below the server installation. On a local server, query the server console or restricted RCON with:

server.identity

Record the reply beside the executable path, working directory and launch source. If the server is managed by a provider, find the identity field or ask support which value reaches the process and where that process stores its server files. A panel may use a container root or mount that is not visible in the panel’s file browser.

1. Choose the running process

   Match the process to its PID, service entry, panel instance or console connection. Do not query a stopped copy while assuming it represents the public server.

2. Read server.identity

   Query the selected process and save the exact response with the date. If the panel does not expose the value, treat it as unknown until the provider confirms it.

3. Record the launch root

   Note the executable or container, working directory and any mount or file-manager root. These details make a relative server/<identity>/ path traceable.

The running value and the actual file root are the two pieces you need before opening a folder. If either one is unknown, stop before editing or moving files.

See what Rust server identity changes#

The identity names a server’s data directory; it is not the server’s public name, a player ID or a Rust+ login. Facepunch’s server file reference lists the kinds of files inside an identity folder.

The world files are only part of the identity. Copying a .sav by itself can leave out player databases, configuration or pending database writes. If you are tracing a setting rather than isolating two worlds, C01’s Rust settings checklist helps you separate launch arguments, identity config, panel fields and runtime values. For a single file’s location and syntax, see the Rust server.cfg guide.

Assign a distinct folder to every live process#

Use a stable, unique identity for each concurrently running instance. In a local launch command, that means setting a different value for each server process:

+server.identity "main"
+server.identity "staging"

Those two lines belong to separate launch commands; do not paste both into one server’s command line. A panel may store the value in a field instead. Use the provider’s documented field and confirm the result with server.identity after startup.

Write one row per process before you start or change anything:

The rows should point to separate identity folders, and each process should have a separate launch record. Distinct names alone do not prove file isolation: a wrapper can start both processes from an unexpected working directory, and a panel can mount a different host path. Keep the installed files, working directories and process targets in the register too. Port allocation, RAM and CPU planning belong to your multi-instance setup; this identity check does not show that the machine can handle a particular workload.

Verify each instance loads its own config and world#

Use a disposable test world before applying the same check to a server with player progress. Verify both the runtime values and the files the process actually creates; a folder name typed into a panel is not enough.

1. Prepare two disposable identities

   On a private test machine, use separate identity names, seeds and ports. Bind the test servers to loopback or keep them behind a firewall so players cannot join. Do not copy a production companion.id into either identity.

2. Give each config a harmless marker

   Add a different server.hostname value to each identity’s own cfg/server.cfg, then start both processes from their intended launch sources. Use an obvious test name, not a production listing.

3. Query each process independently

   Through each process’s own console or local RCON, record version, server.identity, server.hostname, server.seed and server.worldsize. Compare the replies with that row in your register.

4. Inspect the matching directories

   Under the actual server root, confirm each server/<identity>/ contains its own marker and map/save files with the intended seed and world size. The .sav may not exist until Rust has completed a save, so check again after the first successful save.

5. Stop the disposable processes

   Stop through the server’s normal console or service control, wait for its save/quit messages, and confirm both processes ended before copying or inspecting the final files.

On October 2, 2026, Game Hosting ran this check with two simultaneous loopback-only Windows RustDedicated processes on release build 25670169 (protocol 2634.289.1). The processes returned identities c03-alpha and c03-beta, distinct hostname markers, seeds 3301 and 3302, and world size 1000. Each wrote its own proceduralmap.1000.<seed>.289.map and .sav under its matching server/<identity>/ folder. This proves the vanilla Windows path tested here. It does not prove a provider panel, Linux service wrapper, paid plan with multiple instances, Rust+ pairing or restoration of a world containing player-built structures.

If both RCON sessions report the same identity, a marker appears under the wrong folder, or the expected save is missing after a completed save, do not change the production world. Check the launch source, process target, working directory and service mounts first. Keep the last known-good identity untouched while you investigate.

Protect an existing world before changing identity#

Changing an identity can make a server look empty because the process now points at a different directory. That does not mean Rust erased the previous world. Stop and identify both the old and new folders before taking any repair action.

Use this recovery-safe sequence:

1. Record what the current process uses

   Save its server.identity, launch source, working directory, map settings and the exact filenames present in that identity folder.

2. Stop the server and take a complete copy

   Use the provider’s backup tool or copy the full identity after the process has stopped. Keep the copy separate from the folder you are investigating.

3. Compare before restarting

   Check the intended seed, map size, filename and protocol against the existing world. Do not rename an older .sav to bypass a protocol change; Facepunch warns that an old save may not be compatible.

4. Restart only after the mapping is clear

   Start one process, query its effective identity and inspect the files it opens. Confirm the intended world before allowing players back in.

If the process is already running but loaded an old world, compare its current identity and inputs with your register and Facepunch’s file reference before changing anything. This guide does not provide a save migration or recovery guarantee.

Keep Rust+ identity separate from world copies#

companion.id is separate from the map seed and the server.identity name. Facepunch’s Rust+ server documentation says to keep this file with its server and backups, not give it to someone else, not use someone else’s file and not reuse the same file across servers. The documentation warns that misuse can disrupt Rust+ and require players to pair again.

The two identities serve different purposes. A map/save check cannot prove that Rust+ pairs correctly, and this article’s local test did not pair the companion app. Follow Facepunch’s instructions for Rust+ without exposing or reusing its identity file.

Choose a managed Rust PC route if you do not want to maintain the host#

If your goal is to stop maintaining the physical server and its restarts, the Game Hosting Rust PC service combines a game-specific panel with three backup slots for settings or file changes. Check the plan details against the number of server instances you need; the product page does not turn the local two-process test above into a multi-instance-per-plan promise.

That managed route is optional. If you keep the server yourself, the register is still useful: it tells the next admin which process, identity and backup belong together before they edit a config or investigate an unexpected world.

Record a handoff another admin can verify#

Finish with a record that names the process and the expected data, not just a folder:

If a setting’s value changes unexpectedly after restart, compare its launch argument, identity config, panel field and runtime value using the Rust server settings worksheet. If you only need to locate a server.cfg, use the path and safe-edit guide. Keep this page focused on proving which identity owns each process and world.