Rust server requirements: size your map, plugins and player load

A player-slot number tells you who the server will admit. It does not tell you how much work those players create.

For a Rust PC dedicated server, Facepunch lists 12 GB of free RAM and 15 GB of free disk space, preferring SSD or NVMe storage. A 6k map needs more memory, and use and population affect requirements. Treat those figures as a starting point, not a tested specification for 100 players. Facepunch server requirements

Write down your world, population, software, activity and operations before choosing an allocation. A fresh map with nobody building on it cannot represent the last busy evening of a wipe.

Check the requirements before choosing a plan

Check OS support before installing an old image. Facepunch’s May 2026 Windows notice names Windows Server 2019 or Windows 10 version 21H1, build 19043, as the minimum. Its Linux notice names Debian 11 and Ubuntu 20 as the replacement floor for older releases. Read later release notes before an install or upgrade. Windows notice, Linux notice

Record the workload you intend to host

Send a provider enough detail to make its recommendation testable:

• World: map name or seed, size, custom-map version and save age.
• Population: simultaneous players you expect, and the busiest period you can test. Member counts and slot limits measure something else.
• Software: Rust build, vanilla or framework version, plugins and extensions with their versions.
• Activity: raids, busy monuments, built-up areas or plugin events you need to reproduce.
• Operations: saves, backups, restarts and the test instance’s running time.

Include entity count if your panel exposes it, using the same metric on each run. Keep the activity notes too: two worlds with equal counts can place different demands on the server.

Measure memory and CPU on the running server

Use process graphs in the panel or your OS monitor. Keep the metric labels and units. Rust process memory, whole-machine memory and an allocation limit answer different questions.

Watch startup, normal play and the busiest activity you can reproduce. Record the largest process-memory reading and remaining allocation. Look for host-reported paging or memory-limit terminations around a stall. Allow for growth and other processes, and ask the provider how it enforces a limit that the graph does not show.

Capture per-core CPU readings alongside the Rust process where available. A low average across a whole machine can hide a busy core. A managed allocation, VPS and physical server also give you different controls; compare the hosting models before equating extra listed cores with usable capacity for one Rust instance.

At the same time, read FPS in the server console or authenticated RCON console:

fps

The same command in the client’s F1 console reports client FPS. Record the server’s existing limit as well. Holding a cap does not measure how much capacity remains above it. Facepunch console command reference

For a reported stall, use the Rust lag diagnosis before attributing it to hardware.

Test the map and plugin set before increasing the player limit

Test the proposed allocation before raising the player limit:

1. Prepare a recoverable copy. Save the world, configuration and plugin data outside the live service, then check recovery. Give the isolated test instance its own credentials and access controls. Before starting it, replace or disable copied database, webhook and other live integrations so test activity cannot change production data.
2. Keep the comparison consistent. Record the build, map or save, software versions, allocation and FPS cap. Start each run from the same saved state where practical.
3. Take a reference run. Let startup finish. Record normal play with the intended plugins, including a save cycle and a likely busy activity.
4. Add the activity you need to test. Invite the group and repeat the route or event. Record the population and what players did; idle connections do not reproduce an active raid.
5. Test one constraint. Change a suspected plugin setting on the copy, or try a different allocation if the measurements point to a resource limit. Repeat before accepting the result.

Keep a separate sheet for each run. The blank fields leave room for your measurements rather than supplying invented results.

Run / date / time zone:
Rust build / framework / plugin versions:
Map or save / size / age:
CPU / allocation / memory limit / FPS cap:
Players observed / activity / test duration:
Server FPS before, during and after the busy activity:
Rust process memory peak / metric / remaining allocation:
CPU observations / entity count if available:
Save or backup timestamps / stalls / errors:
One change tested / result / rollback used:

Compare quiet and busy runs. Repeat after a major Rust update, a plugin or map change, and later in the wipe. If you cannot gather the intended population, leave that test open; do not extrapolate a guarantee from a smaller group.

Rust server requirements for 100 players

Treat 100 simultaneous players as a test target. Ask the provider to name the map, software and activity behind its recommendation. Agree on what happens if memory reaches the limit or server FPS drops during your planned event.

You can make a purchase before assembling a full server. Share the workload record, agree on a smaller test and check upgrade or cancellation terms. Keep the untested population visible in the decision. A RAM-per-player calculation cannot settle it.

Choose the hosting around the measurements

On VYKIX managed Rust hosting, we maintain the host OS and provide game-file access with Oxide/uMod and Carbon workflows. Listed slots and resources are subject to fair use; your workload sets the playable capacity. Choose Game VPS for root access or a complete physical server for full-machine control.

Our Rust trial gives you 48 hours to run a defined test. It requires a valid card, with no trial charge or automatic paid subscription. Trial hardware can differ from paid hardware, so keep the tested configuration beside your measurements. Export needed files before expiry: the service is suspended at 48 hours, and active trial data is deleted seven calendar days after suspension. Continuing requires a separate paid order.

Review Rust hosting and the trial terms with the map, plugin list and test notes ready. Use the Rust cost calculator to compare quoted billing periods, setup fees and extras.