Rust Server Decay Settings: Reduce Damage, Keep Upkeep Clear

Rust server decay settings control damage over time, while cupboard upkeep pays to protect a building. On a PC server, start by checking the decay.scale value exposed by the build you actually run; Facepunch documents a default of 1. Then test one setting change against a known structure, cupboard state, and restart before applying it to a live wipe. This guide shows where the setting belongs, what a small local test did and did not prove, and how to avoid confusing lower decay with cheaper upkeep.

If you would rather not keep a home PC running so your group can return to the world, Game Hosting’s Rust PC service runs the server separately. It does not replace cupboard resources or change the game’s upkeep rules.

Find the decay control exposed by your PC server#

Use the running RustDedicated server’s console or an authenticated RCON connection to ask which decay controls that build exposes. Facepunch’s command reference recommends find to search the current command list, and warns that the list is incomplete. That makes the live server output more useful than copying a variable list from an old forum answer.

find decay
decay.scale
decay.upkeep_period_minutes

In the local test used for this guide, RustDedicated build 25670169 reported protocol 2634.289.1, decay.scale: "1", decay.tick: "10", decay.upkeep: "True", and decay.upkeep_period_minutes: "1440". The server build was dated October 1, 2026. Those are observations from that build and fixture, not a guarantee that a later update will expose the same values.

Read a setting before you change it and save the response with the build number. If the command is missing, returns a different value, or a hosting panel appears to overwrite it, stop and check the server version, active identity, panel-generated files, and startup route. The broader Rust server settings guide explains how to trace a value to its persistent source. Console Edition uses a separate server ecosystem; these PC commands are not instructions for console community servers.

Separate damage over time from cupboard upkeep#

decay.scale is a floating-point multiplier for server decay, with a documented default of 1. The separate decay.upkeep_period_minutes value sets how long cupboard upkeep lasts; Facepunch lists its default as 1440 minutes, or 24 hours. That command page says increasing the upkeep period reduces the upkeep cost, but that is not the same as reducing structural damage with decay.scale.

Facepunch’s tool cupboard documentation says the cupboard shows the cost per 24 hours and how long protection remains. It also explains that a disconnected building needs its own cupboard. Those indicators answer a different question from whether a stone block is losing health. Check the inventory and privilege indicator rather than assuming a full-looking cupboard protects every nearby structure.

Change one value and test it in a disposable identity#

The safest first test changes only decay.scale in a disposable PC server identity. Facepunch documents server/<identity>/cfg/server.cfg as a place to store server settings and says to write settings without the + used on launch arguments. A control panel may manage the file or rewrite it, so compare the configured value with the value the running process reports.

1. Record the current state

   Save the RustDedicated build and protocol, the current decay.scale response, the cupboard’s resource count, and the health of one stone building block. Use a disposable identity or schedule a maintenance window with a backup.

2. Set one test value

   In the active identity’s cfg/server.cfg, add one line such as decay.scale 0.5. Do not add + to this file entry. Keep the previous value so you can roll back.

3. Restart and read it back

   Restart using the same launcher or panel route your live server uses. Query decay.scale again and confirm it returns the test value. If it does not, find which file or panel field owns the effective setting before proceeding.

4. Compare the same target

   Check the same structure, cupboard state, and health at fixed intervals. Record every interval and repeat after another restart before accepting the change.

The number is a multiplier, not a promise that every object will lose an exact percentage of health in a chosen number of minutes. The local experiment below deliberately shortened stone decay to 0.05; it cannot tell you the natural elapsed time for a regular server. If you use a temporary accelerated duration for a test, restore that value before players return and confirm it in the live process.

Compare a stocked cupboard with an empty one#

A stocked cupboard and an empty cupboard produced different stone-foundation results in one controlled local test. The test used two stone foundations on RustDedicated build 25670169, with decay.scale 1, decay.tick 10, and an accelerated decay.duration_stone 0.05. One attached cupboard held 5,000 stones; the other held none.

The stocked cupboard still held its 5,000 stones during this short sample. This was a server-created fixture, not a player-built base, and its accelerated timing is not a real-world decay schedule. The useful check is the separation: the exposed stone block lost health while the covered sample stayed at full health. Your building radius, connected foundations, grade, cupboard stock, and server version can change what you observe.

To repeat the comparison on your server, choose two equivalent structures, verify which cupboard protects each, and keep the same game version and interval for both. If only one result changes, inspect privilege coverage and material type before changing the global decay multiplier.

Check deployables and detached builds separately#

Do not assume that a foundation result describes every deployable or detached structure. The local fixture’s outdoor wooden box remained at 150 / 150 health through the shortened sample, including the restart check. That single result is not enough to conclude that all boxes, walls, vehicles, external buildings, or other objects ignore decay.

Test the object you care about on a disposable identity. Record its exact type, position, maximum and current health, cupboard relationship, and time between readings. Then repeat with the condition changed one at a time: covered versus outside, stocked versus empty cupboard, or connected versus separate building. A health value that stays the same over a short interval tells you only that it did not change in that interval.

Repeat the sample after a restart#

The same local identity saved and restarted with the no-upkeep stone foundation at 74.28 / 500 HP. After the restart, the stocked foundation was still 500 / 500, the wooden box was still 150 / 150, and the no-upkeep foundation was logged as missing after a further 35 seconds. That is evidence that the tested world state continued through this build’s restart; it is not proof for every panel, plugin, game update, or server identity.

Before you accept a setting, use the restart route your players will actually depend on and record the result:

Use a maintenance window if the experiment could affect a live base. If the identity, test target, or setting cannot be found after restart, do not infer success from a server that merely says it started. Recheck the save path and configuration owner, restore your recorded value if needed, and repeat the controlled sample before changing the rest of the world.

Choose an uptime plan your group can sustain#

Lowering decay does not remove the need to decide who keeps the server running or who checks cupboard stock. If your group wants its Rust PC world online while the home host is away, Game Hosting’s Rust service moves the server off that home PC and puts game controls in a dedicated panel. You still need to set upkeep for your building and verify how any configuration change applies to your server.

If your own PC is reliable and the group is comfortable checking the cupboard, self-hosting can be enough. Either way, save the effective setting, the build number, your upkeep plan, and the result of a restart test where another admin can find them.