Rust Dedicated Server Hardware Sizing 2026: RAM, CPU, and Storage for High-Population Wipes

Rust Dedicated Server Hardware: Why Sizing Is Different

Rust (the survival game, not the programming language) is one of the most hardware-hungry mainstream dedicated servers. A wipe-day server with 200 concurrent players will consume more RAM and produce more entity-churn than a Minecraft network three times its player count. The reason is that Rust keeps every deployed structure, door, box, and deployable as a persistent entity simulated continuously across the entire map.

This guide covers sizing from the server binary’s actual behavior: entity count drives memory, map size drives generation cost, and player concurrency drives network and CPU. For bare-metal spec context, see our dedicated hardware overview.

The Three Load Drivers

1. Entity count — deployed structures and deployables. A 300-player monthly-wipe server can accumulate 400,000+ entities by mid-wipe. This is the dominant RAM driver.
2. Map size — procedural generation cost scales with size. A 6000-size map generates in 3-6 minutes on 8 cores; a 4000-size map in under 2 minutes.
3. Concurrent players — network bandwidth and anti-cheat CPU. Roughly 40-80 Kbps per player, higher during combat with many entities in view.

Hardware Tiers by Server Population

Scenario	vCPU	RAM	Storage	Map size
Small community, 30-50 players	4-6	12-16 GB	NVMe 500 GB	3000-4000
Mid server, 100-150 players	8-12	24-32 GB	NVMe 1 TB	4000-4500
Large monthly-wipe, 200-300 players	16-24	48-64 GB	NVMe 2 TB (RAID 1)	5000-6000
Clan/competitive, 300+ players	32+	96-128 GB	NVMe 4 TB (RAID 10)	6000 + custom

Why 64 GB Is the Real Entry Point for Big Wipes

Rust servers leak memory across long uptimes — not a bug so much as accumulation of entity references and the Unity garbage collector’s reluctance to compact under sustained load. A server that starts a wipe at 18 GB RSS can reach 40 GB by day 20. On a 32 GB box, that means a scheduled restart every 12-24 hours. On 64 GB, you can run 3-5 days between restarts, which is far friendlier to a populated server.

CPU: Clocks Beat Cores (With a Caveat)

Rust’s server tick and entity simulation thread benefits from high single-thread clock speed, but unlike Minecraft it uses significant parallelism for physics, networking, and anti-cheat. The practical sweet spot for a 200-player server is 16 cores at 4.5+ GHz base. Beyond 24 cores, returns diminish unless you are running multiple instances.

Wipe-day generation is the exception: it will saturate all available cores for several minutes. If your operation accepts player joins immediately on wipe, 16+ cores materially reduce the “map still generating” window.

Storage and the Wipe-Day I/O Burst

Rust saves the entire world to disk on a schedule controlled by server.saveinterval (default 600 seconds). A 200-player server with a 6000 map produces save files of 1-5 GB. Every 10 minutes, the server writes that in one operation, then compresses it.

• Use NVMe, not SATA. Save operations that take 400 ms on NVMe take 3+ seconds on SATA — and the server stutters during the write.
• Keep server.saveinterval at 300-600 for populated servers; do not extend it to reduce I/O, as longer intervals mean bigger writes and worse worst-case stalls.
• Store backups on a separate volume or remote object storage. Never on the live server’s boot disk.

Network Sizing

Rust traffic is bursty and entity-driven. A player standing in a base sees minimal traffic; a raid with 40 players and thousands of entities in view can push 200 Kbps per player. Plan on 1 Mbps of commit per 15-20 concurrent players at peak, with a 1 Gbps port. Monthly traffic for a 200-player monthly-wipe server typically lands between 8 and 20 TB.

DDoS exposure matters more for Rust than most games because public server lists attract volumetric attacks. Dedicated IPs with always-on filtering are worth the cost over the “on-demand” model that requires you to notice the attack first.

Server ConVars That Interact With Hardware

ConVar	Hardware impact
server.maxplayers	Directly sets RAM and network ceiling; raising it on undersized RAM causes OOM kills
server.worldsize	Generation CPU and disk size; 6000 max recommended without custom config
server.saveinterval	Disk write frequency and save-file size
server.tickrate	CPU per tick; 30 is standard, higher rates multiply CPU cost
gc.buffer	Memory reserved for GC; too low causes hitches, too high wastes RAM

Sizing Summary

• Budget 16 GB RAM as the floor for any server over 100 players.
• 64 GB is the practical target for 200-300 player monthly wipes.
• 16 cores at 4.5+ GHz handles the tick loop and wipe generation.
• NVMe for the live world; separate storage for backups.
• 1 Gbps port, always-on DDoS filtering, 10-20 TB monthly commit.

Rust rewards overprovisioning RAM more than almost any other game server. Start one tier above your measured peak — the cost difference between 32 GB and 64 GB is small compared to the damage a mid-wipe OOM crash does to your community. For current bare-metal configurations suited to this workload, see the hardware options on our main site.