A Rust server can start with 7 GB of RAM, then end up at 14 GB after two days of wipe without changing version. The map size sets the base, players fill that base with bases, chests, sleepers and entities. The right setting is chosen before the wipe, because reducing a map afterward almost always means wiping the terrain.
Link RAM, map size and players before the wipe
Rust loads a full map as soon as it starts. Then players add what remains in the world, buildings, chests, furnaces, traps, vehicles and sleepers. A 4000 map is not 33 % heavier than a 3000. It is 16 km² instead of 9 km², which is 78 % more surface area. This surface area brings more monuments, more roads, more resource spawns and more persistent entities.
First set server.worldsize. 3000 is suitable for a small community of 20 to 40 connected players. 3500 works well for 50 to 80 players. 4000 becomes the common format around 100 players. Beyond 4500, the surface costs more in RAM and heavier saves. Then set server.maxplayers. This number does not fill memory by itself, but it allows more bases, more chests and more sleepers over the course of the wipe.
Keep 25 to 30 % memory headroom after boot. A server that starts at 10,5 GB on a 12 GB machine is already starting too high. At 85 % RAM usage, the system keeps little room for save spikes. At 92 %, swap or the Linux OOM killer eventually gets involved. The message "Out of memory: Killed process" often appears at the worst possible time, never when Discord is quiet.
Choosing a Rust map size based on your population
The right map size is not the one that lines up the most monuments. It is the one that keeps players close enough to run into each other, without cramming 200 bases into the same 1 km² square. A map that is too big uses more resources and gives the impression of an empty server. A map that is too small turns every evening into constant raiding, then people leave after 48 hours.
| Size | Surface area | Target population | RAM to plan for | Degradation threshold |
|---|---|---|---|---|
| 3000 | 9 km² | 20 to 40 players | 6 to 8 GB | More than 70 active players, crowded monuments |
| 3500 | 12,25 km² | 40 to 80 players | 8 to 10 GB | More than 110 active players, lots of bases |
| 4000 | 16 km² | 80 to 130 players | 10 to 14 GB | More than 170 active players, long saves |
| 4500 | 20,25 km² | 130 to 180 players | 14 to 18 GB | More than 220 active players, high entity count |
| 5000 | 25 km² | 180 to 250 players | 18 to 24 GB | Beyond 280 active players, CPU and RAM struggle to keep up |
These figures are intended for a vanilla or near-vanilla server, with active decay and without 80 uMod plugins. An x10 server with huge stacks, kits, modified recycling and accelerated loot generates more items and pushes players to build bigger. At the same population, it often uses 20 to 40 % more memory than a vanilla server after a week of wipe.
Do not choose 6000 for 60 players. The map is 36 km², four times a 3000. Players travel more than they meet, and the machine keeps in memory a surface nobody really uses.
Sizing RAM for 20, 50, 100 and 200 players
Minimum RAM is for starting the server. Useful RAM handles the wipe, saves, Saturday night peaks and plugins. On Rust, the number of connected players matters less than what they leave behind. 50 active players over two days build less than a community of 50 players taking turns across 180 unique accounts.
| Real case | Consistent map | Minimum RAM | Target RAM | Bad sign |
|---|---|---|---|---|
| 20 players among friends | 3000 | 6 GB | 8 GB | More than 6.8 GB used on 8 GB |
| 50 community players | 3500 | 8 GB | 10 to 12 GB | Save above 2 seconds |
| 100 players, regular wipe | 4000 | 12 GB | 16 GB | Server FPS below 20 in the evening |
| 200 public players | 4500 to 5000 | 18 GB | 24 to 32 GB | RAM above 90 % before midnight |
A 4 GB margin seems large on a small server. Yet it avoids dirty restarts when Unity loads a big save, when Linux keeps disk cache, or when a plugin leaks for six hours. From 100 players onward, think in terms of ceiling, not average. If your server runs at 11 GB in the afternoon on 12 GB available, the 9 p.m. peak can cut the evening short.
Empty slots use almost nothing. Sleepers, however, stay in the save. A limit of 150 players with 40 connected may stay light on the first day, then become heavy on the third if 300 unique accounts have built and slept on the map.
Test Rust load before announcing slots
Announce your slots after a test, not before. A server that boots quickly on a fresh map proves nothing. Check startup, map generation, ports, save and memory after at least 30 minutes with your plugins loaded.
- Set the map and ports in the launch command. The default game port is 28015 in UDP. RCON often uses 28016 in TCP. Opening only 28015 makes the server visible, but remote administration fails.
- Start with a clean map of a realistic size. For 80 players, start with 3500 or 4000, not 5000. A large world hides problems during the first hours, then shows them when bases appear.
- Keep the same seed during your tests. Changing server.seed changes monuments and resource distribution, so it changes the initial load.
- Control saves with server.saveinterval set to 300 seconds. Five minutes limits data loss in case of a crash without writing to disk in a loop.
.\/RustDedicated -batchmode +server.port 28015 +rcon.port 28016 +server.worldsize 3500 +server.maxplayers 80
On the Starmine panel, you change the map size, seed, slots and ports without rewriting the launch command at every wipe. The values stay visible in the same place. This avoids the classic 4000 announced on Discord and 4500 actually launched. See the panel.
Spotting Rust performance that degrades in game
Players do not first see full RAM. They see doors opening late, gathering rolling back, shots landing badly. On the server side, look at three thresholds together, memory, server FPS and save duration. A healthy Rust server stays close to 30 server FPS. Below 20 FPS during peak hours, actions start to lag. Below 10 FPS, combat gets bad, even with player ping at 35 ms.
Save duration describes the real state of the map. A save under 500 ms is not noticeable. Between 1 and 2 seconds, attentive players sometimes see a micro-freeze. Above 3 seconds every 300 seconds, the map has too many entities for the machine or the disk is keeping up poorly. A factory base with conveyors, turrets, chests and lighting costs server time. Multiply that by 80 clans and you see where the milliseconds go.
Memory becomes dangerous before 100 %. At 85 %, monitor it. At 90 %, plan a clean restart or reduce the load. At 95 %, you are waiting for a crash. On Linux, the log may contain "Out of memory: Killed process". This is not a mysterious Rust crash. It is the system killing the process to stay alive.
tail -n 200 output_log.txt
Plugins make these thresholds worse when they store too much data in JSON, scan containers too often or trigger timers every second. A badly written stats plugin can cost more than moving from 3500 to 4000.
Reducing a Rust map that is too large after a bad wipe
Reducing the map size, changing the seed or deleting the world folder forces a new map. You lose the terrain, bases, chests, vehicles, sleepers and generated monuments. Blueprints only disappear if you also erase the player database.
When a 5000 map drops below 15 server FPS with 90 players, adding 4 GB of RAM can save an evening. It does not fix the root cause. Going from 5000 to 4000 cuts the surface from 25 km² to 16 km², which is 36 % less land. The RAM drop varies by seed, but 4 to 8 GB difference on a busy server is nothing unusual.
- Announce a map wipe. Do not promise to move the bases. Rust cannot cleanly shrink a world while keeping constructions at the new coordinates.
- Copy the folder linked to server.identity before doing anything. Keep the full folder at least until the next wipe. A backup of 2 to 8 GB transfers quickly, a lost community does not come back quickly.
- Keep the blueprints if your wipe schedule keeps them. Deleting only the map avoids punishing players twice.
- Restart with a lower size and a tested seed. For 70 players, 3500 is enough. For 120 players, 4000 remains the best compromise. For 200 players, 4500 works better than 5000 if your priority is combat and save times.
The bad idea is to lower the slots without touching the map. You limit entries, but you keep the same surface, the same entities and the same saves. If the problem comes from a world that is too large, the slots free up almost nothing before the next wipe.
Guides
Is 16 GB of RAM enough for 100 players on Rust ?
Yes, with a 4000 map and a vanilla or lightly modded server, 16 GB leaves a decent margin. If RAM goes over 14 GB before the evening peak, the map or the plugins are already too heavy to handle the wipe properly.
Is a Rust 5000 map too big for 60 players ?
Yes, in most cases. A 5000 map is 25 km², while a 3500 is 12.25 km². For 60 players, you are paying for almost twice as much surface without creating more activity.
How much more RAM do Rust plugins need ?
A small batch of clean plugins often adds 500 MB to 2 GB. A heavily modded server with kits, economy, statistics, stacks, modified loot and detailed logs can add 4 GB or more after a few days.
Does changing the number of slots reduce RAM usage ?
Very little if the map already exists. Empty slots consume almost nothing. RAM mainly comes from the map size, saved entities, sleepers and loaded plugins.