Rust server RAM: sizing by map and wipe

A Rust server needs about 8 to 10 GB of memory for a 3000-size map with up to fifty players, 12 to 16 GB for the common 3500-4000 maps with 75 to 125 players, and 16 to 24 GB for a 4500-plus map with the population to fill it. A small private server for a group of friends on a 2000-2500 map runs in 6 to 8 GB. Those figures are for the end of a wipe, not the start: Rust's memory use is lowest the hour after a wipe and highest the day before the next one, because every wall, box and furnace players place stays in memory until the map is wiped. Size for the busiest day of the cycle, leave headroom for the save, and remember that the very first start of a fresh map is the heaviest moment of all.

What a Rust server keeps in memory#

RustDedicated is a Unity server running a managed .NET heap, and almost everything it knows lives in that heap all the time. Unlike Minecraft, it does not unload the parts of the world nobody is near. The whole map and every entity on it are resident from start to shutdown, so memory is set by the size of the world and how much has been built on it, and only weakly by how many people happen to be online.

The main consumers are:

• The map itself. Terrain heightmap, splat and topology layers, biome data, the road and river splines, and every monument and prefab. Map memory grows faster than linearly with server.worldsize, because both dimensions grow and larger maps get more monuments.
• Entities. Every building block, door, box, furnace, turret, sleeping bag, dropped item, corpse, barrel, node, animal and NPC is a networked entity. A mature wipe on a busy server holds hundreds of thousands of them, and this is the line that grows through the cycle.
• Item containers. Each box holds its items as objects. Raised stack sizes on a modded server mean fewer items but larger counts, and higher gather rates mean more total stuff in the world.
• Plugins. Oxide or Carbon load every plugin into the same process, along with their data files, caches and timers. Most cost little; some keep large structures in memory.
• Garbage collector headroom. A managed heap needs free space to work in. Running it right up against the limit makes collections more frequent and slower.

That last point is the one people miss. A Rust server that genuinely holds 9 GB of live data will not run happily in a 10 GB container, because the collector needs room and the save process allocates while it writes.

RAM by world size and population#

These are working figures for a vanilla or lightly modded server, measured at the end of a weekly wipe cycle rather than on wipe day.

Two warnings about the table.

The player column is an indicator of how much gets built, not a direct cost. Each connected player adds network buffers and a little state, perhaps tens of megabytes. What costs gigabytes is what they build. A twenty-player clan server where every group builds a compound with walls, turrets and twenty large boxes can need more memory than a fifty-player server of solo players living in two-by-twos.

The world size column is a choice, and it is the cheapest lever you have. A 4500 map with thirty players is mostly empty land you are paying to hold in memory, and it plays worse: people spread out, raids happen less, and the server feels dead. Pick the map size for the population you actually have. Rust wipes without losing your players covers how map size, cadence and population fit together.

Why memory peaks the day before a wipe#

Plot a Rust server's memory over a wipe cycle and you get a ramp, not a flat line. Wipe day starts at the map's floor. Every evening adds bases, deployables and loot. Upkeep and decay remove some of it, but on an active server they remove less than players add. By the last day of the cycle the server can be holding several gigabytes more than it did on the first.

This has two practical consequences.

1. Never size from wipe day. A server that sits at 55% on Thursday afternoon after a Thursday wipe can be at 95% the following Wednesday. Check the graph across a whole cycle before deciding the plan is right.
2. Restart, but do not expect a restart to reset it. A restart frees fragmentation and anything a plugin was leaking, which often recovers a gigabyte or more. It does not remove entities, because they are loaded back from the save. Only decay, cleanup and the wipe itself do that.

The map generation spike#

The first start after a map wipe builds the whole procedural world in memory before it writes it to disk, and that is the highest memory use the server will ever reach. A server that would host the finished 4000 map perfectly can run out of memory while generating it.

The map is cached in the server's identity folder once generated:

server/my_server_identity/  proceduralmap.4000.12345.<protocol>.map  proceduralmap.4000.12345.<protocol>.sav  player.blueprints.<n>.db

The file name carries the world size, the seed and the game protocol number. On every later start the server loads the cached .map instead of generating, which is both faster and lighter. If the protocol changes (a forced wipe update) or you change size or seed, it generates again.

If the first start after a wipe fails and the second succeeds, or if it only works after you shrink the map, you have hit this. The fixes, in order:

1. Make sure nothing else is using memory during generation: no plugins doing heavy work on load, no second process.
2. Generate once with fewer players able to join, then let people in after the .map file exists.
3. Reduce server.worldsize by 500. The memory saving is real and few players notice.
4. Generate the map somewhere with more memory, then upload the .map file with the same size, seed and protocol in its name.

The startup line that sets all of this is the usual one:

$ ./RustDedicated -batchmode -nographics \    +server.identity "my_server_identity" \    +server.worldsize 4000 +server.seed 12345 \    +server.maxplayers 100 +server.saveinterval 600 \    +rcon.web 1 +rcon.port 28016 +rcon.password "change-me"

server.worldsize accepts values from 1000 to 6000. The seed is any integer. Custom maps use server.levelurl pointing at a hosted .map file instead of size and seed, and their memory depends entirely on how many prefabs the maker placed.

Settings that control how much gets built#

Because entity count drives memory, the settings that control entity count are memory settings, whether or not they say so.

Type a convar name on its own in the console to print its current value - defaults have moved between updates, so read yours rather than trusting any table.

Gather rate and stack size plugins change the shape of memory more than the size. Higher gather means players own more of everything sooner and build larger compounds sooner, so a 3x server reaches late-wipe memory use in days rather than weeks. Plan modded servers one row up the table from vanilla.

Plugins: Oxide, Carbon and what they cost#

Oxide (uMod) and Carbon both load plugins as compiled C# into the server process. The framework itself adds a few hundred megabytes. Individual plugins vary enormously:

• Cheap: chat formatting, kits, teleport commands, simple admin tools. Kilobytes to a few megabytes each.
• Moderate: economy and shop plugins, permission-heavy setups with thousands of players in their data files, Discord bridges.
• Expensive: anything that tracks per-entity data across the whole map, custom NPC and event plugins that spawn their own entities, map-wide statistics and logging plugins that keep history in memory, and loot plugins that fill extra containers.

Plugin data files live under oxide/data (or Carbon's carbon/data) and are loaded into memory when the plugin starts. A data file that has grown to hundreds of megabytes over months of player history is a memory cost on every start. Check their sizes from time to time; Rust Oxide and uMod plugins and Carbon vs Oxide cover the frameworks.

The quickest test for a suspect plugin is the boring one: unload it with oxide.unload PluginName (or c.unload on Carbon), wait for a garbage collection, and watch whether memory drops. Then load it again and watch whether it climbs back.

Proving memory is the problem#

Rust's performance problems are split fairly evenly between memory and the main thread, and the fixes do not overlap. Check which one you have.

1. Watch memory across a full wipe cycle. If the peak is within 10% of the limit on the last day, you need either more memory or fewer entities.
2. Check `server.fps` during the busiest hour. Low server FPS with memory well below the limit is a CPU problem: entity count, plugins or AI. More memory will not move it. Game server CPU requirements covers what to do instead.
3. Look at how the server stops. A Rust server that runs out of memory inside a container does not print a friendly error. The log simply ends, often mid-save, and the next start loads whatever was last written successfully. If the log ends without an exception, look at the memory graph for the minutes before it.
4. Check the save time. As the world grows, the save takes longer and allocates more. A save that freezes the server for several seconds on the last day of the wipe is a sign the world is large for the plan - and a save that is interrupted by the memory limit can leave a damaged .sav.

Rust server performance and entities goes further into entity counts and server FPS.

Running Rust on rented hardware#

Rust is not in the RE:NODE game catalogue, so there is no Rust plan to point at. For a community server the honest answer is a machine where the whole allocation is yours: a VDS or a dedicated box. A 16 GB machine is the realistic floor for a 3500-4000 map community server once you account for the operating system, a backup process and headroom for the save; 24 GB gives a 4500 map room to breathe. A small friends server on a 2000 map is happy in 8 GB.

Whatever you run it on, three habits keep the memory story boring:

• A scheduled daily restart at a quiet hour, with an in-game warning first. It recovers fragmentation and plugin leaks, and it is when updates and plugin reloads happen cleanly. Restart schedules that help has the timing.
• A backup before every wipe and before every update. The identity folder is the server. Back up server/<identity> and the plugin data and config folders.
• A memory check on the day before each wipe. That is the number that tells you whether next cycle needs a smaller map or a larger plan.

On a VDS you also choose what happens at the limit. Linux's out-of-memory killer will pick the largest process, which is RustDedicated, and kill it outright. A small swap file buys warning time rather than capacity - Linux swap and the OOM killer explains why a little is useful and a lot makes things worse.

FAQ#

Is 8 GB enough for a Rust server?

For a 3000 map with up to about fifty players, or a smaller map for a group of friends, yes. For the common 3500-4000 community map it will run on wipe day and struggle by the end of the week. If you have 8 GB, choose the map size to fit it rather than the other way round.

Does Rust use more RAM with more players?

A little directly, a lot indirectly. Each connection costs tens of megabytes. What players build costs gigabytes, and more players build more. A server's memory tracks entity count far more closely than the number online.

Why did my Rust server crash on the first start after a wipe?

Almost certainly map generation. Building a procedural map takes more memory than running it, and the first start of a new size or seed has to generate it. Shrink the world by 500, or generate it once with more memory and keep the .map file.

Do Oxide plugins use a lot of RAM?

The framework adds a few hundred megabytes and most plugins add little. A minority that spawn entities, track per-entity data or keep long histories in their data files can add gigabytes over a wipe. Unload a suspect plugin and watch the memory graph to find out.

Should I restart my Rust server every day?

On a busy server, yes. A daily restart recovers fragmented memory and any leak in a plugin, and it gives a predictable time for updates. It does not reduce entity count, so it will not rescue a server that is simply too small for its map at the end of a wipe.