Rust Server Requirements Calculator

Rust Dedicated Server Requirements

Facepunch's official wiki lists a baseline of 12 GB of free RAM (noting that a 6k map will use more) and 15 GB of free disk space, with SSD or NVMe storage “highly preferred.” Treat 12 GB as a practical floor, not a target. Rust's resource use is unusually variable, so it pays to understand what drives each requirement.

RAM — driven by map size first, players last

The single biggest memory consumer is the +server.worldsize value. Larger maps generate more terrain, monuments, and procedural content that the server must hold in memory, and RAM use scales steeply with map size. Facepunch recommends 3500 as the sweet spot for most servers — large enough to roam, but generating meaningfully fewer entities than a 4k+ map. Valid values run from 1000 to 6000; going above 4500 should only be done on a machine with serious RAM and CPU headroom.

• 3000-3500 map: roughly 8-10 GB baseline before plugins and a full wipe of entities.
• 4000-4500 map: roughly 10-14 GB baseline.
• 5000-6000 map: 14+ GB baseline, climbing fast.

Players themselves are a relatively small contributor — on the order of tens of megabytes each (RAM calculators allocate well under a gigabyte total for a full slot list). The second major driver is the entity count: every deployed wall, foundation, sleeping bag, and dropped item is a tracked entity. A healthy mid-wipe server stays under ~200,000 entities; past ~300,000, tick-rate degradation becomes player-noticeable, and underpowered boxes crash. Plan RAM for the end of your wipe cycle, not day one.

CPU — clock speed over cores

Rust's server simulation (tick rate, physics, AI, plugin logic) runs predominantly on one or two threads. A high-frequency 4-core CPU will outperform a 16-core server chip with a low base clock. Aim for 4.0 GHz+ boost clocks; 3.0-3.4 GHz is a realistic floor only for small maps. Each RustDedicated instance wants 2-4 fast dedicated cores; the extra cores help world saves, networking, and Oxide/Carbon compilation rather than the main loop. Server “FPS” (tick rate) is the health metric — 60 is ideal, and Facepunch notes 30 is fine in practice, so treat a sustained drop below 30 under load as the warning sign.

Storage

The install plus a world save fits in roughly 15-20 GB, and disk does not grow much with player count. Use SSD/NVMe: Rust performs periodic full world saves that stall the simulation, and slow disks turn those saves into visible lag spikes. NVMe meaningfully shortens save time on large maps.

Network / Bandwidth

Plan upload capacity of roughly 2 Mbps per player minimum, 4 Mbps recommended — so ~200-400 Mbps for a 100-player server. A 1 Gbps uplink is ideal for popular servers, and 100 Mbps is a sensible minimum line. Latency matters for hit registration, so server location relative to your playerbase is important. Rust uses UDP (default game port 28015) plus a query port and an optional RCON port. Monthly egress works out to roughly 10-15 GB per active player depending on activity and plugins.

Vanilla vs. modded

A vanilla server is mostly bound by map size and entity count. Modded servers (Oxide/uMod or Carbon) add plugin memory and CPU overhead — budget roughly 1.5-2x the RAM for a heavily modded box, more if plugins spawn or track lots of entities (zombies, NPCs, extra loot).

Optimizing a Rust Server

Most Rust performance problems are self-inflicted through map size and entity sprawl. The fixes are concrete:

Pick a sane map size

Set +server.worldsize 3500 unless you have a specific reason and the hardware to go bigger. Dropping from 4500 to 3500 can cut baseline RAM by several gigabytes and noticeably raise server FPS. Avoid 4500+ without a high-clock CPU and ample RAM.

Control entity buildup

Entity count is the number-one killer of late-wipe performance — aim to stay under ~200k mid-wipe and treat ~300k as the danger zone. Use automated cleanup: an inactive-base purge (for example, removing bases of players offline 48+ hours) keeps counts manageable. Entity-reducer plugins can trim naturally spawning props, and clearing entities outside Tool Cupboard range reclaims memory mid-wipe.

Wipe on a schedule

Performance degrades steadily across a wipe as entities accumulate. A regular wipe cadence (weekly or biweekly is common) is the simplest performance tool you have — it resets the entity count to near zero.

Tune the server config

• Keep save settings reasonable; server.saveinterval too low causes frequent stutters, too high risks more lost progress on a crash.
• Monitor server.fps in console — if it sits below 30 under load, you are CPU-bound (reduce map/entities/plugins) or out of RAM.
• Tune the Unity garbage collector buffer to trade frequent micro-stutters for rarer, less noticeable GC hitches.
• Audit plugins: a single poorly written Oxide plugin can tank tick rate. Disable plugins one at a time to isolate offenders.
• Consider Carbon as an Oxide-compatible framework — most uMod plugins run on it unchanged and some operators see better performance.

Hardware-side wins

Put the server on NVMe to shorten world-save stalls, pin the instance to your fastest cores, and leave RAM headroom for end-of-wipe peaks rather than sizing for day one. If you run multiple Rust instances on one box, give each its own dedicated fast cores.

What to Look For in a Rust Host

Rust's quirks make some host features genuinely important rather than marketing checkboxes:

• High single-thread CPU performance. This is the most important spec for Rust and the hardest to judge from a listing. Look for hosts that publish the actual CPU model or advertise high-clock chips. A high core count at a low clock is the wrong tradeoff for Rust.
• Enough RAM headroom for your map and late wipe. Size for the end of a wipe cycle and your chosen worldsize, not the minimum — Facepunch's 12 GB baseline is a floor. RAM that is fine on day one can OOM-crash the server in week two.
• NVMe/SSD storage. Directly affects world-save lag spikes; large maps benefit most from NVMe.
• DDoS protection. Rust servers are frequent targets; layer-3/4 mitigation that does not add latency is valuable.
• Server location and low latency to your playerbase, since hit registration depends on it.
• One-click Oxide/Carbon install and easy plugin/file management (FTP/SFTP) if you plan to mod.
• Console/RCON access for live commands and monitoring server FPS and entity counts.
• Automated backups and easy wipe tooling, since regular wipes are part of normal Rust operation.
• Adequate upload bandwidth (roughly 2-4 Mbps per slot) without restrictive monthly transfer caps.

For self-hosting, the same priorities apply: a high-clock CPU, NVMe disk, generous RAM, and a stable upload pipe with a static IP and the ability to forward the UDP game and query ports.

CPU note: Heavily single-thread-bound (Unity engine). Prioritize high clock speed (4.0 GHz+ boost) over core count. The main game simulation runs on one or two cores; extra cores only help world saves, networking, and plugin compilation. Give each RustDedicated instance 2-4 fast dedicated cores; a 16-core low-clock Xeon will perform worse than a 4-core high-clock desktop CPU.

RAM is driven primarily by map size (+server.worldsize) and entity buildup over the wipe cycle, NOT player count, so the per-player figure is small (~50 MB). Facepunch's official baseline is 12 GB free RAM and 15 GB SSD/NVMe disk; treat 12 GB as a practical floor for any real server. The base_ram_gb here (8 GB) reflects the simulation + a recommended 3000-3500 worldsize before plugins and a full wipe of entities, but the smallest tier starts at 12 GB to match Facepunch's baseline. A 6k map can push baseline well above 12 GB. Size RAM for the END of your wipe cycle, and apply the modded multiplier (1.5-2x) for Oxide/Carbon servers with many plugins.