Fast Load: How We Are Cutting Garry's Mod Server Boot Time by 87%

Server boot time matters more than it sounds. Every second a customer waits to connect is a second they doubt the purchase. We have been measuring and reducing it systematically since early 2026. This post explains what changed and how we measured it.

All numbers in this post are reproducible from our public benchmarks page, which logs every run with methodology notes.

Where we started

Our baseline cold-start for a Garry's Mod server was 6.2 seconds (median of five runs, no addons, production hardware). That is the time from "server created" to the server accepting connections. For context, community reports put vanilla GMod hosting at 45-90 seconds for a cold start - we were already faster, but we wanted to be faster still.

We also had a problem with the server image. The GMod container image we shipped to each server was 6.5GB. That is not a startup-time problem on its own, but it was a storage and provisioning problem that compounded everything else.

What we changed

Image slimming

We rebuilt the server image from scratch, removing everything that did not need to be in the container. The result: 6.5GB down to 141MB - a 98% reduction. This did not move the cold-start number directly (the 6.5GB image was only pulled once per node, not per boot), but it cut per-server storage footprint by 273MB and made provisioning a new server considerably faster.

Startup phase instrumentation

Before changing anything in the boot path, we instrumented it. We split the cold-start into distinct phases - container creation, binary load, game init - and measured each one independently. The result: 1.56 seconds (78% of the remaining boot gap after image work) was being spent in the Docker container creation step, not in the game server process itself.

That finding dictated the next step.

Instant Boot

Instead of creating a new container every time a server starts, Instant Boot keeps a pre-warmed container in a ready state and swaps the server data volume into it on demand. The container creation overhead disappears because the container already exists.

Expected result once Instant Boot ships: cold-start drops from about 6.2s to 0.8s (-87%) - sub-second from press-start to accepting connections. Instant Boot is not live yet; the benchmarks page currently records the live cold-start of about 6.2s.

Standby mode

Instant Boot targets the start time; Standby targets the idle cost. A game server running but waiting for players uses CPU even when nobody is connected. Standby is designed to suspend the server process when the last player leaves, reducing idle CPU usage, then wake it on the next incoming packet - an expected end-to-end wake latency of about 1 second. Both are in development alongside Instant Boot.

The combination means idle servers consume significantly less resource, and the next player to connect gets a running server within a second.

What is still in progress

The 1.56s container creation overhead is the remaining lever we have not fully pulled. The work to eliminate it at the pool level - keeping a set of pre-created containers warm across the node rather than per-server - is scoped and in the design phase. When it ships, the 0.8s Instant Boot time will drop further.

We also identified that the srcds binary load phase accounts for about 22% of the remaining gap. That phase is upstream code we do not control, but there are kernel-level prefetch techniques we have not tried yet.

How we measure

All results come from measure-startup.sh, which runs five timed cold-starts and records the median and standard deviation. We treat any delta smaller than one standard deviation as noise and do not claim it as an improvement. The benchmarks page shows every run, including the attempts that changed nothing - we do not cherry-pick.

See zerosrp.co.uk/benchmarks for the full dataset.

Continue reading

This post is part of the Fast Load series. Related articles: How We Are Building Sub-Second Cold Start, How We Measure Server Boot Speed. The Fast Load feature page shows live benchmarks and what the feature means for your server.