The State of CI/CD for Game Studios 2026

How game studios build, cook, and ship across a platform matrix, and why the build farm, not the test suite, is the most expensive thing in the pipeline.

Executive summary

Game CI does not look like web CI, and applying web-CI instincts to a game pipeline optimizes the wrong things. A single game build can compile millions of lines of native code, cook tens of gigabytes of assets, and then repeat the whole expensive sequence across a matrix of consoles and PC targets. The pipeline is long, heavy, and dominated by compute, which makes the build farm, not the test suite, the thing that drives both wall-clock time and spend. In most game pipelines the tests are a minor slice of the bill, and an optimization strategy aimed at sharding them is aimed at the wrong bottleneck.

The data shows where studios actually bleed time and money: redundant asset cooks that ignore caching and re-cook assets that did not change, full rebuilds where an incremental or distributed build would do, and a platform matrix that multiplies every one of those costs across every target. Each of these is mechanical waste rather than essential work. The cook only has to happen when the assets change, the compile only has to redo the code that changed, and the shared work across platforms only has to run once if it is kept on a common runner.

The studios that stay fast invest in the levers that fit the shape of game CI. They cache build outputs and cooked assets aggressively so a typical change does not pay for a full rebuild, they distribute compilation across machines so the long native compile parallelizes, and they keep the heavy shared work, the code that compiles identically and the assets that cook once, on cheap Linux runners while running only the genuinely platform-specific legs per target. The result is a pipeline where most changes validate in single-digit minutes rather than the better part of an hour.

This report quantifies the build-farm tax. It models clean build-and-cook times across platform targets, breaks down where a game build minute actually goes, and shows how caching strategy collapses the wall-clock time of a typical change. It then explains why game build demand, bursty between milestones and overwhelming during crunch, is a poor fit for a fixed on-prem farm and a good fit for elastic managed runners with persistent, high-throughput caching.

The framing for a studio's engineering leadership is that the build farm is the pipeline's center of gravity, and the wins come from doing less redundant heavy work rather than from speeding up the cheap parts. Caching, distribution, a Linux-first matrix, and elastic capacity are the levers, and together they turn the build farm from a fixed cost sized for peak into elastic capacity that matches the real, spiky demand curve of game development.

The asset cook, not the test suite, is the expensive leg

In most game pipelines the largest single consumer of build minutes is asset cooking and packaging, with native compilation close behind. Cooking converts source assets, textures, meshes, audio, levels, into the platform-specific formats the engine ships, and for a content-rich title that is tens of gigabytes of work that takes real time and real compute. Tests, by contrast, are a minor slice of the bill.

The build-minute chart shows the distribution plainly. Asset cook and packaging is the largest share, native code compilation is the next largest, uncached dependency fetch takes a meaningful slice, and queue and provisioning is the smallest. The two heavy legs, cook and compile, together dominate the build minute, which is exactly the opposite of a typical web pipeline where the test suite is the long pole.

This inverts the usual CI optimization advice in a way that matters. The biggest wins in game CI come from caching cooked assets so unchanged content is restored rather than re-cooked, and from distributing compilation so the long native build parallelizes across machines. Sharding a test suite that was never the bottleneck buys almost nothing here; the leverage is entirely in the cook and the compile.

• Asset cook and packaging is the single largest consumer of build minutes, with native compile close behind.
• Tests are a minor slice, so web-CI test-sharding advice misses the real bottleneck.
• The wins are caching cooked assets and distributing compilation, not optimizing the test suite.

The platform matrix multiplies everything

Every console and PC target reruns the build, and each leg is long. The build-time chart shows the per-target cost: a Linux dedicated server build is the cheapest leg, a Windows PC build longer, and the console targets longer still, each measured in the better part of an hour for a clean build and cook. Stack those legs across a full matrix and the cost multiplies, with a complete matrix running several times the cost of a single Linux build leg.

The trap is that much of what each platform leg does is identical across platforms. The game logic compiles the same way, and most assets cook once into a form that several targets can share. When a naive matrix reruns all of that per platform, it is paying N times for work that only genuinely differs at the edges, where the platform-specific compile flags, the console SDK packaging, and the per-target asset variants live.

The studios that stay affordable keep the heavy shared work, the code that compiles identically and the assets that cook once, on cheap Linux runners, and run only the genuinely platform-specific legs per target rather than rebuilding the world N times. The shared work happens once on the cheapest runner, and each platform leg does only the incremental, target-specific portion, which collapses the matrix multiplier from N times the full build to N times a much smaller delta.

• Each platform leg is long, and a full matrix runs several times the cost of a single Linux build.
• Most compile and cook work is identical across targets and only differs at the platform-specific edges.
• Do the shared work once on cheap Linux and run only the per-target delta on each platform leg.

Caching is the highest-leverage investment in game CI

A clean full rebuild and cook is the worst case, and most changes do not need it. A typical change touches a small fraction of the code and a small fraction of the assets, so re-cooking every asset and recompiling every translation unit is almost entirely wasted work. The whole point of caching is to make the build pay for the change rather than for the repository.

The cache-impact chart shows the gradient for a typical change. A no-cache full rebuild is the worst case, a dependency cache alone removes a chunk, a build-plus-asset cache removes most of it, and distributed compilation on top of caching brings a typical change down to single-digit minutes. Each step is mechanical configuration of the build and runner layer rather than a change to the game, and each one compounds with the last.

Because game caches are large, tens of gigabytes of cooked assets and build outputs, the cache layer must be fast and durable, not a slow pull from remote storage that costs as much as re-cooking. This is exactly where a runner platform with persistent, high-throughput caching pays for itself across every build, restoring the unchanged majority of the cook and the compile in seconds so the build only does the work the change actually requires.

• Most changes touch a small fraction of code and assets, so full rebuild-and-cook is mostly wasted work.
• Build-plus-asset caching with distributed compilation cuts a typical change to single-digit minutes.
• Large game caches demand a fast, durable, local cache layer, not a slow remote pull.

A fixed build farm is the wrong shape for spiky demand

Game build demand is bursty in a way few other workloads match. It is quiet between milestones, when a handful of engineers iterate on isolated features, and then becomes a wall of builds before a vertical slice, a demo, a publisher milestone, or a release, when the whole studio is committing and every platform leg is in flight at once. The demand curve has tall, narrow peaks separated by long quiet stretches.

A fixed on-prem farm sized for the peak sits idle most of the month, depreciating expensive silicon that no one is using between milestones, while a farm sized for the average starves the studio during crunch, exactly when fast builds matter most and a queue of waiting builds directly slows the run-up to a deadline. Neither sizing fits, because no single fixed capacity matches a demand curve with peaks this far above its average.

Elastic managed runners scale to the burst and cost nothing between milestones, matching the real demand curve instead of paying for the peak year-round. During crunch the capacity is there to run the full matrix without queueing, and during the quiet stretches there is no idle farm to pay for. The studio buys the peak only when the peak is happening, which is the only sizing that fits a workload this spiky.

Cross-platform tooling quietly pulls in expensive runners

Some platform legs require operating systems that cost a premium at hosted rates. Tooling and signing for certain targets, and any macOS or iOS-facing work for studios shipping on Apple platforms, pull expensive runners into the matrix, and a macOS CI minute costs 10x a Linux minute while a Windows minute costs 2x, so a few platform-specific legs can take an outsized share of the bill.

The runner-cost chart shows the per-minute spread across hosted tiers and a managed alternative, and the gap between the cheapest and most expensive operating system is large enough that letting expensive runners do cheap, OS-agnostic work is a costly mistake. The same Linux-first discipline that controls the matrix multiplier applies here: the expensive operating systems should do only the work that genuinely requires them.

Keeping the heavy shared compile and cook on cheap Linux and reserving the premium operating systems strictly for the signing, packaging, and platform-specific legs that truly need them keeps the expensive runners from dominating the bill. The platform-specific surface is small relative to the full build, so reserving the premium runners for that surface preserves full platform coverage while keeping most of the spend on the cheapest tier.

Transient failures on hour-long builds are uniquely costly

A flake on a sub-minute web test wastes seconds. A transient failure on an hour-long game build, an out-of-memory kill partway through a giant cook, a runner reclaim, a registry timeout fetching a large dependency, throws away the better part of an hour of the most expensive compute in the pipeline and forces the whole build to start again. The cost of a needless re-run scales with the length and weight of the build, and game builds are the longest and heaviest a studio runs.

These failures are overwhelmingly mechanical rather than real defects. An OOM kill on an undersized runner during a large cook is a sizing problem, a reclaim is the cloud taking the instance back, a download timeout is a network blip. None of them indicate a problem with the game or the build configuration, and all of them pass on a clean retry, which means the right response is automated recovery rather than an engineer re-triggering an hour-long build by hand.

Self-healing runners that detect a known-transient signal and retry on a fresh environment matter more on game builds than almost anywhere else, precisely because the recovered work is so large. A transient OOM kill on a giant cook does not torch an hour-long build that simply needed a clean retry; the platform absorbs the failure and the build completes, turning what would have been an hour of wasted crunch-time compute into a brief, automatic recovery.

Managed runners capture the savings without owning the farm

Owning a build farm means buying for peak, patching it, hardening it, and paying for idle silicon between releases, all while carrying the operational burden of keeping it running during the crunch weeks when it is under the most load and the team has the least slack to maintain it. For all but the largest studios with dedicated build engineering, that burden competes directly with shipping the game.

Managed runners deliver the elastic capacity a studio needs during crunch and capture roughly 69 percent of the compute savings versus hosted runners, while removing the idle and the operations entirely. The capacity is there when the milestone hits and gone when it passes, the patching and hardening are the platform's problem, and the per-minute rate sits well below hosted on the heavy legs where game CI spends most of its minutes.

The combination of elastic capacity, persistent high-throughput caching, and automated recovery is what makes managed runners the right substrate for game CI rather than just a cheaper one. The caching collapses the cook and compile for typical changes, the elasticity matches the spiky milestone-driven demand, and the self-healing protects the hour-long builds from mechanical failures, so the studio gets fast builds during crunch without owning, sizing, or babysitting a farm sized for a peak that only arrives a few times a year.

• Owning a farm means buying for peak, patching it, and paying for idle silicon between milestones.
• Managed runners capture roughly 69% of compute savings while removing idle and ops.
• Elastic capacity, persistent caching, and auto-recovery together fit the spiky, heavy shape of game CI.

Recommendations

Cache cooked assets and build outputs aggressively

The asset cook is the largest consumer of build minutes, and most changes touch only a fraction of the content. Cache cooked assets and build outputs on a fast, durable, local cache layer keyed to content, so a typical change restores the unchanged majority in seconds and pays only for what actually changed instead of re-cooking tens of gigabytes every run.

Distribute compilation to parallelize the long native build

Native compilation is the second-heaviest leg, and it parallelizes well. Distribute the compile across machines so the long build is shared rather than serial, which combined with caching brings a typical change down to single-digit minutes from the better part of an hour, without changing a line of game code.

Keep shared work on Linux, run only per-target deltas

A full platform matrix multiplies every cost, but most compile and cook work is identical across targets. Do the shared work once on cheap Linux runners and run only the genuinely platform-specific legs per target, and reserve the premium operating systems (macOS at 10x, Windows at 2x Linux) strictly for signing and packaging that truly needs them.

Use elastic capacity sized to the milestone, not the year

Game build demand is quiet between milestones and overwhelming during crunch, the worst fit for a fixed farm. Use elastic managed runners that scale to the burst and cost nothing between milestones, so the studio buys the peak only when the peak is happening rather than depreciating an idle farm sized for a few crunch weeks a year.

Auto-heal transient failures on long builds

A transient OOM kill or reclaim on an hour-long cook wastes the most expensive compute in the pipeline and forces a full restart. Run on self-healing runners that retry mechanical failures automatically on a fresh environment, so a network blip or a sizing hiccup during crunch does not torch an hour-long build that simply needed a clean retry.

Outlook

Expect the gap between studios that treat the build farm as elastic, cached infrastructure and those that run a fixed on-prem farm to widen as titles grow heavier. Asset budgets and code sizes are rising, which lengthens every cook and compile and raises the cost of every redundant rebuild, so the studios that cache, distribute, and keep shared work on cheap Linux will pull further ahead while the studios that re-cook the world on every change feel the cost curve steepen against them.

The architectural direction is toward persistent high-throughput caching, distributed compilation, a disciplined Linux-first matrix, and elastic capacity matched to milestone-driven demand, with automated recovery protecting the long builds from mechanical failures. These are not separate optimizations competing for attention; they reinforce each other, because caching, distribution, and elasticity together are what let a studio run a full platform matrix during crunch without owning a farm sized for a peak that arrives a few times a year.

For most studios the practical takeaway is that the build farm is the center of gravity of game CI, and the wins come from doing less redundant heavy work rather than from speeding up the cheap parts. A runner layer that caches the cook and the compile, distributes the long build, keeps the expensive operating systems on a short leash, scales to the milestone burst, and heals the transient failures turns the build farm from the most expensive thing in the pipeline into elastic capacity that fits the real shape of how games get made.

Methodology

This report synthesizes publicly available industry data (developer surveys, the DORA State of DevOps research, published cloud and CI runner pricing) with Latchkey's own analysis of game-build CI/CD runner economics. Game-specific figures (build-and-cook times, the platform-matrix multiplier, the build-minute split, and caching-strategy times) are Latchkey modeled estimates derived from public pricing and typical large-asset build shapes, not a primary survey of named studios, and are labeled as such. OS cost multipliers reflect published GitHub Actions - billing & pricing rates (Windows 2x and macOS 10x a Linux minute), and runner rates reconcile with the shared Latchkey pricing spine. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• Stack Overflow Developer Survey
• GitHub Actions - billing & pricing
• AWS EC2 On-Demand pricing
• GitHub Actions documentation

More Latchkey reports