Cold Start
Cold start is the time between requesting a game server and its container being ready to take a match, provisioned from scratch rather than allocated onto something already running. The game then loads inside the container before players connect. A cold start sets the floor on how long a matched group waits, and long ones force studios to hold warm capacity, which costs money.
Also called
boot time, server boot time
,
What Happens During a Game Server Cold Start?
A cold start is the platform's half of getting a match online. When a matchmaker asks for a server, the platform picks a machine, makes sure the server image is on it, creates the container, maps the ports players will connect through, and starts the server process. The container is then ready to take the match.
The game's half comes next. The engine starts inside the container and loads the map before players connect. That part depends on the build, not on the hosting: a headless server that ships without rendering assets usually has less to load.
Where the platform's time goes varies. Getting the image onto the machine is often the slowest step, so platforms that start servers quickly tend to keep images cached close to where they run. And if no running machine has room, a new one has to be provisioned first, which is a different order of time altogether (see "Warm Pools or Cold Starts: What Does Each Cost?")
In Practices - Insights from Edgegap's Blog
Article's key insights
Infrastructure Modernization Objective: KRAFTON aimed to eliminate operational bottlenecks and improving scalability for hundreds of thousands of concurrent players across global regions by switching from session-based game server to modern container-based game server orchestration.
Agones Scaling Limitations: The open-source game server orchestration platform suffered from 15-minute bootstrapping delays during peak scaling events. KRAFTON's engineering team invested heavily in custom solutions to reduce this to 3-4 minutes through container registry proxies and Karpenter adoption. Whereas developers can simply use a fully managed solution like Edgegap which boots game server from cold start in 2 second median (October 2026, /platform-data/).
Operational Efficiency Benefits: Containerization reduced environment provisioning to under 5 minutes and enabled self-service capabilities. Teams gained autonomous access to testing infrastructure without DevOps intervention.
Hidden Resource Impact: The modernization journey consumed years of specialized engineering effort that could have been directed toward gameplay improvements. Most studios cannot afford this level of infrastructure investment while maintaining competitive development cycles.
Managed Platform Alternative: Fully managed solutions deliver equivalent, if not better, performance and scaling capabilities without internal complexity. Studios achieve enterprise-grade infrastructure through simple integration rather than multi-year implementation projects by using a platform like Edgegap.
Why Do Published Server Start Times Disagree?
Because they often measure different jobs. Three questions tell you what a number covers:
Where does the clock start? Assigning a match to a server that is already running is an allocation. Creating the server for that match is a cold start. Both are real, and the first is usually faster because the work was done earlier.
Where does it stop? At container ready, or once the game has loaded. The gap between the two is the game's own startup time.
Median or average? A median is what a typical match waits. An average can be pulled up or down by a few unusual starts.
Two honest figures can differ for these reasons alone. A warm number says how fast a buffer hands out what it already holds. A cold number says what happens when the buffer is empty.
Warm Pools or Cold Starts: What Does Each Cost?
A warm pool keeps servers running before players need them, so a match can be assigned in moments. AWS GameLift calls it a buffer and states the trade plainly: a bigger buffer cuts player wait time, but you pay for capacity you may not use (AWS documentation). The Agones fleet autoscaler works the same way, scaling the fleet to hold a set number of ready servers (Agones documentation).
The pool has to be sized ahead of demand, and a spike can empty it. After that, new matches wait for capacity to be added. On its Agones setup for PUBG: Battlegrounds, KRAFTON reported up to 15 minutes to bring new servers online during peak scaling: 1 to 3 minutes provisioning instances, 2 to 3 bootstrapping them and 5 to 10 provisioning pods (AWS re:Invent 2024, summarised here).
The faster the cold start, the smaller the pool needs to be, and the less a spike costs in player wait time.
A word from our sponsor (ourselves!)
Warm pools make allocation fast because you pay for servers that sit idle. Edgegap provisions a fresh game server in a median of 2 seconds from cold start, measured to container ready before your engine starts, so a server exists only once a match needs one.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Why We Measure Cold Starts From Scratch
Edgegap's Edge Cloud starts a game server in 2 seconds, median, from cold start: provisioned from scratch rather than allocated onto an already-running server, measured to container ready, before the game engine starts (platform data, rolling 30 days, as of 18 September 2026).
We measure from scratch because that is the case a launch tests. A warm pool hides startup time until a spike drains it, and from then on new matches wait for a cold start. When that wait is 2 seconds, servers can be deployed on request, with no buffer to size or pay for.
Warm capacity still has a place. If a game takes a while to load its map, servers can be prewarmed through Server Browser scaling policies, typically on Private Fleets. Prewarming covers the game's own load time, which deployment speed does not touch.
,
