Rust Server CFG: Find, Edit and Verify the Right File

The safe way to change Rust server.cfg is to find the file used by the running server identity, save a recoverable copy, edit one line, and query the effective value after startup and restart. The file is small; guessing which instance reads it is where the evening gets longer. This guide walks through one reversible edit for a Rust PC dedicated server. It does not give you a gameplay preset or assume a hosting panel exposes the file in a particular place.

Find the server.cfg for the running Rust identity#

The documented relative location is server/<server.identity>/cfg/server.cfg under the server installation. For example, if the process starts with identity friends, look for server/friends/cfg/server.cfg beneath the installation root. Our Rust server identity guide demonstrates a two-process Windows check for matching each identity to its own config and save directory. On Windows, the same relative path uses backslashes in File Explorer; on Linux, it uses forward slashes. The installation’s absolute root depends on how you installed the server.

Facepunch lists the identity’s cfg folder for server settings and documents how server.cfg loads. If you see several similarly named folders, do not create a new cfg path yet. First identify the process that serves your group. A panel can show a server name while hiding its install root, or display a generated editor without exposing the original file. Ask the provider which file its startup process reads and whether a panel template rewrites it.

A file path is only useful if the identity matches. A second test server can have a perfectly valid server.cfg that the public instance never reads. If you are starting from scratch, follow the server setup route and keep its identity and installation notes.

Record the active process before opening the file#

Confirm the server identity and startup route before making an edit. Note the install directory, identity, and whether a script, service, or hosting panel starts the process. If you administer more than one instance, include an unmistakable name for each in your private change notes.

1. Connect to the intended server console

   Use the local server console or an authorized, restricted RCON connection for the instance you plan to change. Do not use a client-side console and assume its commands went to the server.

2. Record its identity and build

   Record the effective server.identity and version output where your server console supports these queries. Save the timestamp and identify which panel instance or service produced them.

3. Match the identity to the file tree

   Check the launch configuration and working directory, then resolve the corresponding server/<identity>/cfg/ directory under that installation. If your provider uses a virtual file manager, ask for the mapping before editing.

Stop here if the identity or file root is uncertain. Editing a file with the right name in the wrong instance produces a frustratingly clean no-op. A panel’s display name is not proof that it maps to the identity string on disk.

This article focuses on the file operation. For a wider worksheet covering launch arguments, panel fields, plugin settings and precedence checks, use Rust Server Settings: Build a Configuration That Persists. It records an observed conflict between a launch value and an identity file on one dated Windows build; use that as a reason to check your own process, not as a universal precedence guarantee.

Make a recoverable copy before changing one line#

Copy the active server.cfg before editing and keep the copy private. Preserve the exact previous file and note when you made it. If your panel has a configuration template, record whether it can recreate the file during startup; a local copy cannot prevent a template from replacing your edit.

If the provider advises stopping the server before a file change, perform a graceful stop first. Otherwise, avoid applying a second console command while you are editing. The value in this procedure will be checked after a normal restart, so a runtime-only change would muddy the result. You do not need a world wipe or a world-file operation to edit this text file.

Keep configuration recovery separate from world recovery. A copy of server.cfg restores text settings; it does not restore the map, player data, or plugin state. If the edit changes an unexpected value, use the saved file rather than layering on additional overrides.

Write a small server.cfg line with the right syntax#

A server.cfg entry is a console-variable name followed by its value. In this file, omit the + prefix used for a launch argument. Put each intended change on its own line, and quote a string that contains spaces, as in Facepunch’s example:

server.hostname "Friends Rust Server"

The command-line form looks different:

+server.hostname "Friends Rust Server"

These examples show where the prefix belongs; they do not imply the file always wins when both sources define the same value. The official server creation guide says the file is read at startup and shows a quoted hostname. A prior controlled test documented in C01 observed a different result for one conflicting Windows launch argument, so keep the value in one persistent source where possible and query what your actual build uses.

For a safe first edit, choose a non-destructive display setting such as the hostname. Change only that line, leave unrelated entries in place, and save the file using the provider’s documented editor or a plain text editor. Do not copy a large settings preset from a search result: it can change admission, ports, map generation, or other behavior outside this task.

Before closing the editor, confirm the filename is exactly server.cfg and not server.cfg.txt. Some editors hide known extensions. Then compare the changed line with your backup so you know no neighboring settings disappeared.

Check the effective value on the intended server#

After the server starts, query the same hostname from its authorized server console and compare the response with the line you saved. Record the answer alongside the version, identity, and time. This checks what the process is using, rather than what the editor displays.

For example, query the convar name without supplying a replacement value:

server.hostname

The C01 test used this query style to read values from the actual Rust process. If your console returns help text, an error, or a value from another instance, stop and use the console method documented for your server. Do not change the value at runtime and treat that response as proof that the file was loaded. The check you want is a read of the value already held by the server.

Avoid using server.writecfg as a shortcut for saving this one edit. Facepunch lists it as a command that writes server convars/settings to cfg files, which is broader than changing one known line. Save the intended text directly, keep the previous copy, and verify what loads. Current Facepunch documentation checked for this guide does not document server.readcfg; do not rely on that command to apply an edit without a supported source and a successful test.

If the response does not match, do not add a second hostname argument yet. Check that your console belongs to the right server, that the active identity points to the file you edited, and that the panel has not regenerated a template. The broader settings guide explains how to compare competing sources without assuming a universal load order.

Repeat the check after the normal restart#

A file that looks correct can still be ignored or replaced. Use the same restart route your group normally depends on, then query the value again. A manual launch can prove only that manual launch; a panel restart needs its own check if that is how you operate the server.

1. Save the exact file path and the value the running server returned before stopping.
2. Gracefully stop the intended instance using its normal service, script, or panel control.
3. Confirm the old process has exited before another instance starts.
4. Start the server through the same route you recorded earlier and wait for its normal startup-complete signal.
5. Query server.hostname again from that server’s console and compare it with the saved file.

If the value returns as expected, record that this file and restart route loaded the setting on this build. That is useful evidence for your own server, not a promise that every convar or provider panel behaves the same way. If it does not, check for a duplicate launch argument, a panel-generated file, or a different server identity before changing anything else.

Some settings have their own activation requirements or can affect a world. This walkthrough deliberately uses a display value. Do not use it to infer how seed, world size, ports, access rules, or plugin files apply; those need their own documented procedure and recovery plan. For the wider question of where a setting belongs, continue with the Rust settings source worksheet.

If managing a PC server’s configuration files does not fit your group, we recommend Game Hosting’s Rust PC hosting with an integrated panel and free backups. Confirm the exact file access your workflow needs. Console Edition is separate and cannot join this PC server.

Restore the previous file when the check fails#

If your value disappears, a different setting changes, or the server fails to start, restore the saved copy before experimenting with more overrides. First confirm the target identity and file path again; then restore the backup using the same editor or provider tool and restart through the same route.

1. Stop the intended instance cleanly

   Use the documented shutdown method and confirm that process has exited before replacing the file.

2. Restore the matching backup

   Replace only the server.cfg for the identity you recorded. Keep the failed version separately if you need to compare it, and do not copy it over another server’s file.

3. Start and query the old value

   Use the same startup route, wait for startup to finish, and query the hostname again. Record whether the previous value returned.

If the restored value still does not appear, stop editing and compare the launch arguments, active identity, panel template, and console target with your notes. A persistent reset after one clean edit is a useful diagnostic; it is not a reason to rewrite the whole config. Keep your diff and timestamps for the administrator or provider who owns the startup process.