How Much RAM Does a 100-Player Rust Server Need? About 12GB — But That's Not Your Problem

Ask this question in a community and you’ll get answers between 16GB and 48GB. They can’t all be right, and the spread has a cause: most people answering are describing a server that ran badly, not a server that ran out of memory. Those are different problems with different fixes.

Here’s the arithmetic, derived from a host that actually has to run these servers.

Deriving it from published tiers

Shockbyte publishes two Rust tiers with both RAM and player count, read live in August 2026:

Two points give you a line. Going from 40 to 75 players — 35 more — costs 2GB:

• Marginal cost: about 59MB per player
• Baseline: about 5.7GB before anyone connects

That 59MB figure is worth pausing on, because the commonly repeated community rule of thumb is 50–100MB per player. We derived ours from a vendor’s own pricing tiers rather than from folklore, and it lands inside that range — which is decent mutual corroboration for a number nobody publishes officially.

Extrapolating the line:

So: about 12GB for 100 players, and buy 16GB. The headroom matters because the line is fitted from two points, mods add entities the fit doesn’t know about, and a server that OOMs at peak is worse than one that cost $10 more.

Why the answers scatter so wildly

Because “my Rust server is struggling” usually isn’t a memory problem at all.

Rust’s server tick is heavily single-threaded, so the binding constraint on a 100-player server is far more often single-core CPU speed than RAM. Someone who added RAM and saw no improvement concludes they need even more RAM. Someone who moved host and got a faster core concludes the extra RAM fixed it. That’s how you end up with 48GB recommendations.

Adding RAM does not raise your server FPS. If the tick is slow, the tick is slow.

This is also why only one of four Rust hosts publishing a CPU model is such a problem — you can compare gigabytes across every host in the market and none of them will tell you the number that actually decides how the server feels.

The two failure signatures

These are what people are really searching for, and they’re easy to tell apart once you know.

Out of memory: the server dies silently.

The process is simply gone. The console log ends mid-line with no error and no stack trace, and the server restarts if you have a watchdog — or just stays down if you don’t. In Docker you’ll see exit code 137.

Confirm it in one command:

sudo dmesg -T | grep -i -E 'killed process|out of memory'

If there’s no match, it wasn’t the OOM killer — and every memory fix you were about to try is wasted effort. We covered the full diagnostic flow, including why the process the kernel kills is usually the largest one rather than the one at fault.

CPU saturation: the server suffers but survives.

Server FPS falls in the console. Players rubber-band, building feels laggy, combat desyncs. But the process stays alive and dmesg shows nothing.

That distinction is the whole diagnosis:

Check dmesg before you buy anything. It’s free and it tells you which of the two you have.

The variable we can’t quantify: map size

Map size is a genuine second axis — a larger world means more terrain and more entities held in memory, and mod-heavy servers add entity count on top of that.

We can’t give you numbers for it. The tiers we derived from don’t state a map size, so our 59MB-per-player figure silently assumes whatever map size the host assumed. A 4500-size map with heavy mods will exceed it; a small vanilla map will come in under.

The practical version: treat 12GB as the figure for a conventional 100-player server, and budget 16GB if you’re running a large map, heavy mods, or both. That’s not a hedge — it’s the honest shape of a number nobody publishes properly.

What to buy

Hetzner — the clear value answer at 16GB, which is the tier this article points to, and the only provider here that publishes a CPU-profile commitment: its dedicated CCX line is sold explicitly for “constantly high CPU usage” while the shared line is not. Given that CPU rather than RAM is the real constraint for Rust, that’s the most relevant thing any host in this comparison says. Note availability limits since June and backups that exclude attached Volumes.

Hostinger — $14.99 for 8GB, which by the table above covers a 40–50 player server comfortably. The right buy if you’re not actually running 100 players, which most people asking this question aren’t. Refund terms cover renewals, so sizing up later isn’t punished.

HostHavoc — $16.00 for managed Rust hosting with a one-click uMod/Oxide plugin manager. The option if you’d rather not size a server at all — though slot plans cap your player count, so check the tier covers your target.

UltaHost — 3 vCPU at $15.87 for 4GB, more cores per dollar than most. Useful if your bottleneck is CPU rather than memory, which for Rust it usually is — though verify single-core clock, not just core count.

How we checked this

The two data points this article is built on are Shockbyte’s published Rust tiers — 8GB for 40 players and 10GB for 75 players — read live from its Rust product page in August 2026 and published in our Rust hosting comparison.

Everything else in the sizing section is our arithmetic on those two points. The 59MB-per-player marginal rate, the 5.7GB baseline and every row of the extrapolation table are a straight line fitted through two vendor pricing tiers. They are not measurements.

Be appropriately sceptical of that. Two points define a line perfectly and tell you nothing about whether the relationship is actually linear — and vendor tiers are set for marketing legibility and margin, not as measurements. The 100, 150 and 200-player rows are extrapolated past the top tier we have data for, which is where fitted lines are least trustworthy. We’ve labelled them in the table rather than presenting all four rows as equally solid.

We have not run a Rust server, measured its memory, or observed one under load. No first-hand figure appears in this article.

The map-size axis the brief asked for is absent. It specified a two-axis table crossing map seed sizes of 3000, 4000 and 4500+ with 50, 100 and 200 players. We have no data on map-size memory impact at all, and the tiers we derived from don’t state the map size they assume — which is a real limitation on the per-player figure itself, not just on the missing axis. Publishing a nine-cell table where we can justify one column would be the most misleading thing we could do here.

The single-threaded premise is not something we verified. That Rust’s tick is bound largely by single-core performance is the widely-held community position and the basis of this article’s central argument. We did not confirm it against Facepunch documentation or measure it.

The failure signatures are grounded differently. The OOM signature — silent process death, truncated logs, exit code 137, and the dmesg confirmation — is behaviour we’ve documented first-hand in our OOM killer guide and it’s generic Linux behaviour, not Rust-specific. The CPU-saturation description is reasoning from the single-thread premise, not something we reproduced in Rust.

What we did not do: run a Rust server, generate player load, measure memory or server FPS, or test any provider’s hardware.

The host links above are affiliate links. The article’s most likely conclusion for most readers is that 8GB is enough, because most people asking about 100-player servers are not running one.

FAQ

How much RAM does a 100-player Rust server need?

About 12GB by our derivation from published host tiers — roughly 5.7GB baseline plus 59MB per player. Buy 16GB for headroom, especially with a large map or mods.

How much RAM for a 50-player Rust server?

Around 8.6GB by the same derivation, which is within the range the published tiers actually cover. An 8GB plan is a reasonable buy.

Why do people say Rust needs 32GB or more?

Usually because they were diagnosing the wrong problem. Rust’s tick is heavily single-threaded, so a struggling server is more often CPU-bound than memory-bound — and adding RAM doesn’t raise server FPS.

How do I know if my Rust server ran out of memory?

Run sudo dmesg -T | grep -i -E 'killed process|out of memory'. A match confirms the OOM killer. No match means it wasn’t memory, and memory fixes won’t help.

What does CPU saturation look like in Rust?

Falling server FPS in the console, rubber-banding and desynced combat — but the process stays alive and dmesg is clean. That’s a faster-core problem, not a bigger-RAM problem.

Does map size affect RAM usage?

Yes — bigger maps mean more terrain and entities in memory, and mods add more. We can’t quantify it, which is why the guidance is to add headroom rather than compute a figure.

Is 8GB enough for a Rust server?

For roughly 40–50 players on a conventional map, by published tiers, yes. It’s the right buy for most servers that aren’t actually hitting 100 concurrent players.