Rust server.cfg & startup parametersConvars, structure and important settings

Published on August 4, 2026 · last updated on November 8, 2026

Where is the server.cfg?

The file lives in the server identity folder under server/<identity>/cfg/server.cfg. It contains commands (convars) that are executed when the server starts. You edit it via WebFTP or SFTP - or via the configuration fields in the web interface.

Important convars

A typical server.cfg contains, among other things:

server.hostname "My Rust Server | 5x | Wipe Thu"
server.description "Welcome! Rules in chat."
server.maxplayers 100
server.worldsize 4000
server.seed 1337
server.tickrate 30
server.url "https://mainhoster.de"
server.headerimage "https://example.com/header.png"

• server.hostname - name in the server list.
• server.maxplayers - upper slot limit.
• server.worldsize / server.seed - the map.
• server.tickrate - server tick rate (default 30, range 15-30).

Startup parameters vs. server.cfg

Some values are already passed at startup as startup parameters (with a leading +), for example +server.identity, +server.port or +server.seed. They define the basic behavior before the server.cfg takes effect. Rule of thumb:

• Startup parameters: identity, ports, worldsize/seed - everything that has to be fixed when the server boots.
• server.cfg: name, description, slots, admin list, fine-tuning.

At MainHoster.de, the core startup parameters are stored in the panel; you handle the fine-tuning in the server.cfg.

Save & apply changes

Changes to the server.cfg take effect after a restart. Convars you set at runtime via RCON become permanent with server.writecfg - otherwise they only apply until the next restart. You automate recurring actions (such as a restart or a broadcast) with the task scheduler in the web interface.

writecfg: the trap when editing

One detail regularly leads to lost work: server.writecfg rewrites the server.cfg - with the values the server currently holds in memory. If you edit the file via FTP while the server is running and someone runs writecfg afterwards, your changes are gone.

The clean order is therefore:

1. Stop the server.
2. Edit the server.cfg via WebFTP or SFTP.
3. Start the server.

Conversely: what you try out via RCON while the server is running only becomes permanent after server.writecfg. A proven workflow is to test values via RCON and then save them with writecfg - that way, memory and file match.

A sensible base configuration

For a new server, a manageable set of values is enough. Everything else only gets added once you really need it:

server.hostname "[EU] MyServer | 2x | Monthly"
server.description "Welcome! Discord: ..."
server.url "https://myserver.example"
server.headerimage "https://myserver.example/header.png"
server.maxplayers 100
server.saveinterval 300
server.worldsize 3500
server.seed 1234567

server.saveinterval deserves special attention: the value determines how much is lost in an unexpected crash. 300 seconds is a good compromise - considerably shorter intervals cost a little performance with every save, considerably longer ones cost game progress in an emergency.

Name, description and image decide whether someone clicks on your server - more on that under Server name & description and Server list.

Values that do not take effect

If a setting stubbornly shows no effect, it is usually one of these points:

• The value belongs in the startup parameters. Rust only reads some settings when the program starts, not from the server.cfg. They are stored in the panel.
• The value only applies to a new world. server.seed and server.worldsize only take effect with a map wipe, see worldsize & seed.
• A plugin overrides it. In Rust, gather rates, stack sizes and craft speed run through plugins, not the server.cfg - see Gather rates.
• The server was not restarted. The most common case, and the quickest to fix.

Back up the server.cfg via WebFTP or SFTP before larger changes. With us, backups are self-service across the board, see Create backups.

Frequently asked questions