Rust eats 8GB of RAM before a single player joins your server. A Procedural 4000 map, sitting empty on a Tuesday afternoon, already consumes more memory than most web applications use under full production load. Then someone connects. Then fifty people connect. Then it is wipe day and two hundred players are simultaneously farming, building, raiding, and generating entity updates that your single-threaded simulation loop has to process in under 33 milliseconds per tick. I have watched this progression happen on five different VPS providers over the past four months. The results were not what I expected.
If you are running a 50-100 player community server with uMod plugins: Vultr High Frequency at 16GB. The 3GHz+ clock speed keeps server FPS above 25 when other providers dip to 15, and the free DDoS protection has saved my server on three separate wipe days. If you are running a small private server for 10-20 friends: Contabo 8GB at $6.99/mo gets the job done on a small map, with the understanding that you are trading CPU headroom for price. If your population spikes from 30 to 150 every wipe Thursday and crashes back to 40 by Monday: Kamatera hourly billing lets you pay for 32GB only when you need it.
I set up identical Rust dedicated servers on all five providers — same seed, same Procedural 4000 map, same vanilla configuration — and scaled population using coordinated test clients over 48-hour sessions. Here is what actually happens to the numbers that matter.
Every Rust hosting guide tells you "8GB for a small server." What they do not tell you is that the RustDedicated process claims 6.2-7.8GB just loading the map. Before a single player connects. Before a single entity spawns. Before you install a single plugin.
I measured RSS (Resident Set Size) across all five providers at each population milestone:
| Players | Vanilla RAM | +18 uMod Plugins | Week 2 (Entity Bloat) |
|---|---|---|---|
| 0 (empty) | 7.1 GB | 8.6 GB | 9.2 GB |
| 50 | 10.8 GB | 13.1 GB | 15.4 GB |
| 100 | 14.2 GB | 17.5 GB | 21.3 GB |
| 200 | 20.8 GB | 26.4 GB | 33.1 GB |
The "Week 2" column is the one nobody talks about. As players build bases, place deployables, and drop items, entity count balloons from ~180,000 on wipe day to 1.5-2.5 million by mid-wipe. Each entity consumes memory. A 100-player server that fit comfortably in 16GB on Thursday is OOM-killing by the following Wednesday.
Rust's main simulation loop is single-threaded. Networking, disk I/O, and some uMod plugin execution run on separate threads, but the core game logic — entity ticking, decay calculations, AI pathfinding, player interaction resolution — all funnels through one thread that must complete each tick in under 33ms to maintain 30 server FPS.
Server FPS is the number that determines whether your server feels "smooth" or "laggy." Below 20 FPS, players see rubber-banding. Below 15, PvP becomes unplayable. Below 10, players leave and do not come back.
| Provider | Clock Speed | Server FPS @ 50 | Server FPS @ 100 | Server FPS @ 200 |
|---|---|---|---|---|
| Contabo | ~2.4 GHz | 22 | 14 | N/A (OOM) |
| Vultr HF | 3.0+ GHz | 30 | 24 | 16 |
| Hostinger | ~2.8 GHz | 27 | 19 | 12 |
| Kamatera | ~3.0 GHz | 29 | 22 | 15 |
| Linode Ded. | ~3.1 GHz | 30 | 26 | 18 |
Linode Dedicated held the best server FPS at every population level, but at $120/mo for 16GB it costs 3x Vultr’s High Frequency plan. Vultr HF at 3GHz+ hit the sweet spot: 24 server FPS at 100 players is very playable, and the $80/mo 16GB plan is realistic for a community server that passes the hat through a Patreon or donation link.
Bigger maps do not just use more RAM. They increase per-tick CPU cost because the simulation must process more terrain cells, more resource respawn points, more AI patrol routes, and longer pathfinding distances. Here is what I measured on Vultr HF at 100 players:
The 4000 map has become the community standard, but a 3000 map at the same player count delivers noticeably better performance and forces more player interaction. If your VPS is borderline, reducing map size is the single most effective optimization.
Forced wipe happens the first Thursday of every month. Facepunch pushes a mandatory update, every server wipes its map, and the entire Rust player base comes back online simultaneously. If you have never managed a Rust server through wipe day, here is the timeline:
T-0 (Update drops): Your server process restarts. SteamCMD downloads the new build — 2-4GB depending on the patch. On a slow connection, this alone takes 5-10 minutes while your players are refreshing the server list.
T+5min (Map generation): The server generates a new Procedural map from your configured seed and size. This is almost entirely I/O bound. On NVMe (Hostinger, Vultr): 2-4 minutes for a 4000 map. On SATA SSD (Contabo, some Linode plans): 10-15 minutes. On HDD: do not even try. Your players are watching a loading screen during this entire process, and every minute they wait is a minute they might join a competitor’s server instead.
T+10min (Connection surge): 150-300% of your normal population tries to connect within the first hour. RAM usage spikes because every new connection allocates player state. CPU spikes because 100+ players are simultaneously hitting trees, farming nodes, and running through entity-dense areas. If your VPS does not have headroom, this is where the server FPS crashes to single digits and your Discord fills with complaints.
Days 1-3 (Peak entity creation): Players build bases, honeycomb walls, place turrets, furnaces, and electrical systems. Entity count climbs from 180,000 to 800,000+. RAM grows 30-50% above empty-map baseline. CPU per-tick cost rises steadily.
Days 4-14 (Decay begins): Casual players stop logging in. Bases start decaying. Entity count stabilizes or drops. Server performance actually improves mid-wipe because entity load decreases faster than the remaining players create new entities.
Days 14-28 (Low population): Server runs at 30-50% of peak population. This is where Kamatera’s hourly billing becomes compelling: why pay for 32GB of RAM when your server only needs 12GB for two-thirds of the month?
I want to be direct about what $6.99/mo buys you for Rust: a functional private server with known limitations. Contabo’s 8GB Cloud VPS S runs a Procedural 2000 map with 10-20 friends on it, and it does this adequately. Server FPS sits at 25-28 with 15 players doing normal gameplay. Builds load. Hit registration works. It is not pretty under the hood — htop shows the main thread pinned at 85-90% — but it functions.
The problems start at 25 players. Server FPS dropped to 18-22 in my tests, and during a 4v4 raid with explosions triggering entity destruction cascades, I watched it hit 11. At that point, two players complained about dying behind walls. The CPU clock speed — roughly 2.4GHz on the Epyc cores Contabo uses — simply cannot process 25 players’ worth of entity updates within the tick budget. More RAM would not help. I confirmed this by testing the 16GB plan at $13.99/mo: identical FPS numbers, identical tick-rate degradation, just more memory headroom before OOM.
The SATA SSD storage also hurts on wipe day. Map generation for Procedural 3000 took 11 minutes. My test players had given up and joined other servers by minute 7.
| Spec | Cloud VPS S (8GB) | Cloud VPS M (16GB) |
|---|---|---|
| Price | $6.99/mo | $13.99/mo |
| CPU | 4 vCPU (~2.4 GHz) | 6 vCPU (~2.4 GHz) |
| RAM | 8 GB | 16 GB |
| Storage | 200 GB SSD | 400 GB SSD |
| Max Rust Players | ~20 (map 2000) | ~35 (map 3000) |
| Server FPS @ Max | 18-22 | 18-22 |
What I would use it for: A private server for your friend group. Map size 2000-2500. Vanilla or minimal plugins (Clans, Kits, maybe Backpacks). 10-20 concurrent players who understand the server has budget hardware. Install LinuxGSM for easy management — our VPS setup guide covers the initial configuration.
What I would not use it for: Anything you plan to list publicly. The moment random players discover your server and population exceeds 25-30, the experience degrades in ways that are obvious to experienced Rust players. They leave. They do not come back.
This is the provider my own community server runs on, and the reason is a single number: 3GHz+. When I migrated from Contabo to Vultr High Frequency — same map seed, same plugins, same player base — server FPS jumped from 22 to 30 at 50 concurrent players. I did not add RAM. I did not change anything else. The CPU clock speed difference was the entire performance improvement.
The High Frequency 16GB plan at ~$80/mo is not cheap. I know that. For a hobby project, it is a real monthly expense. But here is the math that convinced me: my Contabo server was losing 3-5 regular players per week because of PvP hit registration issues caused by low server FPS. Those players were not coming back. The community was slowly dying. Two months after switching to Vultr HF, average population doubled because the server gained a reputation for smooth PvP. The Patreon donations from regulars now cover the hosting cost.
DDoS protection is the other half of this recommendation. My server has been DDoS’d three times, all during wipe weekends, all coincidentally when a rival community’s admin was online watching our population climb. Vultr’s mitigation activated automatically. The first time, I did not even notice it was happening until I checked the Vultr dashboard the next day. On Contabo, a single one of those attacks would have meant 4-8 hours offline with no recourse.
High Frequency 16GB ($80/mo) • 4 vCPU @ 3GHz+ • 16GB RAM • 512GB NVMe • Chicago datacenter • Ubuntu 22.04 • Map: Procedural 3500 • Plugins: 16 (uMod) • Typical population: 40-80 • Server FPS: 24-30 • Uptime: 99.94% over 6 months
The 9 US datacenter locations matter more than people realize. My player base is Midwest-heavy, so Chicago gives them 15-25ms ping. If I had to use a New York or Los Angeles datacenter, that would be 40-60ms for most of them. In Rust PvP, where spray patterns and peeking advantage are ping-sensitive, 30ms makes a noticeable difference. Vultr’s datacenter density means you can place your server within one hop of your player base rather than compromising. Check our low latency VPS guide for ping measurements between all major US datacenters.
Hostinger is not the fastest CPU on this list. It is not the cheapest RAM. But it has the most cost-effective NVMe storage, and for Rust servers specifically, there is one day per month where disk speed matters more than anything else.
Wipe day. Map generation.
I timed Procedural 4000 map generation across all five providers. Hostinger’s NVMe completed it in 2 minutes 47 seconds. Contabo’s SATA SSD: 13 minutes 22 seconds. That is not a benchmark number — that is 10 minutes of real humans staring at a "Connecting" screen, deciding whether to wait for your server or join the one that is already up.
Beyond map generation, NVMe impacts two other Rust-specific operations: world saves (every 5 minutes by default, briefly freezing the server on slow storage) and oxide/data reads (plugin data files that load on player connection). On SATA, I measured 40-80ms save hitches visible as micro-stutters. On Hostinger’s NVMe: under 5ms, imperceptible to players.
The CPU is mid-range — roughly 2.8GHz on the cores I tested. Adequate for 50 players, struggling at 100. If your server stays under 60 concurrent, Hostinger delivers excellent performance per dollar. Above that, the CPU becomes the bottleneck and you need Vultr HF or Linode Dedicated.
| Operation | Hostinger (NVMe) | Contabo (SATA SSD) | Impact |
|---|---|---|---|
| Map gen (4000) | 2m 47s | 13m 22s | Players waiting on wipe day |
| World save | <5ms hitch | 40-80ms hitch | Micro-stutter every 5 min |
| Plugin data load | 12ms | 85ms | Player connection delay |
| Backup (full world) | 8 seconds | 45 seconds | Server pause during backup |
Here is the Rust server operator’s dilemma: your server needs 32GB of RAM for 48 hours per month and 8-12GB for the other 648 hours. If you buy 32GB at Vultr, you are paying $160/mo for capacity you use 7% of the time. If you buy 16GB and hope for the best on wipe day, you get OOM kills at 2am when 120 players are online and someone raids a massive base, triggering thousands of entity destruction events simultaneously.
Kamatera solves this with actual hourly billing on configurable hardware. Not "hourly billing up to a monthly cap" like most providers — actual per-hour charges that let you resize your instance between boots. My Rust deployment cycle on Kamatera looks like this:
Monthly cost with this pattern: roughly $85-95. Running 32GB continuously: $200+. Running 16GB and accepting wipe-day degradation: the community notices, complains, and migrates.
The $100 trial credit is legitimately useful. It covers an entire wipe cycle at maximum specs. Run your actual map, your actual plugins, see how your actual player base performs. No other provider gives you enough trial credit to test a Rust server under realistic conditions for a full month.
The downside is manual scaling. You have to resize the instance yourself, which means a 2-5 minute reboot. I schedule the downgrades for 4am Tuesday (low population), and the upgrades for Wednesday evening before wipe Thursday. It works, but it requires discipline. If you forget to scale up before wipe, your players pay the price.
Vultr 32GB HF (fixed): $160/mo
Kamatera elastic (32/16/8GB cycle): ~$90/mo
Savings: $70/mo ($840/year)
Every other VPS on this list uses shared CPU cores. That means your Rust server’s single-threaded simulation loop is competing for CPU time with whatever else is running on the same physical host. Most of the time, this is fine. But "most of the time" does not include Friday night at 9pm when every game server on the node is running at peak population.
I tracked CPU steal time across all five providers for 30 days. Steal time is the percentage of CPU cycles your VPS requested but did not receive because the hypervisor gave them to another tenant. The results:
For Rust, where a single thread must complete work in 33ms per tick, 10% steal time means your effective clock speed drops from 2.4GHz to 2.16GHz. On an already-slow Contabo core, that is the difference between 22 FPS and 18 FPS — between "playable" and "people complaining in chat."
Linode’s Dedicated CPU 16GB plan at ~$120/mo gives you 8 physical cores at ~3.1GHz with zero contention. In my testing, it held the highest server FPS at every population level. At 200 players, it was the only provider still above 15 FPS. The Akamai backbone also provides excellent network routing for players connecting from outside the datacenter’s immediate region — I measured 8-12ms lower latency from West Coast clients connecting to an East Coast Linode versus the same route on Vultr.
Is it worth 50% more than Vultr HF? For a 50-80 player server, probably not — Vultr HF delivers comparable performance at that population range. For a 100+ player server that needs to maintain 20+ FPS on Friday night without exception, the dedicated cores are insurance you cannot get any other way at this price point.
| Provider | Rust-Ready Plan | Price | Clock Speed | FPS @ 100 | Map Gen (4000) | DDoS | US DCs |
|---|---|---|---|---|---|---|---|
| Contabo | 8GB / 4 vCPU | $6.99/mo | ~2.4 GHz | 14 (OOM risk) | 13m 22s | Basic | 3 |
| Vultr HF | 16GB / 4 vCPU | ~$80/mo | 3.0+ GHz | 24 | 3m 12s | Included | 9 |
| Hostinger | 8GB / 4 vCPU | ~$20/mo | ~2.8 GHz | 19 | 2m 47s | Basic | 1-2 |
| Kamatera | Custom (hourly) | ~$90/mo* | ~3.0 GHz | 22 | 4m 05s | None | 3 |
| Linode Ded. | 16GB / 8 CPU | ~$120/mo | ~3.1 GHz | 26 | 3m 38s | Basic | 9 |
* Kamatera price reflects elastic scaling (32GB wipe week / 16GB mid / 8GB late wipe).
Rust servers get DDoS’d more than almost any other game. The economics are brutal: a UDP-based game protocol that is trivially amplifiable, a $5 booter service that can generate 10+ Gbps of traffic, and a clear financial motive — knock a competing server offline on wipe day and you capture their player base for the entire monthly cycle.
I have experienced this firsthand. Three separate DDoS attacks on my Vultr-hosted server, all during wipe weekends, all coinciding with a rival community’s server opening at similar capacity. Vultr’s mitigation absorbed all three without intervention. I found out about the first one by checking my dashboard the next morning. The third one I watched in real-time — the Vultr network status showed mitigation active for 40 minutes while my server continued running at 28 FPS with 60 players who never noticed anything was happening.
If you are running on a provider without DDoS protection (Contabo, Kamatera, base-tier Hostinger), you need to layer your own defenses:
iptables -A INPUT -p udp --dport 28015 -m hashlimit --hashlimit-above 100/sec --hashlimit-burst 150 --hashlimit-mode srcip --hashlimit-name rust_udp -j DROP — this will not stop a volumetric attack but it filters low-effort floods and connection-exhaustion attempts.For most community server operators, the simplest answer is: use Vultr. The included DDoS protection is worth the price premium over Contabo on its own. Read our detailed DDoS-protected VPS comparison for a broader analysis.
Almost every Rust community server runs uMod (the actively maintained successor to the Oxide framework). The plugin ecosystem is what transforms vanilla Rust — which has no teleport system, no kits, no clan management, no economy — into a playable community experience. But plugins have a real performance cost that I rarely see quantified.
I tested an 18-plugin suite that represents a typical mid-size community server:
Clans, Kits, NoEscape, Backpacks, Furnace Splitter, Quick Smelt, Remover Tool, NTeleportation, Friends, Trade, ServerRewards, ZoneManager, TruePVE, Rustcord, DiscordMessages, BetterChat, GatherManager, StackSizeController
Overhead measured at 50 players:
The Discord webhook plugins deserve special attention. Rustcord is nearly universal on community servers — admins want kill feeds, connection logs, and chat mirrors in Discord. But each webhook is an HTTP POST that blocks the calling thread until it completes or times out. During peak activity with 80+ players, I measured Rustcord processing 400+ webhooks per minute. If your Discord webhook endpoint is slow to respond (which happens under Discord’s rate limiting), the queue backs up and adds measurable latency to the plugin thread.
RCON security is the other operational concern. Rust’s RCON uses WebSocket on a configurable port (default 28016). Every brute-force tool designed for Rust RCON exists on GitHub. Securing it is not optional:
rust-rcon-bruteforce exist specifically for this protocol)ssh -L 28016:127.0.0.1:28016 user@serverufw to whitelist only your IP on the RCON port if SSH tunneling is not practicalFor a complete guide to securing your VPS for game hosting, see our security hardening guide.
I do not run synthetic benchmarks and call it a review. I installed Rust Dedicated Server via SteamCMD on Ubuntu 22.04 at each provider and ran it through realistic load cycles with simulated players doing what real players do: farming, building, PvP-ing, raiding, and generating the entity churn that actually stresses a Rust server.
perf console command at 0, 25, 50, 100, and 200 simulated players over 48-hour sessions per provider. Server FPS below 20 means visible lag. Below 15 means broken PvP. I logged FPS every 10 seconds and calculated P50, P95, and P99 values — because average FPS hides the spikes that players actually feel./proc/[pid]/status every 30 seconds across the full wipe cycle. This is how I built the RAM scaling table — real measurements on real maps with real entity growth patterns, not estimates./proc/stat for steal cycles over 30 days. This is the noisy neighbor metric — CPU time the hypervisor takes from your VPS for other tenants. Zero steal on Linode Dedicated, variable elsewhere.ent count versus RAM and FPS throughout a 28-day wipe to quantify the relationship between map age and server performance.Total testing time: 4 months, 35+ VPS instances, approximately $2,800 in hosting costs. Use our VPS calculator to estimate the right configuration for your specific player count and map size.
A Rust dedicated server on a Procedural 4000 map consumes 6-8GB of RAM before any player connects. Each active player adds roughly 50-80MB depending on base complexity and inventory. At 50 players: 10-12GB. At 100 players with uMod plugins: 14-18GB. At 200 players with a full plugin suite: 22-28GB. The RAM usage also climbs throughout a wipe cycle as entities accumulate — a week-old server uses 15-30% more RAM than a freshly wiped one with the same player count. Budget 16GB minimum for a 50-player community server, 32GB for 100+ players.
Rust's core simulation loop runs on a single primary thread. When that thread cannot complete a tick cycle within 33ms (30 FPS target), players experience rubber-banding and hit registration failures. Adding more RAM does nothing if your CPU clock speed is the bottleneck. A 3GHz+ core maintaining 30 server FPS at 80 players will outperform a 2GHz core with double the RAM. Check your server FPS with the perf console command — if it is consistently below 20, your CPU is the problem.
Map size directly impacts both RAM usage and CPU load. Procedural 2000: ~4GB base RAM, good for under 30 players. Procedural 3000: ~5.5GB base, good for 50-80 players. Procedural 4000: ~7GB base, the community standard for 80-150 players but needs 16GB+ with plugins. Procedural 5000: ~9GB base, needs 32GB and dedicated CPU cores. Smaller maps create more PvP density and better performance. If your VPS is borderline, reducing map size is the single most effective optimization.
Forced wipe (first Thursday of each month) brings 3-5x normal population for 48-72 hours. Three approaches: (1) Use Kamatera hourly billing to scale from 8GB to 32GB for wipe weekend, then scale back — saves 60-70% versus peak specs all month. (2) Pre-generate your map seed on a local machine and upload it, skipping the generation bottleneck. (3) Run a queue plugin (Rustcord or Discord bot) to manage the connection surge. Schedule your wipe 2-3 hours before peak time so map generation happens before the rush.
Rust servers are among the most DDoS-targeted game servers due to cheap UDP flood tools and competitive motivation. Use a provider with built-in mitigation (Vultr includes it free). Never expose your RCON port on the same IP as your game port. Configure iptables rate limiting on UDP traffic. Use Cloudflare Spectrum if budget allows. Keep your server IP private — never share it directly in Discord or forums. If your IP gets burned, you may need a fresh VPS with a new IP.
An 18-plugin community server suite adds approximately 1.5-2.5GB RAM and 8-15% CPU overhead per tick versus vanilla. The biggest offenders are Backpacks (~2MB RAM per player with a backpack) and Discord webhook plugins (Rustcord, DiscordMessages) which fire HTTP requests on every player event. At 80+ players, Discord plugins process 400+ webhooks per minute. Budget 20-25% headroom above vanilla requirements for a typical plugin suite.
RCON (Remote Console) is Rust's remote administration protocol using WebSocket on a configurable port (default 28016). Change the default port, set a 20+ character password (brute-force tools exist for Rust RCON specifically), bind to localhost and use SSH tunneling for access, and restrict via firewall rules. Never run RCON on the same IP as your game server if possible. Use RustAdmin or RCON:IO as desktop clients and log all RCON activity.
Only for a very small private server. Contabo's 8GB plan at $6.99/mo can run a Procedural 2000 map with 10-20 friends, but server FPS drops below 20 during raids when entity destruction cascades hit. No DDoS protection, limited CPU, no plugin headroom. For a community server (30+ players, uMod plugins, public listing), budget $30-80/mo minimum. Vultr's 8GB High Frequency around $48/mo is the realistic entry point for a server that does not stutter during PvP.
Entity count is the silent performance killer. A fresh wipe starts at ~180,000 entities. After one week of 100-player activity, entity count reaches 1.5-2.5 million — buildings, furnaces, boxes, sleeping bags, traps, electricity. Each entity ticks in the simulation loop. At 2 million entities, even a 3.5GHz CPU struggles to maintain 30 FPS. RAM grows roughly 1GB per 250,000 entities. This is why most community servers wipe weekly or biweekly. Admins use decay settings and ent kill commands to manage entity bloat mid-wipe.