Upkeep, Decay and the Cost of Leaving Things Behind

Rust is a game about building permanent-looking things in a world designed to erase them.

A stone fortress can survive gunfire, rockets and days of fighting.

Then its owners stop playing.

Eventually, without anyone attacking it, the building begins to disappear.

That is not simply a timer attached to every wall.

Rust separates upkeep, protection, decay eligibility, decay timing, building grade and several special cases through the decay.* namespace. The current public command inventory exposes dozens of individual controls under that prefix. (Corrosion Hour)

And the reason the system exists is unusually well documented.

Rust Used to Have an Abandoned-Base Problem

Before the modern upkeep system, decay prevention was much simpler.

Facepunch explained in December 2017 that interacting with a base could keep it protected from decay for days. In practice, abandoned structures accumulated, and the server continued carrying those entities long after their owners had stopped maintaining them. Facepunch explicitly connected this accumulation with server performance and with the lack of any continuing economic cost for very large bases. (Rust)

Building 3.0 changed that.

The Tool Cupboard became more than a building-permission device.

It became the maintenance account for the structure.

The basic system became:

building exists
→ upkeep resources are available
→ building remains protected

or:

upkeep resources unavailable
→ decay becomes possible

That is why decay is interesting administratively.

It is not simply destruction.

It is Rust deciding how long player construction is allowed to remain part of the world when nobody maintains it.

Upkeep Comes Before Decay

Facepunch’s current Tool Cupboard documentation describes upkeep as consuming resources to protect associated building blocks from decay. (Facepunch Wiki)

The central controls include:

These defaults and descriptions are present in the current public admin-command inventory; Facepunch separately documents the 1440-minute default as a 24-hour upkeep period. (Corrosion Hour)

1440 minutes is:

24 hours.

So the Tool Cupboard’s familiar:

Cost per 24 hours

is not merely UI text.

The period itself is configurable.

The Cupboard Does Not Protect Everything Merely Because It Is Nearby

Building privilege and decay protection overlap, but they are not identical concepts.

Facepunch’s Building 3.0 work moved privilege away from being simply a radius emitted by the cupboard and toward the identity of building blocks connected to a cupboard. (Rust)

The current Tool Cupboard documentation likewise distinguishes between separate buildings and construction attached to the same building. (Facepunch Wiki)

There are also exceptions.

Deployables inside building privilege gained decay protection shortly after Building 3.0, even though they do not necessarily contribute to upkeep in the same way as building blocks. (Rust)

Again:

decay protection

and:

upkeep contribution

are related, but not necessarily the same rule.

Upkeep Has Brackets

When Building 3.0 launched, Facepunch explicitly described upkeep as progressive: small bases should remain inexpensive while increasingly large structures become progressively more costly to maintain. (Rust)

The current public controls expose:

(Corrosion Hour)

The important point is not to reproduce the entire upkeep calculator here.

It is that Rust does not treat every additional building block as having one universal maintenance percentage.

The building grows through cost brackets.

That was one of the original purposes of upkeep: massive bases should require continuing resources rather than paying their entire economic cost once, at construction. (Rust)

Doors Can Have Their Own Brackets

The current namespace also contains separate door counts and door fractions for the same upkeep brackets.

But:

decay.use_door_upkeep_brackets = FALSE

is the current default. (Corrosion Hour)

This is a good example of why exposed controls can tell us more than default vanilla gameplay does.

Rust possesses a separate door-bracket system even though vanilla normally leaves it disabled.

Facepunch has used that capability elsewhere. In April 2025, Softcore received much higher door upkeep specifically to discourage sprawling, door-heavy bases while leaving building-block upkeep unchanged. (Rust)

So the distinction:

building-block upkeep

versus:

door upkeep

is not theoretical.

Rust can price them differently.

Doors Did Not Always Count

When Building 3.0 first appeared, players quickly found ways to build around its costs.

One week later, Facepunch added upkeep to doors, wall-frame inserts and floor-frame inserts. (Rust)

That historical change is useful because it explains why the current system counts more than walls and foundations.

Upkeep is not simply measuring:

how large is the footprint?

It is attempting to measure enough of the structure that increasingly elaborate defenses continue to have a maintenance cost.

Running Out of One Resource Does Not Mean Everything Decays

A mixed-material base adds another layer.

If a structure contains several building grades, upkeep is paid using the materials required by those components. The Tool Cupboard system tracks those resource requirements rather than treating the entire structure as one homogeneous object. (Facepunch Wiki)

So:

base upkeep failed

can be too broad a description.

Different components can reach an unprotected state according to the resources required to maintain them.

That is a much more granular system than one whole-building expiration timer.

Decay Moves From Outside In

Once upkeep protection is gone, the structure does not necessarily dissolve uniformly.

The current system distinguishes exterior from interior decay, and the public command inventory exposes:

decay.outside_test_range = 50

described as the maximum distance used when testing whether a structure is outside. (Corrosion Hour)

The original Building 3.0 design also explicitly aimed for outer layers to disappear before the protected center of a base. (Rust)

This gives us another useful chain:

upkeep failure

→ decay eligibility

→ position / exposure

→ damage over time

The base does not merely have an expiration date.

Building Grade Controls the Decay Duration

Current defaults are:

The public command inventory explicitly describes these values as hours required for an unprotected building grade to decay. (Corrosion Hour)

So upgrading a wall does more than increase its resistance to weapons.

It also changes how long that building grade survives once decay begins.

A stone wall and an Armored wall are therefore different in at least two independent dimensions:

combat durability

and:

abandonment durability.

Delay Is Not Duration

Rust exposes another entire family:

decay.delay_twig

decay.delay_wood

decay.delay_stone

decay.delay_metal

decay.delay_toptier

All currently default to:

0. (Corrosion Hour)

Facepunch added these ConVars shortly after Building 3.0 launched and explicitly stated that they all defaulted to zero. (Rust)

This gives us two different clocks:

Decay delay
How long Rust waits before decay begins.

Decay duration
How long the decay process takes once it is happening.

Those can produce the same visible observation:

The building survived for a while.

But administratively they describe different stages.

A modern example outside normal building upkeep shows the same distinction particularly clearly: in March 2026, Facepunch increased player-built boat decay delay from 12 to 24 hours while reducing its decay duration from 18 to 12 hours. (Rust)

Same two concepts.

Different system.

The Tool Cupboard Can Die Before Its Protection Does

Destroying a Tool Cupboard does not necessarily mean:

decay begins now.

Rust exposes:

decay.upkeep_grief_protection = 1440

Facepunch describes this as the maximum number of minutes of stored upkeep that can continue protecting the base after the cupboard is destroyed. With the default 1440, that can represent up to 24 hours. (Facepunch Wiki)

So another apparently simple event:

TC destroyed

actually becomes:

TC destroyed
→ stored resources converted into protection time
→ protection expires
→ decay becomes possible

unless another building-state change intervenes.

Upkeep Has to Survive a Server Restart

One of the most revealing technical details appeared almost immediately after Building 3.0 launched.

Building blocks cannot pay fractions of one resource.

That creates small overpayments.

Rust compensates by extending the next protected upkeep period according to the overpayment.

Then Facepunch discovered another requirement:

that extra protection time had to survive server restarts.

Devblog 191 specifically added serialization for that prolonged upkeep period so restarting the server would not erase already-paid protection. (Rust)

It sounds like a tiny bookkeeping fix.

But it exposes an important persistence principle:

upkeep state itself is persistent data.

A restart cannot simply rebuild the world and start every protection clock from zero.

Decay Has Global Scaling Too

The namespace also exposes:

The current public command inventory explicitly documents the >0 behavior for the two override variables. (Corrosion Hour)

Individual material timings are therefore not the only administrative layer.

Rust also exposes ways to influence the decay system globally.

Building Grades Can Be Controlled at Construction Too

decay.* contains another group that initially seems broader than decay itself:

decay.upgrade_wood_enabled

decay.upgrade_stone_enabled

decay.upgrade_metal_enabled

decay.upgrade_hqm_enabled

and their corresponding cost multipliers.

All four upgrade switches currently default to:

TRUE

and all four cost multipliers to:

1. (Corrosion Hour)

This tells us something about the scope of the namespace.

decay.* is not purely:

damage that happens when upkeep fails.

It also contains controls associated with building grades and the construction economy that feeds into upkeep.

The namespace behaves more like a broader building lifecycle control surface.

Decay Protection Does Not Always Mean Upkeep

Deployables provide another exception.

Shortly after Building 3.0 launched, Facepunch made deployables inside building privilege decay-protected. (Rust)

So we have to preserve three separate questions:

Does this entity decay?

Is this entity currently protected from decay?

Does this entity consume upkeep resources?

Those answers do not always have to be identical.

decay.* Is Not Every Kind of Decay in Rust

The namespace is broad, but it should not be mistaken for a universal lifetime system.

Rust has other objects that deteriorate or disappear through their own mechanics:

vehicles;

boats;

dropped items;

corpses;

food;

event entities;

and other temporary world objects.

Current public commands contain many examples outside decay.*, including vehicle-specific decay timers and separate despawn controls. (Corrosion Hour)

So:

Rust persistence

is larger than:

decay.*

The namespace we are looking at here is principally the control surface for building upkeep and building decay.

That boundary matters.

Current Core Controls

The general value conventions are already explained in Under Rust #1.

The defaults and short descriptions above are publicly listed by Corrosion Hour; Facepunch independently documents the central Tool Cupboard and upkeep behavior. (Corrosion Hour)

Rust Does Not Destroy a Base Because Nobody Likes It

Decay can look like punishment:

You stopped feeding the Tool Cupboard, so Rust destroyed your house.

From the server’s perspective, there is another interpretation.

Every abandoned wall, foundation, door and deployable is still an entity that the world may need to save, load, network and eventually send to players.

Facepunch explicitly identified abandoned structures accumulating indefinitely as a server-performance problem when modern upkeep was introduced. (Rust)

Upkeep therefore solves two problems at once.

It creates a continuing economic cost for large construction.

And it gives Rust a gameplay-compatible mechanism for eventually removing structures whose owners have stopped maintaining them.

That makes the final chain much larger than:

TC empty → base dies

It is:

building created
→ construction cost
→ upkeep calculation
→ resource protection
→ persistent paid time
→ decay eligibility
→ exposure / position
→ grade-specific delay and duration
→ entity removed

The player sees a base slowly falling apart.

The server is deciding when that base has stopped earning its place on the island.

Views: 3