RAM & CPU considerations

What actually burns resources

Player count, entity count (bases, deployables, dropped items), map size, plugin complexity and wipe-day join spikes drive CPU and RAM. A quiet 20-player monthly wipe is not the same as a 100+ pop with heavy plugins and a sprawling map late into the wipe cycle.

CPU notes (no fake benches)

Rust dedicated servers care a lot about strong cores and consistent clocks under load. We will not invent “X% faster than Host Y” charts here. If you compare hosts, compare named CPUs, region, and a trial on your plugin set. Monolith’s current production game node is a verified AMD Ryzen 9 9950X in Germany—use a trial to see how your wipe feels, not a marketing percentile.

RAM starting ranges (rules of thumb)

These are starting points, not guarantees:

• Small friends / low pop: often begins in the mid-single-digit GB range if plugins are light.
• Public community with Oxide/Carbon: plan more headroom as entities grow through the wipe.
• High pop / heavy plugins: size up early; running out of RAM causes hitching and crashes that look like “bad CPU”.

Always leave spare RAM for the OS, framework and spike joins. Prefer watching real usage after day 1–3 of a wipe over guessing from slot count alone.

How to validate

1) Start from a conservative plan.
2) Load your actual plugins.
3) Watch RAM and CPU during peak hours.
4) Raise resources before you are swapping or hitching.
5) Re-check after mid-wipe when entities pile up.

What we will not invent

No fabricated TPS tables, no unnamed “premium Ryzen” claims, no DDR5/NVMe marketing lines that are not part of Monolith’s published hardware story. Measure your server; treat vendor charts as marketing unless you can reproduce them.