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

By Niko Catarino

Updated 15 September 2026

Size a Rust server around what your players will do in the world. The slot limit controls how many can join, while their activity, your map and your plugins determine the work the server has to handle.

Facepunch’s starting requirements for a Rust PC dedicated server are 12 GB of free RAM and 15 GB of free disk space, with SSD or NVMe preferred. A 6k map needs more memory. Population and use also change the requirement, so test the workload before treating that baseline as enough for 100 players. Facepunch server requirements

Describe the world and its software before choosing an allocation. Include the activity you expect near the end of a wipe, when players have built up the map, as well as startup on a fresh save.

Check the requirements before choosing a plan

Resource	What to check
Memory	Find the allocation available to Rust. On your own machine, allow for the OS and other processes too.
CPU	Ask for the model, allocation and sharing policy, then test your workload against that specification.
Storage	Leave space for installation, the world, plugin data, logs, update files and backups you retain.
Operating system	Confirm Rust and framework support for the OS, and agree who installs OS updates.
Network	Choose a location and connection your group can test; port speed alone does not tell you their latency.

Scroll to see all columns →

Before installing an OS image, check its supported version. Facepunch’s May 2026 Windows notice sets a minimum of Windows Server 2019 or Windows 10 version 21H1, build 19043. Its Linux notice raises the floor for older releases to Debian 11 and Ubuntu 20. Read subsequent release notes before installing or upgrading. Windows notice, Linux notice

Record the workload you intend to host

Give the provider these details so you can test its recommendation:

• World: record the map name or seed, size, custom-map version and save age.
• Population: estimate simultaneous players and arrange the busiest session you can test. Keep that separate from community membership or the slot limit.
• Software: list the Rust build, vanilla or framework version, and versions of plugins and extensions.
• Activity: choose the raids, monuments, built-up areas or plugin events you will reproduce.
• Operations: include saves, backups and restarts, and record how long the test instance has run.

If your panel shows entity count, keep that reading using the same metric on each run. Note the activity alongside it; equal entity counts can still produce different workloads.

Measure memory and CPU on the running server

Open the panel’s process graphs or your OS monitor. Record their labels and units so you can tell the Rust process reading apart from whole-machine use and the allocation limit.

Watch startup, ordinary play and the busiest activity you can arrange. Note peak process memory and how much allocation remains. For a stall, ask about paging or memory-limit terminations at that time. Leave room for growth and other processes. If the limit is absent from the graph, ask the provider how it is enforced.

Capture per-core CPU with the Rust process readings where available. A machine’s low average can conceal one busy core. The controls available on a managed allocation, VPS and physical server differ too. Compare the hosting models before using a higher core count as a reason to expect more capacity from one Rust instance.

At the same time, run this in the server console or authenticated RCON console:

fps

The client’s F1 console reports client FPS for the same command. Record the server’s configured FPS limit alongside its result. If the reading reaches the cap, it does not show how much capacity remains beyond it. Facepunch console command reference

If players report a stall, use the Rust lag diagnosis to check its cause before choosing a hardware change.

Test the map and plugin set before increasing the player limit

Run a workload test on the proposed allocation before admitting more players:

1. Make a restorable copy. Back up the world, configuration and plugin data away from the live service and try recovery. Protect the test instance with separate credentials and access controls. Before starting it, replace or disable copied live database, webhook and other integration connections.
2. Set a repeatable starting point. Record the build, map or save, software versions, allocation and FPS cap. Where you can, restore the same saved state before each run.
3. Measure a reference session. Wait for startup to finish, then play with the intended plugins. Include a save cycle and an activity you expect during a busy session.
4. Run the planned event. Invite your group and repeat the route or activity. Note how many players took part and what they did. Idle connections put different demands on the server from an active raid.
5. Change one suspected limit. On the copy, try a plugin setting or another allocation if the readings show a resource constraint. Repeat the test to confirm the result.

Keep a separate record for each run:

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 the quiet session with the busy one. Test again after a major Rust update, a plugin or map change, and as the save grows through the wipe. If fewer players attend than you planned for, record that population and arrange the larger test later.

Rust server requirements for 100 players

Use 100 simultaneous players as your test target. Ask which map, software and activity informed the provider’s recommendation. Agree on the next step if the planned event reaches the memory limit or produces low server FPS.

If you need to order before assembling that group, share the workload record and agree on a smaller initial test. Check cancellation and upgrade terms, and keep the untested population target in your notes. A RAM-per-player formula will not account for the map and plugin activity you still need to measure.

Choose the hosting around the measurements

With VYKIX managed Rust hosting, we maintain the host OS and provide game-file access plus Oxide/uMod and Carbon workflows. Fair-use limits apply to listed slots and resources, and the playable capacity depends on your workload. If you need root access, consider Game VPS; a complete physical server gives you control of the whole machine.

You can use the 48-hour Rust trial for a defined workload test. A valid card is required, with no trial charge or automatic paid subscription. Keep the hardware specification with your results, since it can differ from paid hardware. Export needed files before expiry. Service is suspended at 48 hours, and active trial data is deleted seven calendar days after suspension. To continue, place a separate paid order.

Bring your map, plugin list and test notes when you review Rust hosting and the trial terms. Compare quoted billing periods, setup fees and extras with the Rust cost calculator.