Find Rust server.cfg and the correct identity save folder

Rust keeps each server identity in its own directory. Editing a similarly named folder can appear to do nothing; changing the identity can make an existing world look missing. Locate the running instance before moving or editing any files.

Identify the active instance

Record the startup configuration shown for your service. Find server.identity, including its exact spelling and case. If the panel does not expose it, ask support to identify it rather than trying different names.
In the server files, locate server/IDENTITY/ relative to the Rust installation. Replace IDENTITY with the recorded value. A hosted container may show a different installation root; the relative identity directory is what matters.
Check recent console output and file timestamps against the last successful session. Old identities can remain from previous configurations. Do not delete them just because another directory looks newer.

Save a recoverable copy

Schedule a short maintenance window, announce it, and stop the server normally. Download or back up the complete active identity directory, the startup settings and any Oxide configuration and data. Keep related database files together, including matching journal or WAL files. A lone map save is not necessarily a complete copy of player and plugin state.

Edit server.cfg

The normal location is server/IDENTITY/cfg/server.cfg. Preserve the existing file before making one small change. Configuration lines use console-variable syntax without the command-line plus sign:

server.hostname "My Rust community"

Keep quotes around text containing spaces. Do not paste a complete example startup line into this file. Network endpoints, world parameters and identity values should remain unchanged while testing a hostname edit. Some hosting startup settings are managed separately; record those values too so competing settings can be traced.

Confirm the intended file was loaded

Start the server and wait for normal startup completion. Check the hostname from an external client and inspect the console for configuration errors. Join and verify a familiar building or player location. If the world seems new, stop immediately and compare the identity and startup settings with your notes; do not generate additional saves or attempt a wipe as a repair.

A successful name change proves the selected configuration is being read. It does not prove every setting belongs there. Make further changes individually, checking the relevant variable documentation and the hosting settings each time. Preserve the working copy until a later restart has also succeeded.

If edits disappear

Compare the saved file after a normal restart. A startup template or management integration may regenerate a setting. Report the file path, setting name and time of the restart to support. Remove passwords, access tokens and player database contents from screenshots. Restoring the original configuration and startup values is the first rollback; replacing world files is unnecessary for a configuration-only change.