Rust Server Settings: Build a Configuration That Persists

To make your Rust server settings repeatable, give each value one intended persistent source, read what the running server actually uses, and check again after a controlled restart. A saved file alone does not prove the setting took effect. This guide gives you a configuration worksheet and a small, measured Windows example that caught a disagreement with the documentation. It covers an existing Rust PC server, not Console Edition or a recommended gameplay preset. If you still need the server itself, first choose and verify a Rust hosting setup.

Inventory the sources of your Rust server settings#

Identify every place capable of supplying a setting before changing it. A console response, a text file, and a panel field can all show different values without referring to different setting names. Your first task is to connect each source to the process your players actually use.

For the disposable identity used in our test, the file was below the server installation at:

server/c01-proof/cfg/server.cfg

The Facepunch setup documentation describes this identity-based configuration file and its startup loading. A panel’s file browser may begin inside that directory, so do not create an extra directory tree simply to make its display match the example.

Check the running identity and the real launch method together. A similarly named desktop shortcut or a backup folder is weak evidence. On a managed service, ask which panel fields generate files and when they run. Mark that answer unknown until the provider documents it or you observe it. Our local test did not exercise a hosting panel.

Record a baseline before changing behavior#

Create one row per intended behavior, then fill the observed columns from your server. Keep desired values separate from observations so a plan cannot quietly become a claimed test result.

Use an authorized server console or RCON session to collect these individually:

version
server.identity
server.hostname
server.description
server.seed
server.worldsize

In our test, entering those convar names without a new value returned the effective values. Record the complete version response with the date, installation, and identity. A screenshot of a panel field is not equivalent to a response from the process.

Also retain the previous source contents before editing. Configuration snapshots can contain secrets; store them with appropriate access rather than pasting the whole launch command into a public issue. The shared worksheet can reference a private recovery location without exposing credentials. Your baseline is ready when another administrator could find the same process, sources, and previous values from these notes.

Give each value one owner before testing precedence#

Avoid defining the same setting in multiple persistent places when you can choose one. The reason is practical: our current-build test did not follow the precedence described by the wiki.

On September 13, 2026, we installed the public Windows dedicated package, Steam build 25230300, and queried release changeset 163794, protocol 2633.288.1. Its reported build date was September 10. The disposable instance used loopback listeners, no plugins, identity c01-proof, seed 1234, and world size 1000. Those map values were test inputs, not recommendations for a group’s world.

We placed this name in the identity’s file:

server.hostname "C01 persistent baseline"

For the first pair of starts, the launch command also contained:

+server.hostname "C01 launch value"

The file’s separate description value loaded on every start, confirming that we had selected the active file. The wiki says the file takes priority over command-line values; this hostname test produced the opposite result. Treat the table as evidence for this build, setting, and launch route, not a replacement universal rule.

The useful fix was to remove the duplicate definition. With one persistent hostname source, the baseline returned after restart. Other variables, service wrappers, and panel actions need their own checks. Do not conclude that every temporary command persists, or that one save command writes every setting, from a successful runtime response.

Separate identity, listing, and admission rules#

Record identity, public presentation, and permission to join as different concerns. A name that says “private” does not implement the access policy, and changing a display name should not become an accidental change of data identity.

Keep your identity stable while validating routine listing changes. In the worksheet, record the desired name and description separately from the identity path. Then check the result through a player-facing view when a client is available. Our RCON test proves the server’s effective text value; it does not certify how quickly an external browser updates its cached listing.

Use Facepunch’s server tag definitions when describing the server. Tags communicate characteristics to players. A tag describing weekly wipes is not evidence that a scheduled wipe operation exists, and a PvE description is not a test of every damage interaction. The person writing the listing should use the same accepted behavior record as the person configuring the game.

Facepunch documents a combined hidden and whitelisted server procedure. Follow the complete access method appropriate to your server instead of borrowing one command and assuming the rest. Keep admission results pending if no suitable player accounts are available for testing.

Approve map changes separately from routine settings#

Treat a different map or identity as a world decision with its own recovery plan. Do not mix it into a name-change experiment and then wonder which change caused a different result after restart.

Before approving map work, record the current identity, seed, size, map type, build, and the world your players expect to return to. For a custom map, add its source, permission to use it, required game build, and any dependencies. These are review fields, not a command sequence for replacing an existing world.

Ask the group what the map must provide: expected travel, required monuments, building locations, and how often they want encounters. A small test map that starts quickly is not evidence that those needs are met. Inspect the intended map before accepting it for real play, and keep that acceptance separate from whether its configuration values load correctly.

Facepunch’s server file guide distinguishes map terrain, saved entities, player databases, and other identity data. A copy of configuration text cannot substitute for a consistent world backup. Likewise, a saved world does not prove that every runtime setting will return after a restart.

If a routine restart unexpectedly selects a different world, stop the rollout and compare the recorded identity and sources. Preserve the available data while investigating. Deleting files to get a clean start removes evidence and can turn a configuration mistake into lost progress.

Identify native controls before adding plugins#

Check whether the current server exposes a native control for the exact behavior you want. Similar names can have different scope, and a control specific to one game mode does not establish a global setting for every mode.

These discovery queries returned matching command information in our tested build:

find server.pve
find relationshipmanager.maxteamsize
find gather

The results included native PvE and team-size controls. The gather search also returned a Softcore-specific gather variable among unrelated matches. That is a useful warning against copying the first plausible result into a general configuration. Read the current help and test the applicable behavior before assigning a value.

Command discovery only confirms that the server exposes those controls. We did not use player clients to test damage rules, team behavior, or resource yields, and these queries do not prove a complete gameplay preset. Write an acceptance check for the actual outcome, including any exceptions your group cares about.

If a plugin is needed, give it its own configuration row and recovery notes. uMod’s configuration documentation describes plugin JSON configuration, commonly under the framework’s config directory. That is a different source from native server convars. Record the plugin’s maintained instructions for applying changes, its version, and any separate data files it needs.

Use a maintainable plugin stack register to connect those configuration rows to dependencies, permission owners, and the checks required before an update.

Finally, review Facepunch’s Community and Modded rules for the actual modification. Classifying the server by framework installation alone misses what the plugins do. Your listing should describe the accepted configuration honestly.

Restart and accept only the values you verify#

Accept a configuration change only after the intended source produces the intended result through the restart route you normally use. Test in a disposable instance where possible, or agree on a maintenance window and recovery plan before interrupting players.

1. Capture the current instance and recovery point

   Record the version, identity, effective value, source contents, and previous working configuration. Confirm that your console belongs to that instance. Preserve world data separately when the change can affect it.

2. Edit one intended persistent source

   Make the smallest change that meets the requirement. Resolve duplicate definitions for that value without removing unrelated settings. On a panel, establish whether a file edit or a panel field is the supported source.

3. Start and read the effective value

   Wait for startup to complete, query the setting, and record the response. If it differs from the desired value, investigate before adding another override somewhere else.

4. Repeat through the normal restart route

   Use the documented graceful stop method, confirm the process exits, and start it again through the same service, script, or panel route. Repeat the version, identity, and value checks.

5. Verify the player outcome separately

   Test the listing, admission, or gameplay behavior with the appropriate client checks. Record pending tests explicitly. A convar response alone cannot prove the entire player experience.

Our test used authenticated, loopback-only WebRCON and a server-side quit command between starts; every process exited before its replacement launched. We did not invoke a global config-writing command between the temporary hostname change and restart. That makes the observed return to the persistent source meaningful.

If you normally restart from a panel, test that route too. Passing a manual launch test cannot establish that a panel avoids regenerating the file. Keep the row unaccepted until the route you intend to operate produces the expected result.

Keep a change register someone else can operate#

Keep the accepted worksheet with a short change record so another administrator can repeat or reverse the work. Record who changed the source, why, the before-and-after values, the build, the restart time, the checks performed, and the private location of the previous configuration.

A useful entry distinguishes outcomes such as “effective hostname confirmed after restart” from “external listing still awaiting a client check.” That distinction lets a second administrator finish the remaining work without repeating every successful step or assuming that an incomplete test passed.

Recheck affected rows after updates. The September Breach and Clear announcement includes changes to event save/load behavior and upkeep scaling. Configuration persistence, world persistence, and gameplay behavior can change independently; an old acceptance record should identify the build it actually covered.

If keeping this record exposes work you would rather delegate, use it to compare Rust hosting providers against concrete requirements. Ask about access to the relevant sources, restart behavior, exports, and who resolves conflicts. A feature list is less useful than an answer tied to the operation you need.

Our Rust PC hosting page provides the product and availability route. Availability was closed and registrations went to a waitlist when checked for this guide. Confirm current availability and the specific operating controls before planning a move; this local test does not validate a provider panel. If your existing setup meets the group’s needs, the same worksheet helps you keep operating it with fewer surprises.