Rust server.cfg and convars: decay and upkeep

A Rust server is configured with convars - console variables like server.hostname or decay.scale - and the file that sets them at every start is server/<identity>/cfg/server.cfg. Each line is a convar and a value, exactly as you would type it in the console, with no + in front. Startup-only values (ports, identity, map seed and size) belong on the launch line instead. Admin and ban lists live next door in users.cfg and bans.cfg, written by server.writecfg. Of the hundreds of convars, perhaps twenty matter to a typical server, and the ones that change how the server plays - decay and upkeep above all - deserve more thought than they usually get. This post lists them with what they do.

Where Rust keeps its configuration#

Everything lives in the identity folder named by +server.identity on the launch line. With an identity of main:

The cfg folder may not exist on a fresh install. Create it, create server.cfg inside it, and the server reads it on the next start. Some builds also write an automatically managed config file into the same folder holding values changed in the console; treat anything there as the server's, and keep your own settings in server.cfg where you can see them.

The identity folder is also where the map, save and player databases live, which is why the config survives wipes: a wipe deletes the .map, .sav and selected .db files, not cfg/. Rust wipes without losing your players has the full file list.

How convars load, and how to check a value#

There are three places to set a convar, and they behave differently:

1. The launch line, as +convar value. Read before the world loads. The only right place for server.port, server.queryport, server.identity, server.level, server.seed, server.worldsize and the RCON settings.
2. `server.cfg`, as convar value. Executed at every start. The right place for everything else you want to persist.
3. The console or RCON, as convar value. Takes effect immediately, and is forgotten at the next restart unless the same line is also in server.cfg.

Set each convar in exactly one of the first two places. A value set on the launch line and again, differently, in server.cfg will be resolved by load order, and the person debugging it later will not know which file to trust.

Checking is easy. Type a convar's name with no value and the console prints the current value. find decay lists every command and convar containing "decay" with a short description, which is the best way to discover settings and to confirm that a name you read in an old guide still exists on the current build.

> decay.scaledecay.scale: "1"> find upkeep

Changing values on a live server

Most gameplay and listing convars take effect the moment you set them in the console: the hostname updates in the browser at the next query, decay.scale changes the next decay tick, server.idlekick applies to the next idle check. That makes the console the right place to try a value before committing it to the file. A few things do not change live in any useful way. Ports, identity, seed, world size and level are read once at startup; setting them in the console either does nothing or does nothing until the next wipe. RCON settings are the same.

The safe routine is: try the value in the console, watch the effect for an evening, then add the line to server.cfg so the next restart keeps it. The unsafe routine - editing server.cfg and restarting to see what happens - costs players a restart for every experiment.

A complete server.cfg#

A sensible starting file for a community server. Values in quotes when they contain spaces; comments are lines starting with //.

// listingserver.hostname "Longship | EU | Biweekly | Next wipe Thu 15 Oct"server.description "Vanilla rates, 2-week wipes, no zergs over 4.\nDiscord: example.com/discord"server.url "https://example.com"server.headerimage "https://example.com/rust-header.png"server.tags "biweekly,vanilla,eu"// population and savingserver.maxplayers 75server.saveinterval 300// playersserver.idlekick 30server.globalchat true// performancefps.limit 60// decay and upkeep (vanilla)decay.scale 1decay.upkeep true

\n in the description starts a new line in the server info panel. The header image is fetched by each client from your URL, so host it somewhere fast and stable; the commonly documented size is 512 x 256 pixels.

Listing and identity convars#

These decide whether anyone finds the server and what they think when they do. The hostname is the single most-read piece of text you control - put the cadence and next wipe date in it, as the monthly force wipe schedule suggests.

server.tags drives the browser's filters. The accepted values cover wipe cadence (weekly, biweekly, monthly), style (vanilla, pve, roleplay, creative and a few more) and a region code; unknown tags are ignored. The list is defined by the game and has changed over time, so check the current set rather than inventing tags. Tag honestly: a server tagged vanilla running 5x gather is the kind of thing players report.

Gameplay convars#

Two warnings. server.pve true is vanilla Rust's PvE switch, and it is blunt: it does not stop players looting each other's bases or killing animals someone else is hunting. Proper PvE servers combine it with plugins such as TruePVE and zone rules. And server.stability false is popular on build servers but changes how every structure behaves; turning it on again mid-wipe can bring down bases that were legal a minute earlier.

The idle kick matters more than it looks on a full server. Without it, a slot occupied by someone asleep at their desk is a slot a queued player cannot use. Thirty minutes is a reasonable default; on a server that is never full, idlekickmode lets you only kick idle players when the server is at capacity.

Decay and upkeep, explained properly#

Decay is how Rust cleans up. Without it, every abandoned base on the map stays forever, entity counts climb all wipe, and new players spawn into a landscape of ruins. Upkeep is the price of exemption: a base protected by a Tool Cupboard pays resources from that cupboard to stay in repair, and when the cupboard runs dry, the base starts to decay like any other structure.

The mechanics, in the order they happen:

1. Every building block and many deployables have a decay timer and a material. Twig falls fastest, then wood, stone, sheet metal and armoured.
2. A Tool Cupboard covering the building pays upkeep from its inventory. The cost depends on how many blocks and of what material, and rises more than proportionally as the base grows - large bases pay a premium per block.
3. While upkeep is paid, the base does not decay and slowly heals.
4. When the cupboard cannot pay, decay starts. Entities lose health on a schedule until they break.

The exact timers and cost brackets are set by Facepunch and adjusted from time to time; the console's find decay shows the convars your build has.

Choosing decay settings

• Vanilla (`decay.scale 1`, upkeep on) - the right default. Abandoned bases disappear within a day or so, entity counts stay manageable, and players learn to fill their cupboard.
• Reduced decay (`decay.scale 0.5`) - a reasonable choice for small servers where people play a couple of evenings a week. Halving decay gives absent players a buffer without letting the map fill up.
• No decay (`decay.scale 0`) - only for creative and build servers, or short wipe cycles where the wipe does the cleaning. On a monthly server with no decay, the map ends the month carrying every base ever started, and performance pays for it.
• Upkeep off - removes the cost of keeping a base, which strips out a core resource sink. Usually a mistake on PvP servers, sometimes right on PvE or roleplay ones.

Whatever you choose, say it in the server description. "Decay 50%" or "No upkeep" is information players use to decide whether your server suits how often they can play, and a player whose base decayed on a server they assumed was lenient will not come back to read the rules.

Three starting points

Most servers fit one of three shapes, and the convars follow from the shape.

• Vanilla community PvP. Leave decay, upkeep, radiation and stability at their defaults. Set an idle kick of around 30 minutes, keep global chat on, and spend your effort on the listing convars and a sensible world size. This is the configuration players arriving from official servers expect, and deviating from it without saying so is the quickest way to get negative reviews.
• PvE or relaxed. server.pve true plus a PvE plugin for the gaps, decay.scale around 0.5 so weekend players keep their bases, and an idle kick only when the server is full. Radiation stays on, otherwise monuments lose their purpose.
• Build or creative. decay.scale 0, upkeep off, often server.stability false, no idle kick, and wipes only when the map is full. Expect the entity count to climb without limit and plan the wipe schedule around that.

Changing shape mid-wipe is the one thing to avoid. Turning decay back on, or stability back on, on a map built under the opposite rules destroys bases that players built in good faith.

Decay is your cheapest performance tool. Server performance and entity count explains why entities are the main cost, and why decay beats any cleanup plugin.

Writing changes to disk#

Changes made in the console are live and temporary. To keep them, put them in server.cfg. Admin and ban changes are different: ownerid, moderatorid and banid change lists the server stores itself, and they reach users.cfg and bans.cfg only when you run server.writecfg.

ownerid 76561198012345678 "Alice" "owner"moderatorid 76561198087654321 "Bob" "mod"server.writecfg

Restart without server.writecfg and those grants are gone. It is the most common configuration support question for Rust there is. Rust admin commands has the rest of the admin list.

Keep a copy of the whole cfg folder outside the server - in your staff documents, a private repository, or simply a dated download before each wipe. It is a few kilobytes, it holds every decision you have made about how the server runs, and it is the first thing you will want if you move hosts, rebuild after a bad update or hand the server to someone else. Moving a server without losing players covers the rest of a move.

Editing users.cfg or bans.cfg by hand works while the server is stopped. Edit them while it is running and the next server.writecfg overwrites your edit with what the server has in memory.

Editing config on a panel#

On a Pterodactyl panel, launch-line values appear as variables on the Startup tab and the server assembles the command from them, so the seed, world size and hostname may be panel fields rather than lines you write. Check what the egg sets before duplicating anything in server.cfg: if the hostname is a Startup variable and also in server.cfg, one of them is ignored.

On RE:NODE, the file manager edits server.cfg in the browser with syntax highlighting, the console has command history and tab completion for trying values live, and backup slots let you snapshot the identity folder before an experiment. Rust is not in RE:NODE's game catalogue, so these are the panel's general features rather than a Rust plan; Pterodactyl panel explained covers how the pieces fit.

Troubleshooting config problems#

A setting in server.cfg has no effect. It is also set on the launch line or by a panel variable, the name is misspelled, or the convar no longer exists. Type its name in the console to see the live value.

Hostname or description reverts after restart. It was changed in the console only. Put it in server.cfg.

Admins lose rights on restart. server.writecfg was not run after ownerid.

The description shows on one line. Use \n inside the quoted string, not real line breaks.

The server ignores server.cfg entirely. It is in the wrong identity folder or not inside cfg/. Check the identity on the launch line against the folder name exactly, including case on Linux.

Bases decayed overnight on a small server. Vanilla decay with players who log in twice a week. Lower decay.scale or teach people to stock their cupboard.

FAQ#

Where is server.cfg on a Rust server?

In server/<identity>/cfg/server.cfg, where <identity> is the value of +server.identity on the launch line. Create the cfg folder if it does not exist.

How do I turn off decay on a Rust server?

Set decay.scale 0 in server.cfg. Use it for build and creative servers; on a normal PvP server, lowering decay is usually better than removing it because decay is what clears abandoned bases.

Do I need the plus sign in server.cfg?

No. The + is launch-line syntax only. In server.cfg each line is the convar and its value, as you would type it in the console.

How do I find every convar Rust supports?

Use find in the console with a prefix, such as find server. or find decay. It lists matching commands and convars from the build you are actually running.

Does a wipe reset server.cfg?

No. A wipe removes map, save and player database files. The cfg folder is untouched unless you delete it yourself.