Rust Server Performance Optimization: 2026 Guide

Rust is one of the most demanding multiplayer survival games to host. Every tree chopped, every wall placed, every bullet fired, and every sleeping player on the map adds to the load your server carries. Facepunch Studios releases monthly updates that add new content and change the balance, and each update can shift performance characteristics. A Rust server that ran smoothly last month might struggle this month if you do not stay on top of optimization.

This guide focuses specifically on performance: how to size your hardware, configure your server for maximum efficiency, manage the entity count that ultimately determines your server's health, tune garbage collection for Unity, select the right map settings, handle plugins responsibly, and plan your wipe cycle. Whether you run a small group server or a 300-slot community battlefield, the principles here apply.

Why Rust servers need strong hardware

Rust is built on the Unity engine, and the dedicated server inherits both the strengths and weaknesses of that engine. The server simulation is largely single-threaded for its main game loop: AI, player interactions, building stability, decay, and most game logic run on one thread. Additional threads handle networking, saving, and some background tasks, but the bottleneck is almost always that main thread.

This means that throwing more CPU cores at a Rust server does not help much. What helps is raw clock speed. A processor running at 5 GHz handles more entities per tick than one running at 3.5 GHz, and in Rust the entity count is everything. Every foundation, wall, door, sleeping bag, furnace, auto turret, and dropped item is an entity. A busy server at the end of a wipe cycle can have millions of entities, and the server must process all of them every tick.

Memory is the other critical resource. Rust servers are memory-hungry. A freshly wiped server with a 4000-size map uses 6 to 8 GB. By the end of a monthly wipe cycle with active players, that same server can reach 12 to 16 GB or more. Running out of memory does not produce a graceful error: the server crashes, potentially corrupting the save.

Hardware sizing

Use this table as a starting point. Actual requirements vary based on your map, plugin load, and player behavior.

NVMe storage is important for Rust. The server writes the full world save to disk at regular intervals (default every 300 seconds), and a late-wipe save can be several gigabytes. On spinning disks or slow SSDs, the save operation causes a noticeable server-wide lag spike. On NVMe, even large saves complete quickly enough that players barely notice.

Server installation

The Rust dedicated server is distributed through SteamCMD. Installation on a Linux VPS:

1. Install SteamCMD: sudo apt install steamcmd on Debian or Ubuntu.
2. Download the server (app ID 258550):

   steamcmd +force_install_dir /home/rust/server +login anonymous +app_update 258550 validate +quit

3. Start the server:

   ./RustDedicated -batchmode +server.port 28015 +server.level "Procedural Map" +server.seed 12345 +server.worldsize 4000 +server.maxplayers 100 +server.hostname "My Rust Server" +server.identity "myserver"

4. Use screen, tmux, or a systemd service to keep it running in the background.

The server generates the map on first startup based on the seed and world size you specify. This initial generation can take several minutes depending on the map size and your CPU speed. Subsequent startups load the existing save and are much faster.

Map size and seed selection

Map size is one of the most impactful performance decisions you make. It directly affects entity capacity, player density, and resource distribution.

• Size 3000: compact. Good for small groups (under 50 players). Resources are close together, PvP encounters are frequent, and the entity count stays manageable. The server runs lighter and saves are smaller.
• Size 4000: the standard. The most common choice for community servers with 50 to 150 players. Provides a good balance of space, monuments, and performance.
• Size 4500 to 5000: large. Suitable for high-population servers. More monuments, more space between bases, but also more terrain for the server to track. Requires proportionally more resources.
• Size 6000+: very large. Only for dedicated communities with the hardware to match. Server save files become very large, and the entity count ceiling is much higher.

The seed determines the map layout: monument placement, terrain features, rivers, and biome distribution. Some seeds produce better monument spacing than others. The Rust community shares popular seeds on sites like rustmaps.com. Test your chosen seed on a local instance before committing to it on your live server.

Custom maps created in the Rust Edit tool give you complete control over the layout but may have different performance characteristics than procedural maps. Test them thoroughly before going live.

Entity management

Entity count is the single most important metric for Rust server performance. When the entity count grows too high, the server's tick rate drops, players experience rubber-banding and delayed interactions, and eventually the server becomes unplayable.

Key strategies for managing entities:

• Enable decay. Building decay removes abandoned structures over time. Without decay, the map fills with empty bases that consume entities forever. The default decay rates are reasonable for most servers. Reducing decay makes bases last longer but significantly increases the entity count over a wipe cycle.
• Set upkeep costs appropriately. Upkeep forces players to actively maintain their bases by depositing resources in the tool cupboard. Bases that run out of upkeep start decaying faster. This is the primary mechanism for removing inactive player bases.
• Use a decay management plugin. Plugins like "Rust Remover" or "Entity Cleanup" let you automatically remove specific types of entities (like dropped items, small stashes, or entities belonging to players who have not logged in for a set number of days). These plugins are essential for long wipe cycles.
• Limit building size. Plugins that cap the number of building blocks per player or per tool cupboard prevent a single group from building a mega-base with 50,000 entities. Even a small cap of 10,000 to 15,000 blocks per building privilege makes a meaningful difference.
• Monitor entity count. Use the ent kill and ent count console commands to track entity types. If you see a specific entity type growing out of control (common with dropped items or certain deployables), address it directly.

Garbage collection tuning

Because Rust runs on Unity, which uses the .NET runtime for the server, garbage collection (GC) is a fact of life. The GC periodically pauses the server to reclaim unused memory, and these pauses cause lag spikes that players feel as brief freezes or rubber-banding.

Tuning GC is about finding the right balance between memory usage and pause frequency.

• Incremental GC is enabled by default in recent Rust builds. This spreads the work of garbage collection across multiple frames instead of doing it all at once, reducing the severity of individual pauses. Do not disable it unless you have a specific reason.
• Allocate more RAM than the minimum. When the server has plenty of free memory, the GC runs less frequently because it does not need to reclaim space as urgently. A server that technically needs 12 GB of RAM runs smoother with 16 GB allocated, because the GC has more headroom.
• Use the gc.buffer convar. This controls the size of the GC buffer in megabytes. Increasing it (for example, from the default to 256 or 512) allows the server to accumulate more garbage before triggering a collection, which reduces the frequency of GC pauses at the cost of higher peak memory usage.
• Schedule restarts before major GC events. A server restart is the most effective garbage collection. If your server runs 24/7, schedule a restart every 12 to 24 hours during low-population periods. This resets the memory state completely.

Watch the server console for GC-related messages. If you see frequent "GC collect" entries with long pause times (over 100 ms), your server is under memory pressure and either needs more RAM or fewer entities.

Oxide and uMod plugin management

Oxide (distributed through uMod) is the standard plugin framework for Rust servers. It lets you install plugins written in C# that extend the server with features like teleportation, kits, clans, shop systems, anti-cheat, and custom game mechanics. The Rust plugin ecosystem is enormous, with thousands of free and premium plugins available.

However, plugins are also the most common source of performance problems after entity count. Every plugin hooks into the server's game loop and runs code on every relevant event. A plugin that fires on every player movement, every entity spawn, or every damage event adds processing time to every tick.

Best practices for plugin performance:

• Start minimal. Install only the plugins you genuinely need. It is tempting to add every quality-of-life plugin available, but each one has a cost. A server with 50 plugins will always be slower than one with 15, all else being equal.
• Profile your plugins. Use the oxide.show command to see which plugins are consuming the most CPU time. If a single plugin accounts for a large percentage of your tick time, consider replacing it with a lighter alternative or optimizing its configuration.
• Update regularly. Plugin developers fix performance issues in updates. Running an outdated version of a popular plugin means missing those optimizations.
• Avoid duplicate functionality. Two different teleport plugins, two different kit plugins, or two different admin tools running simultaneously waste resources and can cause conflicts.
• Test on a staging server. Before adding a new plugin to your live server, test it on a copy with simulated load. A plugin that runs fine on an empty server might cause problems with 100 players online.

Wipe cycle planning

Rust's wipe system is central to the game. Facepunch forces a map wipe on the first Thursday of every month when a major update drops. Between forced wipes, server owners choose their own wipe schedule: weekly, bi-weekly, or monthly.

Your wipe cycle directly affects performance requirements:

• Weekly wipe servers have the lightest sustained load. The entity count never gets extremely high because everything resets after seven days. These servers can get away with less RAM and still maintain good performance throughout the cycle.
• Bi-weekly wipe servers hit a middle ground. The entity count builds up more than weekly but never reaches the extremes of monthly. 12 to 16 GB of RAM is typical.
• Monthly wipe servers face the biggest challenge. By the end of the month, the entity count can be many times what it was at the start. These servers need generous RAM allocations and aggressive entity management through decay, upkeep, and cleanup plugins.

Consider a "blueprint wipe" schedule separate from your map wipe. Blueprints are the crafting recipes players learn by researching items. A blueprint wipe resets everyone to zero, which reinvigorates the early-game economy. Many servers wipe blueprints monthly (on forced wipe) but wipe maps more frequently.

Network optimization

Rust uses UDP on port 28015 by default, with RCON on 28016. Network performance matters because the server constantly sends world state updates to every connected client.

• Bandwidth scales with player count. Each connected player receives entity updates for everything in their network radius. A 100-player server with dense building areas can easily use 50 to 100 Mbit/s of bandwidth.
• Use server.netcache true. This caches network messages that are identical across multiple players, reducing the CPU time spent constructing packets. It is enabled by default in recent builds.
• Set server.tickrate appropriately. The default is 30. Higher tick rates (like 60) make the game feel smoother but double the network and CPU load. Only increase the tick rate if your hardware can sustain it under peak load. Most community servers stay at 30.
• Location matters. Players with 200 ms ping will have a worse experience than players with 30 ms, regardless of your server's performance. Host your server geographically close to your player base. If your players are split between regions, consider running separate servers rather than forcing half of them onto a high-latency connection.

Monitoring and diagnostics

You cannot optimize what you do not measure. Use these tools and commands to monitor your Rust server's health:

• status: shows connected players, their ping, and connection duration.
• server.fps: displays the server's current tick rate. If this drops consistently below 20, the server is struggling and players are feeling it.
• ent count: displays the total entity count broken down by type. Run this periodically and track the trend over your wipe cycle.
• perf: shows performance metrics including frame time, entity count, and network statistics.
• RustAdmin or RCON tools: external tools that connect via RCON and provide a dashboard view of server health, player activity, and console output. Useful for monitoring without being in-game.

Set up alerts for critical thresholds. If your entity count exceeds a certain value or your server FPS drops below 20, you want to know about it before players start complaining in chat.

Server security

Rust servers face both cheaters in-game and network attacks from outside. Layer your protections:

• Valve Anti-Cheat (VAC) and Easy Anti-Cheat (EAC) are enabled by default. Do not disable them on a public server. They catch the majority of common cheats.
• Anti-cheat plugins like "Spectate" and various reporting tools help admins identify and ban cheaters that automated systems miss.
• DDoS protection is essential. Rust servers, especially popular ones, are frequent targets for DDoS attacks. A hosting provider that includes network-level DDoS mitigation saves you from hours of downtime.
• Secure your RCON password. RCON gives full console access to the server. Use a strong, unique password and restrict access to trusted IP addresses where possible.

Hosting at HostValues

HostValues game server plans and VPS plans are built to handle the demands of Rust. All plans include AMD Ryzen 9 7950X processors with boost clocks above 5 GHz, giving you the single-thread performance that Rust's game loop depends on. NVMe storage ensures that world saves complete quickly without lag spikes. DDoS protection is included on every plan at no extra cost.

For a small group server (under 50 players, weekly wipe), start with 10 to 12 GB. For a medium community server (50 to 100 players, bi-weekly wipe), 16 GB gives you comfortable headroom. For a large community or high-population server, 24 GB and above keeps the server smooth through the entire wipe cycle. Scaling up is straightforward and does not require a wipe or data migration.

Check the Rust hosting page for plan details and pricing, or browse VPS plans if you want root access for full control over your Rust server configuration. Use the latency test to find the server location nearest to your player base.

Frequently asked questions

Why does my server lag at the end of the wipe cycle?

Almost always the entity count. As players build more bases, place more deployables, and loot accumulates on the ground, the entity count climbs throughout the wipe. The server must process every entity each tick, so more entities means longer tick times. Solutions include enabling proper decay rates, running entity cleanup plugins, setting building limits, and scheduling restarts. If the problem persists, you may need more RAM or a shorter wipe cycle.

How often should I restart my Rust server?

Most server operators restart every 12 to 24 hours. Restarts clear accumulated memory fragmentation from Unity's garbage collector, reload plugins cleanly, and generally restore peak performance. Schedule restarts during your server's lowest population window (typically early morning for your player base's time zone). Warn players 10 to 15 minutes in advance using a scheduled message plugin.

Can I switch from a procedural map to a custom map without wiping?

No. Changing the map type or seed requires a full map wipe because the terrain data is completely different. Player blueprints can be preserved (they are stored separately), but all buildings, items, and world state are tied to the specific map. Plan map changes to coincide with your regular wipe schedule to minimize disruption.

Ready to run your own Rust server? Browse HostValues Rust hosting plans, or choose a VPS for full root access. For other games, see the complete game server overview.