For a Rust dedicated server, start with Facepunch’s baseline of 12 GB of free RAM and 15 GB of free disk space, using an SSD or NVMe drive. Those are free-resource starting points, not a guaranteed specification for every server. A 6k map, a larger player population, dense player-built entities, plugins, logs, backups and other services all increase demand. CPU requirements rise with concurrent players; per-core performance matters particularly because the game’s main work is concentrated on a primary thread. Install more memory than the free-RAM figure, leave storage headroom, and measure the live server before committing to a larger population or heavier plugin set.
What are the official Rust dedicated-server requirements?
The Facepunch Rust Wiki lists 12 GB of free RAM and 15 GB of free disk space for a dedicated server, with SSD or NVMe storage highly preferred. Facepunch also says that these values are not fixed: requirements depend on the server’s use case and population. The figures therefore describe a starting point for the server process, not the total hardware specification of a host machine.
| Resource | Official starting point | What the figure means |
|---|---|---|
| Memory | 12 GB free RAM | Available memory after the operating system and other running services have taken their share. |
| Storage | 15 GB free disk space | Free capacity for the server installation at a minimum; worlds, logs, updates and backups require additional space. |
| CPU | No universal model, clock speed or core count published | Facepunch states that more players require a faster CPU. Provider guidance places particular importance on per-core speed. |
| Drive type | SSD/NVMe highly preferred | Solid-state storage reduces wait times for world files, saves, updates and other disk activity compared with a hard drive. |
Facepunch’s wording is deliberately conditional. A machine that satisfies the baseline can still struggle when the map, population or plugin workload grows, and no single component guarantees a particular player count.
How much RAM does a Rust server need?
Use the official free-memory baseline as the minimum for a small or moderate deployment, then add capacity for everything else on the machine. “Free RAM” is not the same as installed RAM: the operating system, monitoring tools, databases, control panels, backup jobs and other game servers consume memory before Rust receives any.
What increases memory use?
- Map size: Facepunch specifically warns that a 6k map uses more memory. Larger worlds generally carry more terrain and world data in memory.
- Concurrent players: More connected users create more active entities and simulation work.
- Built entities: Bases, deployables, vehicles and other persistent objects increase the amount of state the server tracks. PineRiver’s provider guidance identifies world entities as a major driver.
- Plugins: Extensions can retain data, add event processing or create additional scheduled jobs. Their impact varies by plugin and configuration.
- Co-hosted services: Web panels, voice services, databases, monitoring and backup software reduce the memory available to Rust.
How should I plan installed memory?
Buy enough installed RAM that the server can keep the required free memory while the operating system and your supporting services are active. For a private server with few extras, that means treating the official baseline as the floor and reserving additional headroom rather than filling the machine to its limit. A public server, 6k map, extensive plugin collection or several co-hosted applications warrants substantially more than the baseline; the exact amount should come from measurements under representative load.
Watch memory over several days, not only immediately after startup. A server may appear comfortable while empty and grow as players build, entities accumulate, logs expand or plugins cache data. Record the lowest available memory during busy periods and during scheduled backups, then increase the allocation if the host approaches exhaustion or begins swapping.
What CPU does a Rust dedicated server require?
There is no official minimum CPU model, benchmark score, clock speed or core count that applies to every Rust server. Facepunch’s direct guidance is that “the more players, the faster your computer CPU needs to be.” In practice, choose a modern processor with strong per-core performance and enough additional cores for plugins and host services.
Why does per-core speed matter?
PineRiver’s provider guidance says Rust performs most game work on a single main thread. That makes sustained performance on one fast core more important than simply buying a processor with many slower cores. Extra cores still have value: they can run plugin tasks, monitoring, web panels, backup compression and other workloads without competing as aggressively with the game thread.
How does player count affect CPU load?
Every additional player adds movement, networking, inventory activity, combat events and interactions with the world. The relationship is not a simple capacity formula because map activity, entity density and plugins change the amount of work per player. Test with the population and play style you expect, paying attention to peak rather than average CPU utilization.
What should I measure?
- Single-core or main-thread utilization during peak activity.
- Frame or tick-time symptoms reported by the server when players experience lag.
- CPU contention from backups, updates, map generation and other scheduled jobs.
- Whether plugin tasks create spikes even when the player count is unchanged.
If the main thread is saturated while other cores are idle, adding cores alone is unlikely to solve the problem; a faster per-core processor or a lighter workload is the more relevant remedy. If all cores are busy because of co-hosted services, moving those services or adding cores can help.
How much storage does a Rust server need?
The official free-space starting point is 15 GB, and Facepunch highly prefers SSD or NVMe storage. Treat that capacity as room for the initial server files, not as the size of a complete long-term installation. World maps, save files, update downloads, logs, plugins and retained backups all need space.
What consumes disk space?
- Installation and updates: The server files and temporary update data must fit while updates are applied.
- World files: PineRiver documents
.mapand.savfiles for the world and its saves. - Backups: Rolling copies of saves multiply storage use according to retention.
- Logs and diagnostics: Busy or heavily moderated servers can create substantial logs over time.
- Plugins and configuration: Extensions may add files and databases of their own.
Why is SSD or NVMe preferred?
Rust repeatedly reads and writes world and save data, especially during saves, restarts, updates and backup operations. Solid-state storage offers much lower latency than a mechanical hard drive, so it is the safer choice for startup time and storage responsiveness. NVMe can provide higher throughput, but the essential decision is to use reliable solid-state storage with enough capacity and free space.
How should I size the drive?
Add the operating system, server installation, current world, the number of save copies you intend to retain, expected log growth and a reserve for updates. Keep enough free capacity that an update or backup does not fail because the volume is full. For a public server with world history and frequent backups, capacity and backup strategy matter more than chasing a particular drive interface.
How do map size, players and plugins change the requirement?
Resource demand is workload-dependent, so a server’s nameplate specification cannot be separated from how it will be operated.
Map size
Facepunch calls out a 6k map as using more memory. Select the map size you actually intend to run, then test it before opening the server to a larger audience. Do not infer that a machine tested on a small map will behave identically on a 6k world.
Player population
Population affects both CPU and memory. A lightly populated public server can have lower average demand than a full one, while peak events may create short periods of much higher load. Plan for the busiest period you expect, not the median number of connected players.
Entities and building activity
As players build and deploy objects, the world contains more state for the server to track. A mature wipe with dense bases can therefore require more resources than a fresh wipe with the same nominal population.
Plugins
Plugins vary widely. Some add only small event hooks; others maintain databases, run frequent scans or change gameplay systems. Add plugins incrementally, measure after each major change and remove or reconfigure extensions that create persistent CPU or memory pressure.
What hardware plan fits a private, public or heavily modified server?
The following bands translate the official baseline and provider workload guidance into purchasing decisions. They are planning categories, not guaranteed player-count tiers.
| Deployment | RAM plan | CPU plan | Storage plan |
|---|---|---|---|
| Small private server | At least the official free-memory baseline, with room for the operating system and utilities. | Modern processor with strong per-core performance. | SSD/NVMe; free space for the baseline installation plus saves and backups. |
| Larger map or active public server | More than the baseline, validated after several days of real activity. | Faster per-core performance; additional cores for plugins and services. | Higher-capacity solid-state drive for world history, logs and backup retention. |
| Heavy plugins or co-hosted services | Substantial headroom beyond server-only use. | High-performance CPU sized for peak player load and competing workloads. | Reliable, high-capacity SSD/NVMe with a separate backup plan. |
Do not convert these categories into promises such as “this hardware supports 100 players.” The available data provides no universal benchmark, and actual capacity depends on map, entities, plugins, operating system overhead and what else runs on the host.
Are Rust client requirements the same as dedicated-server requirements?
No. Steam’s current Rust client listing gives the player game’s minimum of 12 GB RAM and 45 GB storage, with 16 GB RAM recommended and named desktop CPU models. Those values describe the graphical client installed on a player’s computer, not the dedicated server process.
The client also needs space for game assets and a graphics-capable desktop environment, while a headless server has different storage and CPU behavior. Use the Facepunch server guidance for hosting decisions and the Steam listing only when checking a player’s workstation.
How do I validate a server before expanding it?
Measure the intended workload in stages so that a resource problem is visible before it affects a full community.
- Install on SSD or NVMe and leave free capacity beyond the initial files.
- Run the exact map size and plugin set you plan to use; testing a smaller world produces misleading results.
- Load representative activity by inviting the expected number of players or using a controlled test period.
- Record peak CPU, available memory and disk usage during building, combat, saves, restarts and backups.
- Check growth over multiple days for save files, logs, plugin data and backup retention.
- Increase resources or reduce workload when the main thread saturates, available memory falls sharply, or storage approaches capacity.
Repeat the check after a major map change, wipe, plugin addition or population increase. A one-time idle reading cannot establish a safe capacity.
What are the common sizing mistakes?
- Confusing free RAM with installed RAM: the operating system and services must fit outside the server’s requirement.
- Buying to a player-count promise: no official CPU model or benchmark guarantees a population tier.
- Ignoring the 6k-map warning: a larger map can invalidate a configuration that worked on a smaller world.
- Using a nearly full drive: updates, saves and backups can fail when there is no working space.
- Choosing core count over per-core speed: a many-core processor is not automatically faster for the main game thread.
- Testing only at launch: entities, logs, save history and plugin data accumulate as a wipe continues.
- Co-hosting without accounting for contention: backup jobs and other applications can steal CPU, memory or disk time during peak play.
Should I self-host or rent a managed Rust server?
Self-hosting gives you control over CPU choice, memory allocation, storage layout, backups and plugin maintenance, but you are responsible for operating-system updates, security, monitoring, failures and recovery. Renting managed Rust hosting shifts much of that maintenance to a provider and makes capacity changes simpler, while recurring cost and provider-specific limits become the trade-offs.
Whichever route you choose, compare the same factors: available free memory, per-core CPU performance, SSD/NVMe capacity, backup retention, plugin support, co-hosted services, maintenance responsibility and the provider’s process for scaling. No universal monthly price is established here; it varies by region, hardware allocation and service level.
What should I upgrade first when the server lags?
Identify the constrained resource before buying hardware. Main-thread CPU saturation points to faster per-core performance or a lighter plugin and entity workload; memory pressure points to more installed RAM or fewer co-hosted services; slow saves, failed updates or a full volume point to faster or larger storage.
Use monitoring from a busy period rather than guessing from the server’s empty-state behavior. Upgrading the wrong component can leave the actual bottleneck unchanged.
Frequently Asked Questions
Can a Rust server run on a home PC while I play the game on it?
It can, but the game client and server then compete for CPU, memory and storage bandwidth. Test both workloads together, and avoid running backups or updates during busy play if they cause contention.
Does a larger SSD make the server run faster?
Capacity and latency are separate properties. More capacity prevents save and backup failures, while SSD or NVMe latency improves storage responsiveness; capacity alone does not compensate for a slow processor or insufficient memory.
How often should I review resource usage?
Review after every wipe, map-size change, major plugin addition or sustained population increase, then periodically as the world accumulates entities and logs. Trend data is more useful than a single reading after startup.
What happens if the host runs out of memory or disk space?
Memory exhaustion can trigger swapping or process termination, while a full disk can prevent saves, updates and backups. Leave headroom and configure monitoring so you can act before either limit is reached.