How we are building sub-second cold start for Garry's Mod servers

Cold-start time is one of those metrics that looks unimportant until a customer watches a progress bar for six seconds and wonders if something has gone wrong. We started taking it seriously in early 2026. This post explains what we changed, in what order, and what the numbers looked like at each step.

All figures in this post come from our public benchmarks page, which records every measurement run with full methodology notes. We do not report numbers we cannot reproduce there.

The baseline

Our starting point was a cold-start median of 6.2 seconds - measured from server creation to the server accepting its first connection, on production hardware, with no addons installed. That is the worst case for a new customer: an empty server with nothing cached.

We also had an image problem. The Garry's Mod container image we deployed to each server weighed 6.5GB. It was not a direct boot-time problem (the image was pulled once per node, not per server start) but it was contributing to provisioning delays and costing storage on every machine in the fleet.

First change: image slimming

We rebuilt the server image from scratch, keeping only the files the game server process actually needs at runtime. Everything else - build tools, intermediate layers, redundant libraries - was removed.

The result was a 141MB image, down from 6.5GB. That is a 98% reduction. As a bonus, per-server storage footprint on disk fell by 273MB, and provisioning a fresh server on a new node became considerably faster.

Cold-start time did not change much at this stage - the image was already cached on each node. But the groundwork it laid for the next change mattered.

Second change: measuring what was actually slow

Before making further changes, we instrumented the boot sequence. We split cold-start into named phases - container creation, binary load, game initialisation - and measured each independently across multiple runs.

The result was clarifying: 1.56 seconds (roughly 78% of the remaining cold-start time after image work) was spent in Docker container creation, not in the game server process at all. The GMod binary load and game init phases were comparatively fast.

That single finding changed what we built next.

Third change: Instant Boot

Container creation overhead exists because, in a standard deployment, a new container is created from scratch each time a server starts. Instant Boot removes that step by keeping a pre-warmed container in a ready state. When a server starts, the container already exists; we mount the server's data volume into it and let the game process start immediately.

In our testing, Instant Boot brings cold-start from about 6.2 seconds to 0.8 seconds - an ~87% reduction, and genuinely sub-second. Instant Boot is not live yet; 0.8 seconds is the figure we expect to report once it ships. The benchmarks page currently records the live cold-start of about 6.2 seconds.

What we are building alongside this

Instant Boot targets start time. A related feature, Standby mode, targets idle cost: when the last player disconnects, the server process is suspended rather than left running, and when the next player connects the server wakes on the incoming packet, with an expected end-to-end wake latency of about one second - fast enough that most players would not notice the server was sleeping.

Together they are designed to keep idle servers using significantly less CPU, with the player experience on an empty server close to that on an active one.

What is still in progress

The 1.56-second container creation overhead is not fully eliminated yet. Instant Boot removes it per-server by pre-warming a single container. The next step is a node-level pre-warm pool: a set of ready containers maintained across the node, so that even the first start after a node reboot skips the creation phase. That work is scoped and in the design phase.

We also know that the srcds binary load phase (the GMod server binary itself) accounts for roughly 22% of the remaining cold-start gap. That code is upstream, not ours to modify directly, but there are kernel-level prefetch approaches we have not yet tried.

When either of those ships, the benchmarks page will show the numbers before and after.

How we measure

Measurements use measure-startup.sh, which runs five timed cold-starts and records the median and standard deviation. We do not claim a change as an improvement unless the delta exceeds one standard deviation. All runs are logged, including the ones that changed nothing.

Full dataset at zerosrp.co.uk/benchmarks.

Continue reading

This post is part of the Fast Load series. Related articles: Fast Load: How We Are Cutting GMod Boot Time by 87%, How We Measure Server Boot Speed. The Fast Load feature page shows live benchmarks and what the feature means for your server.