I cold-started a Rust dedicated server twice on CT 161 gamelab — Debian 12.15, unprivileged LXC, 4 cores of an i7-4790K, 8 GB — and measured it with zero players connected. The first start settled at 114.2% of one core; the second at 113.8%. That is more than a full CPU core doing nothing but standing there. It’s the first server on this box that behaves that way.
How I measured
LinuxGSM v26.4.0, ./rustserver auto-install. The dependency check stopped on Missing dependencies: lib32z1 and printed the apt command, because the game user has no sudo; I installed lib32z1 as my own user. SteamCMD anonymous, app 258550, download 6,111,762,123 bytes, Success! App '258550' fully installed. du of serverfiles: 5.8 GB.
gmeasure.py cold-starts with ./rustserver start, polls each second. ready = seconds until the game log (log/server/rustserver-game.log) contains Server startup complete. RSS of RustDedicated from /proc/<pid>/status every ~30 s. CPU = the process’s CPU time over a 60-second window at the end, from /proc/<pid>/stat, as % of one core. Disk = du.
The two cold starts
I ran two cold starts on the same procedural map, worldsize 3000, seed 623055343.
| Metric | First start (17:18:32) | Second start (17:34:59) |
|---|---|---|
| Ready time | 339 s | 82 s |
| RSS final | 4,729 MB | 4,283 MB |
| RSS peak | 4,723 MB | 4,282 MB |
| CPU idle (60 s window) | 114.2% of one core | 113.8% of one core |
The first start’s memory was still rising at the end: +35 MB over the last six minutes (4,686 at 510 s → 4,721 at 871 s). The second start sat about 450 MB lower and was four times faster to ready.
What the second start’s log shows
The first start’s game log was overwritten by the second start — LinuxGSM starts a fresh game log each start. So everything I know about the first start beyond timings is gone. The second start’s log, grepped in order, shows exactly what it did:
Generating procedural map of size 3000 with seed 623055343
[RustNav] Loading navmesh from path: server/rustserver/proceduralmap.3000.623055343.289.navmesh (synchronous: False)...
[RustNav] DLL Log: LoadNavMesh: applied 2 delta segment(s) to 'server/rustserver/proceduralmap.3000.623055343.289.navmes
[Rust.MapCache] Map uploaded to backend: https://files.facepunch.com/rust/maps/61c9e7047bfae64511b7c17c876a83407dca26cef
Server startup complete
[Rust.MapCache-Images] Image uploaded to backend: https://files.facepunch.com/rust/map-images/377bfacdc5202b9c9e991fe48d
Saving completeThe map is generated from the seed on every start; the navmesh is loaded from a file in server/rustserver/ that an earlier run saved (the log also shows Saving navmesh to path: the same file after startup). The server uploaded the map and a map image to files.facepunch.com on a LAN-only box with server.ip 0.0.0.0 — outbound, on its own. I won’t speculate why.
VPS hosting implications
RAM says an 8 GB plan: 4.3–4.7 GB does not fit a 4 GB plan. CPU says the vCPU count matters more than for the other games on this box, because the server idles above a full core before anyone is even connected. A VPS vCPU is not the same thing as one of this box’s i7-4790K cores, and I did not run Rust on any VPS, so I won’t claim how it behaves on any particular vCPU count.
The cheapest 8 GB plans, prices checked 2026-10-18, at the time of writing:
| Provider | Plan | RAM | vCPUs | Price |
|---|---|---|---|---|
| Hetzner | CPX32 | 8 GB | 4 vCPU | EUR 35.99/mo (from) |
| Vultr | Cloud Compute Regular 8 GB | 8 GB | 4 vCPU | USD 40.00/mo |
| DigitalOcean | Basic Regular 8 GiB | 8 GB | 4 vCPU | USD 48.00/mo |
Both Rust starts are rows in the server requirements table. The hosting cost calculator picks plans by RAM alone, so for Rust read the vCPU column yourself.
The box comparison
At zero players, idle CPU as % of one core: Valheim sits at 6.7%, Project Zomboid between 3.7 and 3.9%, Palworld at 9.8%. Rust is 113.8–114.2%. RAM for the same set: Valheim 1,432 MB, Palworld 948 MB (1,475 MB start peak), Project Zomboid 5,142 MB (4 GB heap) / 7,617 MB (shipped), vanilla DayZ 4,842 MB, Rust 4,283–4,729 MB.
