How to Reduce Lag on a Rust Server: Settings and Habits That Work

Your Rust server ran smoothly on wipe day. By the second week players are rubber-banding, doors open a second late and the console is quiet about why. Almost nothing about that slide is random: the map has filled with bases, boxes and dropped loot, a plugin or two is doing more work than it should, and the server is spending its frames on all of it.

Server lag is mostly a count of things and a budget of time. Measure first, keep the entity count down with decay, upkeep and sensible limits, match the map to your population, watch what your plugins cost, and leave the settings that sound like speed boosts, such as server.tickrate, at their defaults unless you know exactly what they do.

This guide is for owners of community servers, from a ten-slot server for friends to a busy public one. Every setting named here exists in the current game: I checked the names and defaults against the server code of the build released with Facepunch’s November 2026 update, and against Facepunch’s own notes and wiki.

Measure before you change anything

“Lag” covers three different problems, and each has a different cure:

• The server is slow. Its frame rate drops, so everything players do is answered late. This is what most of this guide is about.
• The network is slow. The server is fine, but the line between it and the players is not. High ping for everybody at once usually points at the host’s connection.
• The player’s PC is slow. Low FPS on one machine is a client problem, and no server setting will fix it.

Four console commands tell you which one you have:

1. server.fps prints the server’s current frame rate. Check it at a quiet hour and again at your peak.
2. global.report prints a performance report to the server console.
3. spawn.report lists every spawn population with its current and target count, so you can see whether wildlife, ore or loot are filling the map.
4. oxide.plugins, on an Oxide server, lists each plugin with the total time and memory its hooks have used since it loaded.

The server also publishes its frame rate, average frame rate and entity count, rounded to the nearest thousand, in the listing information it keeps refreshing on Steam. Anyone querying the server, server-tracking sites included, can read those numbers, so a struggling server is visible from outside before anybody complains.

What server.tickrate and fps.limit really do

These are the two settings people reach for first, and both are widely misunderstood.

server.tickrate defaults to 10. In the current server code it sets how often a housekeeping loop runs: that loop calls the Oxide OnTick hook, services RCON and the Rust+ companion server, and kicks connections that never finished authenticating. Player movement, combat and physics are not driven by it. Raising it does not make the game smoother; it makes every plugin that listens to OnTick run more often.

fps.limit caps the server’s frame rate. Its default in the server code is 240. The cap only matters when the server can actually reach it; a server that is struggling at 40 frames a second is not being held back by a limit of 240.

Copied configs often carry old “performance” values for server.tickrate or fps.limit from guides written years ago. Before keeping a value you did not choose, read what the setting does in the current game. A higher tickrate is extra work for your plugins, not extra speed.

The November 2026 changes worth knowing

Facepunch’s November 2026 update, Printed and Polished, was built largely around optimisation, and several of its changes are switches a server owner can see:

• Packet batching groups a connection’s packets for the frame before sending them. It is server.batchpackets, and it is on by default. Facepunch measured about 25% less traffic on a 500-player server.
• Player update jobs at level 4 are now the default (server.useplayerupdatejobs). Level 4 spreads server occlusion and network queue work across threads; level 3 is due to be removed in the next patch, so do not pin it.
• Network LODs send the positions of distant entities less often. net.position_lod sends them every 0.2 seconds past 128 m and every 0.4 seconds past 192 m; net.position_lod_players does the same for players. Both are 0, off, by default. Facepunch is enabling them on some of its own servers first, so treat them as an experiment and test with real players before leaving them on.
• Building privilege checks now use a grid cache instead of a physics query. Facepunch reports one check in a large base going from 5.7 ms to under 0.02 ms, with no setting to change.
• Fewer entities: most deployables sitting in player inventories no longer create an entity.

The building privilege check after the November change: 0.02 ms per call, down from 5.7 ms in a big base. Image: Facepunch Studios.

Entities: the number that grows all wipe

Every wall, box, door, furnace, dropped item, corpse, tree and animal on the map is an entity the server has to keep, save and send to whoever is near it. A fresh wipe starts low and climbs every day, which is why the same server feels slower in week two than on day one.

Every world save prints the entity count; on this test map it was already above 120,000.

The settings that keep the count in check:

• server.itemdespawn (default 300 seconds) is how long a dropped item lies on the ground. Items left in loot containers last longer, scaled by server.itemdespawn_container_scale up to a cap of 24 times, about two hours.
• server.corpsedespawn (300 seconds) and server.npccorpsedespawn (600 seconds) remove bodies.
• server.max_tool_cupboards (0, unlimited) caps how many tool cupboards each player may place. The November update limits Softcore players to six. Lowering it does not remove cupboards already placed.
• spawn.min_density and spawn.max_density (0.5 and 1) scale how densely ore, wildlife and other populations fill their areas as the player count changes.

Industrial setups are a separate cost: server.conveyormovefrequency and server.industrialcrafterfrequency (both 5 seconds) set how often conveyors and industrial crafters act, and server.industrialframebudgetms (0.5 ms) caps how much of each frame industrial jobs may use.

Decay and upkeep keep the map clean

Decay is the cleaner. A base nobody maintains loses health on every decay tick (decay.tick, every 600 seconds) until it falls down and stops costing the server anything. Unprotected, a building fully decays in roughly 1 hour at twig, 3 at wood, 5 at stone, 8 at sheet metal and 12 at armoured (decay.duration_twig to decay.duration_toptier).

Upkeep is what protects a base from decay: resources in the tool cupboard are consumed to keep it standing. Three things make it scale:

1. Size. The first 15 blocks cost 10% of their build cost per day, the next 50 cost 15%, the next 125 cost 20%, and every block past 190 costs a third (decay.bracket_0_costfraction and its neighbours). Big bases pay much more per block than small ones.
2. Group size. Since the September 2026 update, upkeep rises with the number of players tied to a base: the first four add nothing, the next six add 2% each and every player after that adds 4% (decay.upkeep_group_scaling). In the server code the result is capped at three times the normal cost (decay.upkeep_group_max_multiplier).
3. Time. decay.upkeep_period_minutes (1440, one day) is how long one payment lasts.

A large group sharing one tool cupboard: every player past the first four adds to the upkeep it pays. Image: Facepunch Studios.

Turning decay off with decay.scale 0 feels generous, but on a server that wipes rarely it means every abandoned base stays forever. If players complain decay is too harsh, try decay.scale 0.5 first and watch the entity count over a full wipe.

Match the map to your population

server.worldsize defaults to 4500, and the game clamps procedural maps to between 1000 and 6000 metres. A bigger map is not only more ground: it carries more monuments, more ore, more trees and more animals, all of them entities, and Facepunch’s wiki notes that larger maps need more memory and disk.

The other cost is human. A map much larger than your population feels empty, and an empty server is one players leave. Size it for the players you actually have at your peak, not the slot count you hope for. Rust map size explained goes through the common sizes in detail.

Custom maps follow the same rule: what costs the server is how much is placed on the map, not the number in the file name. A well-made custom map is built with that budget in mind.

Plugins: the cost you add yourself

Every Oxide plugin hooks into the game’s events, and some events fire constantly: entity spawns, damage, player input, the tick loop. A plugin that does heavy work on one of those runs that work thousands of times an hour.

Find the expensive one

Run oxide.plugins after the server has been up for a few hours. The figures in brackets are the total seconds and memory each plugin’s hooks have used since it loaded; one plugin far above the rest is your first suspect. Oxide also writes a warning to the log whenever a single hook call takes longer than 100 milliseconds, naming the hook and the plugin.

Confirm it

Unload the suspect with oxide.unload <name> at a busy hour and compare server.fps before and after. Then decide: configure it more conservatively, replace it, or accept the cost because players want what it does.

Two habits help more than any setting. Do not install a plugin for a feature nobody uses, and update plugins after each monthly Rust update, when hooks and game code change.

Saves, restarts and hardware

The server saves the world every server.saveinterval seconds (600 by default) and keeps server.savebackupcount old copies (2). A save is a moment of extra work, and industrial is paused during it by default (server.pauseindustrialduringsave). Saving much more often than every ten minutes trades smoothness for a smaller loss after a crash.

A scheduled daily restart clears what builds up over a long uptime, and in November Facepunch cut its biggest servers’ restart time from about 10 minutes to about 2 by fixing save-loading code that scaled badly with entity count.

Facepunch's breakdown of the restart work it removed in November: entity links and limit checks went from minutes to seconds. Image: Facepunch Studios.

For hardware, Facepunch’s wiki asks for at least 12 GB of free RAM and 15 GB of free disk, strongly prefers an SSD or NVMe drive, and says real needs depend on your population and use. A great deal of the server’s work still happens on its main thread, so a fast processor core matters more than a long list of slow ones.

The checklist

• server.fps checked at quiet and peak hours, and global.report and spawn.report read once.
• server.tickrate and fps.limit at values you understand, defaults unless you have a reason.
• Packet batching on and player update jobs at level 4; network LODs tested before leaving them on.
• Decay on, upkeep on, and a decision on server.max_tool_cupboards.
• A map size that fits your real peak population.
• oxide.plugins read after a busy evening, and any plugin nobody uses removed.
• A daily restart and the default ten-minute save interval.

Where Badgyver comes in

I make custom Rust maps and Rust plugins, and performance is part of the design rather than an afterthought: a map is a budget of objects, and every monument and plugin on it has to earn its place. If you are choosing a map for a server you want to keep smooth, or wondering whether one of my plugins will cost you frames, ask me on Discord before you buy.