Game host or your own server?
On this page
A game host gets a Rust server running in minutes and looks after the machine for you. Your own VPS or dedicated box takes an evening to set up and makes you the system administrator, but it can run far more than the game, and you choose the hardware. Here is how the two compare, and which hardware actually matters, from load tests on our own servers.
The short answer
- Use a game host if you want to play tonight, never want to see a command line, and only need the game server.
- Use your own box if you want a website, a control panel, Discord bots, backups or custom map files next to the game, if you want to choose the CPU, and if you are willing to keep a Linux machine updated and locked down. Learning that is what the setup guide is for.
Side by side
| Game host | Your own VPS or dedicated box | |
|---|---|---|
| Getting started | Minutes, from a web panel | An hour or two with a guide |
| Command line | Usually none: you get the panel and file access | Full root access |
| Other services on the same machine | Usually not | Yes: website, panel, bots, database, backups |
| Custom maps | Usually, through a map URL setting | Yes, and the same box can serve the map file |
| Pricing | Often per slot or per plan | Per CPU, memory and disk; slots are just a setting |
| CPU | Often shared; the model is not always stated | You choose, and dedicated cores are available |
| Updates and security | The machine is theirs; you update the game from the panel | All yours: the system, the game, the firewall |
| Backups | Often built in | You set them up |
| DDoS filtering | Usually included and tuned for games | Depends on the provider; ask |
| When it breaks | Their support | You |
What a game host does well, and where it stops
A game host rents you a Rust server through a web panel: start and stop buttons, a settings form, one-click installs of Carbon or Oxide, file access, and often backups and DDoS filtering. You never touch the operating system, and nobody expects you to.
The limits come from the same design. You can do what the panel allows and nothing else. There is usually no shell, so you cannot install other software, run a scheduled job of your own, or see what the machine is doing when the server stutters. A website, a database, a Discord bot or a panel agent usually has to live somewhere else, and you pay for that separately.
Plans are usually priced by slot or by tier. The CPU is often shared with other customers' servers, and the exact model and clock speed are not always stated. For Rust, the clock speed of one core matters more than anything else on the spec sheet, as the numbers below show.
What your own box does well, and what it costs you
A VPS is a virtual machine with a share of a bigger server. A dedicated box is a whole physical machine. Either way you get a Linux shell with full control, and you can install anything.
One machine can run the game server and everything around it: a control panel, your server's website, Discord bots, nightly backups, a custom map file for players to download. Our own Australian box runs the game server and this directory (the website, its database and the compiler that checks every hosted plugin file) on one 8 vCPU cloud VM.
You pay for CPU, memory and disk, not slots. The slot count is just a setting.
The cost is your time. You are the system administrator: security updates for the operating system, the monthly Rust update, framework updates, the firewall, SSH keys, backups, and noticing when something breaks at 3 am. The setup guide covers each of these.
Sharing the box with other services
Everything else on the box competes with the game for CPU time. We fence ours off with systemd. The directory's compiler runs at the lowest priority, is capped at one core and 2 GB of memory, and carries a higher out-of-memory score, so the kernel picks it sooner if memory runs out. These are the lines in its service file:
Nice=19
IOSchedulingClass=idle
CPUQuota=100%
MemoryMax=2G
OOMScoreAdjust=500With nobody on the game server, it ran at about 150 to 170 frames per second at idle, 124 to 140 while the compiler worked through every hosted plugin file (one dip to 96), and about 150 again afterwards.
Hardware that matters for Rust
These numbers come from load tests on our own servers. The test players were phantom players: real player objects inside the server that walk, sprint, fight, loot and chat, driven by a test plugin. They are not network clients, so the network side costs a little differently from real players. Treat the numbers as a guide, not a promise.
A word you will see a lot: frame time. It is how long the server takes to run one update of the whole world. Lower is better. 33 ms a frame is 30 updates a second.
One fast core beats many slow ones
Rust runs its world simulation on one main thread: players, physics, building, AI and the queue of entity updates. Plugins run on that thread too. When that thread is busy, nothing else on the box can help it.
During a test with 200 active players, one server thread sat at 99 to 100% of a core while the whole 8 vCPU box was at 20%.
Spare cores are not wasted. Networking runs on its own threads by default, the game hands some work to a pool of job threads (anti-cheat checks and navmesh building, among others; 7 threads on that box), and everything else on the machine runs beside the game instead of on top of it. What they cannot do is make the main thread faster.
One setting spreads more work over those cores: server.useplayerupdatejobs 4 builds each player's network updates in parallel. The default is 3, and the game's own help text calls 4 experimental. In our 200-player test it cut the frame time from 25.0 ms to 22.7 ms, about 9% (Australian server, Rust build 25083359, 2026-09-26). Test it on your own server before you rely on it.
What an empty world and a crowd cost
| Test | Average frame time | Average server fps |
|---|---|---|
| One player, nothing else going on | 10.4 to 10.6 ms | about 95 |
| 200 test players connected, all asleep | 16.4 ms | 62 |
| 200 test players active, bunched near spawn | 32.4 ms (worst 53 ms) | 32 (lowest 22) |
| 300 test players active, bunched near spawn | 61.4 ms (worst 122 ms) | 18 (lowest 11) |
The empty world is the floor you start from: decay, AI and spawns cost about 10.5 ms a frame on that map before anyone plays. Players who move and fight cost far more than sleepers. A crowd costs more than the same players spread out: from 200 to 300 bunched players, player-on-player hits went from 173 to 23,984, and every movement update had to reach everyone in range. A real crowd spread over the map sits somewhere between those rows.
Uptime makes it slower
After a restart, the same server ran the same 200-player test at 25.0 ms a frame instead of 32.4 ms, and with one player on it idled at 6.4 ms instead of about 10.5 ms. Part of that is fewer entities right after boot (79,000 against 93,000). Part is memory: the server's own managed-memory figure was 3.5 GB after 51 hours and 1.8 GB ten minutes after the restart.
A daily restart is cheap insurance. The setup guide shows one with a five-minute warning for players.
Plugins
Our 58 plugins together took 0.6% of the server's time at 200 test players and 1.6% at 300. The test tools themselves are not counted.
The framework that runs plugins adds a little on top; our estimate is a few percent at 200 players, not a clean measurement. Plugins built with care are rarely the problem. One careless plugin can be: in the same test one of ours sent a separate formatted chat message to every player each time anyone unlocked a trophy, 86,000 messages in the 300-player run. We changed it to a single broadcast. The check report on every plugin file hosted in this directory lists the hooks it uses and flags the usual suspects, such as timers under a second and loops over every entity.
Memory
- A 1500 m test map with Carbon and no plugins used about 2.9 GB after boot. (Our Dallas box: Ryzen 9 7950X, Rust build 25454815, Carbon 2.0.259, 2026-09-28.)
- Our Australian server peaked at 8.1 GB during 200-player tests with the profiler recording, and the kernel stopped it once when the 15 GB box, which has no swap, ran out of memory. (Rust build 25083359, 2026-09-26.)
For one full-size server with plugins, 16 GB leaves room to spare. Add more for a second server or heavy extras on the same box.
What to buy, from these numbers
- The fastest single core you can get. A recent CPU with a high clock speed. Our estimate, not a measurement: a 4.5 to 5 GHz class CPU would roughly halve the frame times in the table above.
- 4 to 8 fast cores are plenty for one server plus a website, a panel and backups.
- 16 GB of RAM for one full-size server with plugins; 32 GB for two servers or heavy extras.
- NVMe storage, with room for a week of backups.
DDoS protection, and what to check
A DDoS attack floods your server's address with traffic until players drop. Rust's game traffic is UDP and goes straight to the box, so protection has to happen at the provider's network, before the traffic reaches you. A web proxy in front of your website does not cover the game port.
Ask a provider these questions before you buy:
- Is game UDP traffic filtered? Generic protection is often built for websites. Ask whether they filter game traffic, and whether Rust is one of the games they tune for.
- Always on, or only after detection? Protection that switches on after an attack is detected can mean minutes of disconnects first.
- What happens when an attack is too big? Some providers take your address offline (a "null route") until the attack stops, which ends your server for hours. Ask what their limit is and what they do above it.
- Is it in the price? And can you see attack reports?
Two things are on you. Keep RCON (the remote console) closed to everyone but your own address, and log in to the box with SSH keys, not passwords. The setup guide does both. And remember that everything on the box shares its address: a flood aimed at your website hits the game too.
Choosing a provider: what to check
- The CPU model, by name. "8 vCPU" says little. Ask for the model and its clock speed. Our Australian VM names its CPU only as "Intel Server Processor", and its 8 vCPUs are 4 cores with 2 threads each. Another of our boxes reported a different CPU from the one advertised. Check with
lscputhe day you get it. - Dedicated or shared cores. Shared cores can slow down when a neighbour gets busy. For a game server, dedicated is worth paying for.
- RAM: 16 GB for one full-size server with plugins, more for extras.
- NVMe storage with room for backups.
- Location: close to your players. Ping matters more than anything but the CPU.
- DDoS filtering for game UDP, as above.
- Snapshots and a web console. A snapshot is the undo button for the whole box. The web console still works when SSH does not, which is how you get back in after a firewall mistake.
- Terms that allow game servers. Some VPS terms forbid game servers or steady high CPU use. Read them.
- Monthly billing without a long lock-in. Hourly billing is handy for a test box.
- Ubuntu 22.04 or 24.04 LTS on offer, and an IPv4 address included.
Next
- Set up a Rust server on a VPS or dedicated box, step by step
- Set it up with AI, with prompts to copy
- Run MiX Panel on the same box (private preview)
