Rust Server Requirements: CPU, RAM and Bandwidth Explained

Rust is one of the heaviest multiplayer games to host, and the requirements pages you find online are often either copied from 2018 or quietly optimistic. This guide sets out what a Rust dedicated server actually needs in RAM, CPU, bandwidth and disk — and, just as importantly, why those needs change over the course of a wipe cycle.

The numbers apply whether you self-host on your own hardware or rent. If you are comparing rented plans, our Rust server hosting tiers are sized against the same tables below, so you can match a plan to your map size and player cap rather than guessing from a slider. Either way, the principles are identical: Rust punishes slow cores, small memory allocations and mechanical disks more than almost any other game.

How much RAM does a Rust server need?

RAM usage in Rust is driven by three things: the size of the procedurally generated map, the number of connected players, and — the one everyone forgets — the number of entities in the world. Every wall, foundation, box, turret and dropped item is an entity the server keeps in memory, and entity counts climb relentlessly between wipes.

Two important caveats. First, these figures describe a server late in its wipe cycle, when bases sprawl across the map. A freshly wiped server uses noticeably less, which is exactly why undersized servers feel fine for the first week and then fall apart. Second, map generation itself is a memory spike: generating a large procedural map on boot can briefly exceed steady-state usage, so a server that is borderline on RAM may fail to start at all with a big map.

Why does single-core CPU speed matter so much?

Rust's server runs on Unity, and its main simulation loop — physics, AI, entity updates — is effectively bound to a small number of threads. Throwing sixteen slow cores at it achieves very little; what raises server FPS (the tick-rate equivalent Rust admins watch) is raw per-core performance. A modern desktop-class CPU at high clocks will comfortably outperform an older many-core server chip for this workload.

This is also the number-one thing to interrogate when renting. Two hosts can both advertise “16GB Rust server” while one runs it on a recent Ryzen with strong single-core performance and the other on an oversold, decade-old Xeon. If a host will not tell you what CPU sits behind a plan, assume the worst. As a rule of thumb, aim for 4–6 fast cores dedicated to the server: enough for the main loop, the networking threads, and background saves without contention.

How much bandwidth does a Rust server use?

Less than most people fear. Per-player traffic varies with activity — big raids and dense monuments generate more updates than quiet farming — but a sensible planning figure is in the low hundreds of kilobits per second per player. In round numbers, 100 concurrent players fits comfortably within a 50–100Mbps uplink, and any serious datacentre connection handles it without thought.

The catch for self-hosters is the direction: consumer broadband is asymmetric, and it is your upload that serves players. A UK connection with 20Mbps up will struggle beyond a few dozen players, and if your ISP uses CGNAT you cannot accept inbound connections at all without a tunnel. There is also a one-off cost per player to consider: on first connect, clients download the map from the server (or a map-hosting URL), which is a burst of tens of megabytes per new player — noticeable on wipe day when everyone joins at once.

What disk and operating system should you use?

Budget 20–30GB of storage: the server install is several gigabytes, updates arrive monthly and are often large, and saves plus backups accumulate. Speed matters more than size. Rust autosaves the entire entity state at regular intervals, and on a mechanical drive those saves cause the whole server to hitch. NVMe is the sensible default in 2026; SATA SSD is the minimum acceptable.

The server runs on both Windows and Linux via SteamCMD (app ID 258550). Linux is the standard choice for rented machines — it is lighter, easier to automate with systemd, and both the Oxide and Carbon modding frameworks support it fully. Whichever OS you pick, script your update path: Facepunch ships a mandatory update on the first Thursday of every month, and an un-updated server rejects updated clients within minutes of the patch landing.

How do wipes change your planning?

Rust's monthly rhythm is unusual among survival games and it shapes hardware planning in two ways. First, the forced wipe on the first Thursday of each month resets the map (and, when Facepunch says so, blueprints), which resets your entity count — so memory pressure follows a sawtooth pattern, lowest on wipe day and highest the night before the next one. Size your RAM for the peak, not the trough.

Second, wipe day itself is your load test. Population spikes hard in the first hours after a wipe: everyone connects at once, downloads the map, and sprints for beach loot. CPU load and bandwidth both peak while total entity count is at its lowest. If your server survives wipe evening without queueing or stuttering, the rest of the month is usually comfortable. Many admins schedule a restart shortly before their advertised wipe time and pre-generate or pre-upload the new map so the download burst starts immediately.

Do plugins and mods raise the requirements?

Somewhat, and less than reputation suggests. The Oxide and Carbon frameworks themselves are lightweight. The cost comes from what you install on top: teleport and kit plugins are trivial, while plugins that scan every entity, hook high-frequency events, or maintain large databases (leaderboards, clan systems, custom loot across the whole map) can measurably increase CPU and memory usage. The practical rule is to add plugins in small batches and watch server FPS after each — a single badly written plugin causes more lag than fifty good ones.

Heavily modded servers — custom maps with dense prefabs, NPC raid bases, drivable everything — sit a full tier above the vanilla table earlier in this guide. If you are building one of those, start from 16GB even for a modest population and treat strong single-core performance as non-negotiable.

Frequently asked questions

The bottom line

Plan a Rust server around three numbers: 8GB of RAM as a hard floor, 16GB for the standard 3,500–4,000 map with a real population, and a CPU chosen for per-core speed rather than core count — all on SSD or NVMe storage. Then remember the sawtooth: usage grows all month and resets at the forced wipe, so a server that is sized for day one will be gasping by week three. Size for the last night of the wipe and everything else gets easier.