Rust Server Requirements: RAM, CPU and Player Slots Explained
Rust’s official requirements are only the starting point. This guide shows what actually uses RAM, CPU and disk on a Rust server, how to pick a realistic player limit, and how to tell which upgrade you need before paying for one.
Map size, seed, monuments, plugins and wipe age all change memory use. A smaller world usually saves more money than buying a larger plan too early.
Rust’s server loop leans on strong single-thread performance. More cores help the machine overall, but per-core speed is what usually decides smoothness under load.
As bases, deployables and abandoned structures pile up, CPU time and RAM use rise. A server that feels fine at first can slow down later without any setting changes.
A slot count only means something if the plan’s RAM and CPU really support it. Set server.maxplayers to the hardware, not the marketing label.
Start with Facepunch’s baseline, then adjust for how you host
Facepunch’s official Rust server requirements are broad by design: the server can run on Windows, Linux or macOS, it needs 12 GB free RAM, and a 6k map uses more. It also needs 15 GB free disk space, with SSD or NVMe strongly preferred. Facepunch also says these figures are not fixed and depend heavily on population and use case, which is why hosts publish RAM estimators instead of one universal chart.
The important word there is free. On a home PC, “12 GB free RAM” means the operating system, background tasks, voice chat, browser tabs and anything else you have open need their own share first. On a rented plan, the RAM figure you buy is the amount the server gets from the host’s allocation model; you are not also trying to keep a desktop operating system comfortable for your own daily use. If you want the broader logic behind that, this guide on how game server hardware requirements work is worth a read.
That difference is why people get caught out when they compare a host plan directly to a home machine. A self-hosted box can look big on paper and still fall short because the free headroom is smaller than expected. A rented plan can look modest and still be enough if the map is sensible and the plugin list is lean.
Hosts’ guidance usually puts the practical floor at 8 GB for Rust, with some going further and warning that less than 8 GB often leads to crashes and frequent lag. Another host guide says running Rust on less than 6 GB is almost impossible and treats 10 GB or more as a more comfortable starting point for many people. Treat those as host-side planning guidance, not as Facepunch’s official rule.
The takeaway from the baseline is simple: do not buy by fear. Start with a realistic floor, then size the map and player cap so the server stays inside that budget.
What actually consumes RAM, CPU and disk in Rust
If you want a realistic player limit, you need to know what the server is spending resources on. The biggest drivers are easier to see in this matrix.
| Driver | RAM | CPU (server loop) | Disk |
|---|---|---|---|
| Map size (server.worldsize) | Named | – | Named |
| Seed and monuments | Named | – | – |
| Player count | Named | Named | – |
| Plugins | Named | Named | – |
| Entities building up over a wipe | Named | Named | Likely |
Map size, seed and monuments
server.worldsize has a direct cost. Facepunch allows values from 1000 to 6000, and the larger the world, the more disk space and memory you need. That is not just empty terrain: a larger world means more map data, more structures to track and more saved state when the world writes to disk.
The seed matters too. server.seed can be any value from 0 to 2147483647, and two seeds at the same world size can still behave differently because monument and structure layout changes what the server has to keep track of. Host RAM calculators explicitly treat seed as a reason their result is only an estimate.
Why shrinking the map works: the server is managing less world data in memory and writing less world state to disk. Trade-off: players get a tighter map, less travel and a busier feel. For a private group, that is often a good trade. For a community that wants space and long travel routes, it may not be.
Players
Facepunch’s own guidance is clear here: the more players you allow, the faster your CPU needs to be. Players add movement, building, combat, inventory actions, network updates and interactions with existing entities. Some of that touches RAM and bandwidth, but the main pressure point is CPU time in the server loop.
Why lowering max players works: it reduces the amount of simulation and network work that has to be finished each server frame. Trade-off: shorter queue-free sessions for your regulars, but fewer people can join at once.
Plugins
Plugins cost resources in two ways. First, they live in memory, so they add to RAM use. Second, they run logic on hooks and events, so they can add tick time and hurt server.fps if the code is heavy or badly chosen for your server.
Automation and convenience plugins are often the ones to watch. A plugin that tracks lots of objects or reacts to many events can consume more than its feature list suggests. Why removing or replacing a heavy plugin works: you are directly cutting code from the main loop and reducing memory overhead. Trade-off: you lose that feature, so only strip the plugins players actually notice.
Entity growth across a wipe
This is the part many new renters miss. The same server usually needs more from the hardware late in a wipe than it does on wipe day. As players build bases, place deployables and leave structures behind, entity count rises. Host performance guides consistently point to entity count as the main cause of gradual lag as a wipe ages.
Why decay and wipes help: they remove abandoned structures and reset the amount of world state the server must track. Trade-off: a stricter world and more cleanup, which not every community likes. Entity-control plugins can also help, but remember that the plugin itself has an overhead, so use the simplest tool that actually removes clutter.
CPU: prioritise single-thread speed over chasing core count
Rust server performance leans heavily on single-thread CPU speed. In practice, that means strong per-core performance matters more than a high core count on its own. Extra cores still have value for the operating system, networking, save tasks and anything else running on the machine, but the part players feel most is whether the main server loop gets enough fast CPU time.
This is why a plan with a decent published processor and strong per-core behaviour can outperform a vague “many cores” offer that tells you nothing useful. It is also why low-population lag on a fresh wipe often points to hardware quality or plugin load, not just “needing more RAM”.
What CPU priority add-ons actually buy you
Some hosts sell CPU priority as an add-on. That usually means the operating system scheduler gives your Rust process a larger share of processor time when there is contention on the node. It can help when the plan is otherwise suitable but the process is fighting for time slices under shared load.
Why it works: the server loop gets scheduled more favourably, which can steady frame time when the hardware is shared. Trade-off: it costs more each month and it does not solve bad plugins, too many entities or a map that is oversized for the rest of the plan.
Noisy neighbours and oversold hardware
Random hitches on a lightly loaded server are often blamed on Rust itself, but shared hardware quality matters. On an oversold node, another customer’s busy server can take CPU time your server needed and cause the kind of inconsistent hitching that makes your own settings look guilty when they are not.
How to tell: if your plugin list is lean, your population is low, RAM headroom is fine, and server.fps still dips unpredictably, especially at certain times, the issue may be the host node rather than your own config. In that case, a move to a better plan or different host usually does more than endless in-game tuning.
Player slots vs RAM plans: set max players to the hardware, not the label
Rust hosting is sold in two common ways: by player slots, or by RAM with “unlimited” slots in the panel. Neither model is wrong, but both can mislead if you forget what is underneath. A slot count only means something if the plan’s actual CPU and RAM are strong enough for the population, map size and plugins you intend to run.
That is why server.maxplayers matters more than the plan name. Facepunch’s rule is that more players need a faster CPU, so set the cap to what the hardware can serve cleanly rather than what the control panel allows you to type. If the plan comes with a generous slot number but a modest CPU share, leave server.maxplayers lower until the server proves it can hold more.
Why this saves money: you avoid paying for a higher tier purely to match a slot figure you may never use. A smaller map and a realistic player cap often give a better experience than a bigger plan with headroom you cannot convert into smooth performance anyway. When you compare offers, our Rust server hosting comparison lists the RAM, slots and locations each host actually gives you, so you can see the hardware behind slot-based and RAM-based plans.
Hosts’ RAM calculators usually estimate from three things together: map size, plugin count and player count. That is the right way to think about slots. A player cap is not a resource by itself; it is a demand multiplier applied to your map and plugin choices.
Configuration basics that affect requirements and stability
Rust dedicated servers are installed with SteamCMD using anonymous login, under app ID 258550. You do not need a Steam account to run the server, though players still need Rust to join it. After launch, allow several minutes for startup and wait for the message Server startup complete before judging whether the process is healthy.
Your main config file is server/<identity>/cfg/server.cfg. Rust reads that file at startup, and it takes priority over the command line. That matters when you are troubleshooting, because a value in the panel’s launch options may not win if the same setting is also in server.cfg.
Here is a simple launch line using Facepunch’s example values for world size, player cap and ports.
RustDedicated.exe -batchmode +server.worldsize 4000 +server.maxplayers 10 +server.port 28015 +rcon.port 28016
Map and port choices also affect how the server behaves operationally:
server.worldsize: use 1000 to 6000. Larger sizes consume more RAM and disk.server.maxplayers: this is your real population cap, regardless of what the plan advertises.server.seed: any value from 0 to 2147483647. Different seeds can change monument density and memory use at the same size.
Ports and why each one exists
Rust uses four ports in total. The one players actually need to connect and play is server.port, which defaults to 28015 and uses UDP. server.queryport also uses UDP; by default it is 1 + server.port or rcon.port, whichever is greater, it must be open for the server to appear in the server browser, and it cannot be the same as server.port. RCON uses TCP, with 28016 as a common example, and the Rust+ companion app uses TCP as well.
Plugin framework maintenance matters too. Oxide/uMod has to be re-installed after every server update, and if your startup script runs SteamCMD each boot it will revert modified files to vanilla first. So if your plugins vanish after an update or restart, the framework was overwritten: re-install it before you start blaming performance.
Measure before you upgrade: read the pattern, not just the complaint
The best Rust sizing method is evidence-based. Check server.fps when the server is empty, again near peak activity, and again later in the wipe when the map is full of structures. Then compare that with RAM use against the plan limit. Those two readings tell you far more than a sales page.
This flow is the fastest way to separate RAM pressure from CPU load, plugin overhead and network trouble.
Use these console or RCON commands as your basic checks.
server.fps oxide.plugins oxide.unload PluginName
Why this works: server.fps shows how well the server loop is keeping up. If it drops when players, entities or plugin events rise, the server is short on CPU time somewhere in the loop. If RAM climbs towards the plan limit and the machine starts swapping to disk, you get stutter because storage is vastly slower than RAM. If server.fps stays healthy while players complain about rubber-banding or high latency, the bottleneck is likely network distance, routing or uplink quality rather than the game process itself.
A daily scheduled restart is common for Rust because memory use tends to creep up the longer the process runs. Done gracefully, it lets the world save cleanly and can clear the slow build-up that appears even when the underlying plan is still appropriate. The trade-off is a short interruption, so schedule it away from your busiest period.
| Symptom | Likely cause | First fix |
|---|---|---|
| Lag starts on a fresh wipe with few players | Weak single-thread CPU, bad plugin, or noisy neighbour on shared hardware | Check server.fps, unload recent or heavy plugins one at a time, then consider a higher-CPU plan or CPU priority |
| Server is smooth after wipe, then degrades over days | Entity growth and memory creep | Leave decay on, reduce entity-heavy extras, schedule graceful restarts, and plan wipes sensibly |
| Stutter or crashes as RAM use approaches the plan limit | RAM exhaustion or swapping | Shrink the map, remove memory-heavy plugins, then upgrade RAM if the pattern remains |
Healthy server.fps, but players report ping spikes or rubber-banding | Network distance, routing, or uplink issues | Choose a nearer location and check that required ports are open correctly |
| Short hitches during world saves | Storage latency | Use SSD or preferably NVMe storage so save writes complete more smoothly |
| Server does not appear in the browser | Query port closed or conflicting | Open server.queryport on UDP and make sure it is not the same as server.port |
Tune it or upgrade: a sensible way to avoid overpaying
For a small group or a new community, the cheapest accurate plan is usually found by starting near the hosts’ practical floor, not by buying the biggest thing you might someday grow into. Rust is unusually sensitive to map size, entity count and plugin choices, so configuration often changes the requirement more than an early hardware upgrade does.
- Start near the practical floor. Hosts commonly treat 8 GB as the workable entry point for Rust. That is a starting point, not a promise.
- Match the map to the group. Smaller world size reduces RAM and disk use straight away.
- Set a realistic
server.maxplayers. Use the population your CPU can sustain, not the panel’s highest number. - Measure at three moments. Empty, peak activity, and late in the wipe.
- Upgrade the resource that is actually short. More RAM solves RAM pressure; it does not fix a weak main thread. A better CPU does not fix a bloated map or storage stutter.
| What you observe | Tune first | Upgrade if needed | Why that upgrade fits |
|---|---|---|---|
| RAM use keeps climbing towards the plan limit, especially later in the wipe | Smaller map next wipe, trim memory-heavy plugins, use entity cleanup, restart daily | More RAM | The server has run out of working memory headroom, so more memory prevents swapping and crashes |
server.fps drops under player load while RAM still has headroom | Lower server.maxplayers, remove heavy plugins, reduce entity growth | Faster CPU or CPU priority | The main server loop is short on processor time, not memory |
| Hitches happen mainly during saves | Keep the world and plugin load lean | NVMe storage | Save writes hit storage directly, and faster disk reduces the pause |
Players complain about lag but server.fps stays healthy | Check routing, port setup and your chosen region | Move to a better location | The bottleneck is between players and the server, not inside the Rust process |
| Random hitches with low population and simple config | Restart, verify plugin load, watch for time-of-day pattern | Move to better quality hardware | Shared-node contention and noisy neighbours are outside your config |
Look past the headline slot count. The best offers for Rust are the ones that publish useful CPU details, use NVMe, allow in-place RAM upgrades and make restarts and plugin installs straightforward.
Compare the best Rust server hostsDisk and network still matter, even when CPU and RAM are right
Facepunch lists 15 GB free disk space, and that is the minimum planning point rather than the whole story. Larger maps need more disk, save files grow with world state, and storage speed affects how smooth save writes feel when the server is busy. SSD is strongly preferred and NVMe is better again because it reduces the wait on storage operations.
Why faster storage helps: when the server saves, it has to write world state to disk. Slow storage stretches that work and turns it into visible hitches. Trade-off: there is usually a cost difference, but this is one of the cleaner upgrades because it improves a very specific pain point without changing how the server plays.
Network quality is just as practical. The only port needed for players to connect and play is the game port on UDP, but the query port must also be open for the server browser, and RCON and Rust+ each need their own ports as well. A perfect CPU does not fix a blocked query port, and a healthy server.fps does not fix a poor region choice.
Why location matters: distance and routing raise latency before the server even processes a packet. Trade-off: choosing a central location for a mixed player base may lift average ping for some regulars, while choosing a very local location may exclude friends farther away. For a small group, pick the region that keeps the core players closest.
Pre-purchase checklist for a Rust server
The best time to avoid overpaying is before you order. These are the questions that actually affect a Rust server’s long-term cost and stability.
| Check before buying | Why it matters for Rust | What to look for |
|---|---|---|
| Can I upgrade RAM without migrating? | Rust often needs a small step up later in the wipe cycle or after adding plugins | An in-place plan upgrade path, not a forced rebuild |
| Is storage NVMe? | World saves feel smoother and startup is generally cleaner on fast storage | NVMe stated clearly, not vague “fast SSD” wording |
| Is the CPU model or clock published? | Single-thread performance matters more than marketing around core count | Useful CPU detail you can compare, not a generic “high performance” claim |
| Is there a location close to the players? | Healthy server performance does not help if latency is poor | A region that suits your actual group, not just the cheapest node |
| Are scheduled restarts easy to set? | Rust commonly benefits from graceful daily restarts as memory use creeps | A panel with simple scheduling and clean shutdown behaviour |
| Can I install and maintain the plugin framework cleanly? | Oxide/uMod needs re-installing after updates, so awkward workflows become a chore fast | Clear file access, sensible startup control and room for post-update steps |
| Are the required ports manageable? | Game, query, RCON and Rust+ all need the right access | Clear port controls and no confusion around UDP vs TCP |
| Does the host mention shared hardware quality? | Noisy neighbours can ruin a good config | Signs of sensible node management and optional CPU priority if offered |
Rust server FAQ
How much RAM does a Rust server need?
Facepunch lists 12 GB free RAM, and says a 6k map uses more. That is not a flat requirement for every setup, because map size, seed, monuments, plugins and wipe age all change memory use. On a rented plan, think in terms of the plan’s RAM allocation; on a home PC, think in terms of how much RAM is still free after the operating system and other programs take their share.
Is 8 GB enough for a Rust server?
It can be enough as a practical starting point for a small, lean setup, which is why hosts often treat 8 GB as the floor. It is not enough for every map or plugin mix, and it becomes much less comfortable if you let entities and automation-heavy plugins grow unchecked. If RAM use keeps pressing against the plan limit, shrink the map or upgrade rather than hoping the server will settle down by itself.
How many players can my Rust server handle?
There is no honest fixed player table without also specifying the map, plugins, wipe age and CPU. Facepunch’s own rule is that more players need a faster CPU, so the real answer is whatever population your hardware can sustain while server.fps stays healthy at peak times and later in the wipe. Set server.maxplayers to that proven number, not to the slot count printed on the plan.
Does a Rust server need a fast CPU or more cores?
A fast CPU with strong single-thread performance matters more than a high core count on its own. Rust’s main server loop leans heavily on per-core speed, so that is the part players usually feel first when the server is busy. Extra cores are still useful for the rest of the system, but they do not replace a weak main thread.
Do plugins need more RAM?
Yes, plugins add both memory use and CPU work. Some are light, while others hold more data in memory or run a lot of logic on frequent hooks, which can hurt tick time as well as RAM usage. If a server struggles on a fresh wipe, unload heavy plugins one at a time and re-check server.fps before paying for more hardware.
More Rust server help
The Rust host comparison, plus our general guide to game server hardware.
Game updates and host panels change. If your host’s current panel, startup layout or plugin workflow differs slightly from this guide, follow the host’s live instructions for that part.
