A Rust Tool Cupboard answers two questions: who has building privilege here, and which resources are available to maintain the structure. A player can be authorized while the cupboard is empty. A cupboard can contain plenty of materials while a teammate still lacks permission. Treating those as separate checks makes a shared base much easier to manage.
There is now a third input to the maintenance bill: the group that uses the base. Since September 2026, authorization can affect upkeep scaling. That connects access decisions to cost, but it does not turn the cupboard into a complete membership manager or a guarantee that every part of a compound is maintained.
Permission, available resources and the applied group rate explain different parts of a cupboard problem.
Permission is a list of people, not a pile of stone
The Facepunch-hosted cupboard documentation explains that the placer receives authorization automatically; teammates must authorize separately. The building-privilege indicator shows the local result. The same page distinguishes that permission from the resources consumed for upkeep.
Imagine two friends moving into a starter base. One placed the cupboard and the other supplied all the stone. Their contributions do not establish identical permissions. Before assuming the second player can complete an expansion, both should check the cupboard and the privilege indicator at the intended work area. This is a permission check, even when the group agrees completely about ownership.
The distinction also helps with cosmetic work. Being able to enter a room does not establish every permission needed to change deployed objects there. The repair-bench and Spray Can guide covers those application contexts. Investigate the relevant action rather than repeatedly buying or selecting another skin.
Read the maintenance bill after changing the building
The cupboard shows a daily resource requirement and remaining protection. Different materials can run short independently. Its privilege follows the connected foundations rather than a simple circle centered on the furniture; a nearby separate building does not automatically share the same upkeep arrangement.
Those facts suggest a practical division of labor. The person adding rooms should check the new bill, while the person gathering upkeep should check the new material mix. If an upgrade introduces a material the group did not previously need, adding more of the old material will not solve that shortage. A resource total without its resource name is a poor maintenance target.
Use the actual cupboard display as the basis for a plan. For an explicitly hypothetical example, a group expects to be away for a day and wants an additional half-day margin. Its target is the displayed requirement for that period, checked again after expansion. This is a planning buffer, not a promise that every server uses an identical decay configuration or that the base cannot be attacked.
The group count can change the cost
Facepunch's September 2026 explanation adds group scaling to upkeep. The count includes cupboard authorization, code-lock authorization including guests, and relevant deauthorizations within the previous 24 hours. Under the announced defaults, the first four players add no tax, the next six add two percent each, and later players add four percent each. The maximum is 300 percent. Operators can change or disable this behavior; the cupboard's cost tooltip shows the applied rate.
This means the people with door access matter even when they never touch the cupboard. It also explains why removing somebody is not necessarily followed by an immediate drop in the bill. A delayed accounting effect is different from failed access revocation. Check the relevant lock permissions to assess entry, and check the cupboard's current cost to assess maintenance.
For a group inviting a temporary helper, the useful question is how much access the task needs. Agree on which entrance, which work area and how long the arrangement lasts. There is little value in giving broad access merely because it is faster to recite one familiar code. The cost system gives that ordinary organizational decision another visible consequence.
Draw the compound as several responsibilities
A shared base often grows in stages: living space, a workshop, a farming room and a detached storage area. Players may talk about all of it as one home, but that description is not evidence of a connected building or a common maintenance arrangement. Check each structure that matters instead of standing at the main cupboard and inferring coverage from distance.
A useful group note can name each structure, who checks it, and the point at which the group will replenish it. It need not contain door codes or sensitive screenshots. Its purpose is to prevent everyone from assuming someone else has stocked the detached room. A map marker or room name can be enough to identify the responsibility.
Appearance is another separate decision. Changing a building's skin does not answer whether a particular material is funded or a player is authorized. Use the building-skin controls guide for the hammer interface, then return to the cupboard display for maintenance evidence.
Diagnose the symptom before changing the base
If a trusted player cannot perform an action, first identify the exact object, location and permission involved. If blocks are losing health, first examine the relevant cupboard, material stock and structure connection. If the bill rose, compare construction changes and the applied group rate. These are three investigations with different evidence.
A stocked cupboard buys maintenance time under the server's rules. Authorization grants particular privileges. Neither substitutes for a defensible layout, functioning doors or an agreed group routine. Keeping the questions separate lets the group make a small, targeted correction instead of rebuilding, clearing every permission or gathering the wrong resource.