Rust server: requirements and sizingAssess map size, plugins and player count correctly

Published on August 9, 2026 · last updated on November 8, 2026

Map size is the main driver

The value server.worldsize determines how large the procedural map becomes - and the computing effort does not grow linearly, but with the area. Doubling the edge length roughly quadruples the world.

Important: a large map with few players is more expensive than a small one with many. If you want to reduce the resources you need, reduce the map size first - see Change worldsize & seed.

Entities: what builds up over the weeks

A freshly wiped server is light. The requirements grow over the course of the wipe cycle, because players build:

• Every building part, every box and every trap is an entity that is computed continuously.
• Large clan bases with hundreds of building parts carry considerable weight.
• Electrical and industrial setups cost additional computing time in every tick.

The practical consequence: a server that runs smoothly right after the force wipe can be noticeably slower three weeks later. Size for the end of the cycle, not for the beginning.

Why player count is the worst yardstick

Almost every provider page sorts game servers by player count. With Rust, that is misleading, because the server simulates the world regardless of how many people are connected. Terrain, monuments, animals and all saved objects are computed even when nobody is online at night.

An additional player mostly costs network load and computing what they do in their immediate surroundings. Compared with the base load of the world, that carries little weight. The comparison worth remembering: ten players on a 4500 map usually put more load on the server than fifty on a 3000 map.

With us, player count is not a price factor for that reason alone: slots are unlimited; you pay for RAM, storage and computing power. You set the upper limit yourself via server.maxplayers in the server.cfg - for gameplay reasons, not because a license enforces it. Why the slot count has had its day as a measure overall is explained in Game server slots explained.

An upper limit still makes sense: it prevents the map from filling up so much on a busy wipe day that nobody can find building space - and so protects exactly the game feel you chose the map size for. As orientation, use the slot recommendation per plan on the Rust product page; it is a recommendation, not a technical lock.

Plugins and framework

A modded server needs more than vanilla. The extra load depends less on the number of plugins than on what they do:

• Light plugins - chat, ranks, welcome messages. Barely noticeable.
• Medium load - shops, kits, teleport, gather rate plugins.
• Heavyweights - events, NPCs, zones and anything that continuously scans the world.

A single badly written plugin can cost more than twenty good ones. Which one it is shows up in the analysis in Optimize performance & FPS. The choice of framework itself - Oxide or Carbon - does not make a dramatic difference to the requirements.

How to recognize a server that is too small

• Server FPS below 30 during operation - the most important indicator in Rust.
• Noticeable delay when building and when opening boxes.
• Very long startup time when loading the map.
• Increasing sluggishness over the wipe cycle.
• Crashes with memory messages - see Server will not start.

If this only happens toward the end of the cycle, the map is too large for the resources. If it happens right after the wipe, the resources are too tight in general.

Measure instead of guessing: three values over the cycle

Instead of calculating the requirements in advance, you read them off the running server. Three values are enough - the key is to record them once shortly after the wipe and once toward the end of the cycle and compare them:

• Server FPS via server.fps in the console, measured at peak time. The trend over the weeks says more than any single value.
• RAM usage in the web interface, also at peak time and not at night with three players.
• Size of the identity folder via WebFTP or SFTP. It grows with the number of saved objects and is therefore the most direct measure of entity load you can get without extra tools.

If the folder grows considerably while server FPS drop in the same period, you have proven the cause instead of guessing it. A save process that takes noticeably longer points in the same direction - short hangs at intervals of server.saveinterval are a reliable early warning sign.

The limit of this method: it shows you that the load is rising, not which plugin is involved. For that, the step-by-step analysis in Optimize performance & FPS is the right way - only after that is it worth asking about a larger plan.

The right order when planning

1. Decide on the map size - it determines the base load.
2. Decide between modded and vanilla - plugins come on top.
3. Choose the wipe cycle - short cycles keep the entity count low, long ones let it grow.
4. Only then choose the plan - the tiers are listed on the Rust product page, and with prices and the assignment by map size also in How much does a Rust server cost?.

If you are unsure, start with a smaller map and grow. A 4500 map on resources that are too tight frustrates everyone - a 3000 map that runs well does not. General guideline values across all games are in How much RAM do I need?.

Two points take the pressure off the decision. First, an upgrade to a larger plan is possible at any time without losing your world, plugins or configuration - so you do not have to decide today how big your server will be in six months. Second, the map size can be chosen anew at the next wipe anyway: if you notice that 4500 was too large, you start the coming cycle with 3500 and have solved the problem at its root.

Automatic backups are not part of the plan - with us, backups are self-service across the board via the WebFTP file manager or SFTP. Plan those few minutes in before every larger change, for example before a framework update or a map change, see Create backups.

Frequently asked questions