The State of Kubernetes CI/CD 2026

GitOps went mainstream and solved the deploy, but the build-and-test phase that feeds the cluster is where the time and money still leak.

Executive summary

Kubernetes is no longer the interesting part of the story. Running containers in production is now the default for most organizations, the orchestration layer is mature and largely commoditized, and the operational patterns are well understood. The interesting part in 2026 is the pipeline that feeds the cluster, and specifically the widening gap between the polished, declarative, well-instrumented GitOps deploy and the noisy, expensive, under-instrumented build-and-test phase that has to happen before any manifest is reconciled.

GitOps with Argo CD and Flux solved the deploy half of the problem and solved it well. The cluster pulls desired state from git and continuously reconciles toward it, deploys are auditable because the desired state is a commit, and a rollback is a git revert rather than a frightening manual intervention. For the deploy step itself, the story is genuinely good, and adoption of the GitOps model is now broad enough that it is the default way serious teams ship to Kubernetes.

But GitOps does nothing for the half of the pipeline that builds the image and validates it against a real cluster, and that half is where the wall-clock and nearly all of the variance live. Building the container image, running the integration suite against a real or simulated cluster, and standing up the ephemeral environment a pull request needs are all upstream of the reconcile, untouched by the GitOps tooling, and collectively far more expensive than the deploy they precede. The deploy is the part everyone instrumented; the build is the part that actually costs.

Ephemeral environments are the defining pattern and the defining cost of modern Kubernetes CI. Spinning a real, short-lived environment per pull request catches integration failures that a shared staging environment hides, and teams that adopt the pattern rarely want to go back. The catch is that a per-PR ephemeral environment can triple the CI minutes per merge, almost entirely because each one rebuilds container images from a cold cache. The pattern is worth it, but only when the build that feeds it is cached, which turns the cost question into a caching question.

This report quantifies the split between build, test, and deploy for Kubernetes-bound pipelines, the cost of per-PR ephemeral environments under different caching strategies, and where managed runners with warm caches change the math. The throughline is that the leverage in Kubernetes CI is not in the part GitOps already perfected; it is in the image build that sits on the critical path of every environment, every PR, and every promotion, and in the disposable compute that ephemeral environments demand constantly.

GitOps fixed the deploy, not the pipeline

Argo CD and Flux made the deploy step declarative, auditable, and easy to roll back, and the adoption chart shows how broad the GitOps model has become, with Argo CD and Flux together accounting for the majority of how teams ship to Kubernetes and scripted Helm and raw kubectl trailing. For the act of getting desired state into a cluster, the GitOps approach is a genuine success, and it deserves the adoption it has earned.

But the reconcile-and-wait step is a small fraction of total pipeline time, around 9 percent in the modeled split. By the time a manifest reaches the cluster, the expensive work is already done. The image has been built, the integration suite has run, and the ephemeral environment has been stood up, and all of that happened upstream of the part GitOps touches. The polished, well-instrumented deploy sits on top of a build-and-test phase that nobody gave the same attention to.

This matters because it tells teams where the leverage actually is. The deploy is fast, declarative, and observable, so optimizing it further yields almost nothing. The build and the cluster-level integration test that precede it are where most of the wall-clock and nearly all of the run-to-run variance live, and they are exactly the steps GitOps tooling does not address. A team that wants a faster path to production should look upstream of the reconcile, not at it.

Ephemeral environments are worth it if the build is cached

Spinning a real environment per pull request catches a class of integration failure that shared staging structurally cannot. A shared staging environment is a single mutable target that every PR contends over, so a bug only appears after merge when changes collide, and reproducing it means untangling whose change broke what. A per-PR ephemeral environment is isolated and real, so the integration failure surfaces on the PR that caused it, which is why teams that adopt the pattern rarely want to give it up.

The catch is cost, and the ephemeral-cost chart makes the shape clear. Shared staging only sits around 14 CI minutes per merge, a namespace per PR roughly 26, and a full ephemeral cluster per PR jumps to about 43, more than triple the shared-staging baseline. Almost all of that increase is the same work repeated: each ephemeral environment rebuilds its container images from a cold cache, so the cost scales with the number of PRs times the full uncached build, which is the worst possible multiplier.

The resolution is in the last bar of the chart. An ephemeral cluster per PR backed by a warm, shared layer cache lands near 19 minutes, close to the namespace-per-PR cost, while keeping the full isolation that makes ephemeral environments worth adopting. The pattern does not have to be expensive; it is expensive only when every environment rebuilds from cold. Warm the build cache and the isolation becomes nearly free relative to the cold version of the same workflow.

• Shared staging hides integration bugs until after merge; per-PR ephemeral environments surface them on the PR that caused them.
• A full ephemeral cluster per PR roughly triples CI minutes per merge, almost entirely from cold image rebuilds.
• A warm shared layer cache brings the same isolated workflow down near the namespace-per-PR cost.

The image build is the bottleneck before every deploy

Across Kubernetes-bound pipelines the image build is consistently the largest single phase. The pipeline-split chart puts image build at roughly 33 percent and cluster-level integration test at about 27 percent, so the two together are well over half the pipeline, while unit test and lint, manifest render and push, and the reconcile make up the rest. The build, not the test and certainly not the deploy, is the heaviest single thing the pipeline does.

What makes the image build the most important phase to optimize is not just its size but its position. It sits on the critical path of every environment, every pull request, and every promotion from one stage to the next. Every ephemeral environment needs a built image, every PR triggers a build, and every promotion may rebuild, so an improvement to the build compounds across all of those paths in a way that an improvement to any single downstream step cannot.

Teams that want faster deploys often tune the wrong end of the pipeline, optimizing the deploy or the manifest rendering that are already cheap while leaving the build untouched. The leverage is in caching the image build: a layer cache that persists across runs means most layers are reused rather than rebuilt, so the build collapses to the layers that actually changed. Because the build feeds every other phase, caching it is the change with the widest reach in the entire Kubernetes pipeline.

Cluster test environments need fast, disposable compute

The whole value of an ephemeral environment is that it is real and short-lived. It is real enough to catch integration bugs that mocks hide, and short-lived enough that it never accumulates the drift and contention that makes shared staging unreliable. But short-lived means the pipeline pays a fresh setup cost constantly, far more often than a long-lived staging box ever does, because every PR and often every push stands up and tears down its own environment.

That pattern is brutal on slow cold-start runners and kind to fast ones. A runner that takes a long time to provision and comes up with a cold cache punishes a workflow that provisions constantly, because the fixed setup cost is paid on every one of the many short-lived environments. A runner that comes up fast and carries a warm cache rewards the same workflow, because the setup cost is amortized across far more runs than a long-lived environment would ever generate.

The cost-per-deploy chart shows where this lands. Hosted runners scale in cost with core count, from roughly 21 cents on a 2-core to 58 cents on an 8-core, and throwing bigger runners at the problem mostly buys a more expensive cold start. A managed runner with a warm cache comes in around 6.5 cents, an order of magnitude below the hosted options, precisely because it attacks the setup-and-rebuild overhead that the ephemeral pattern pays over and over rather than the raw compute.

Transient cluster failures are mostly mechanical

A large share of red Kubernetes pipelines fail on transient, infrastructure-shaped problems rather than real regressions. An image pull backoff because the registry was briefly slow, a registry timeout during a push, a readiness probe that flaked because a dependency had not finished starting, a node that was not ready when a pod scheduled onto it. None of these is a bug in the code under test, and all of them pass on a clean retry once the timing works out.

The Kubernetes pipeline has an unusually wide surface for this kind of mechanical failure because it touches so many moving infrastructure pieces: a container registry, an image build, a cluster API, schedulers, probes, and the network between all of them. Each integration point is a place where a transient blip can turn a green change red, and an integration-heavy, ephemeral-environment workflow exercises all of them on every PR, which multiplies the opportunities for a mechanical false failure.

These pass on a clean retry, which is exactly the class of failure self-healing runners absorb without anyone changing a manifest or a test. When a step fails on a known-transient signal like an image pull backoff or a registry timeout, the platform retries it on a fresh environment automatically, so the mechanical majority of red pipelines never reaches the pull request. The developer sees only the failures that reflect a real problem with the change, which is the signal CI is supposed to provide.

Layer caching is the lever that bends every Kubernetes cost

If the image build is the largest phase and the most-repeated work in the Kubernetes pipeline, then the container layer cache is the single highest-leverage optimization available, because it attacks the build everywhere the build appears. A persistent layer cache means a build reuses every layer whose inputs did not change and rebuilds only the layers that did, which on a typical service is the application layer on top of a stable base, so the build collapses to a fraction of its cold cost.

The reason layer caching has such reach is that the build is upstream of everything. Cache the build and the per-PR ephemeral environment gets cheaper, because each environment reuses layers instead of rebuilding them, which is precisely the difference between the 43-minute cold ephemeral case and the 19-minute warm one. Cache the build and the cost per deploy drops, because the most expensive phase is mostly skipped. Cache the build and even promotions between stages get faster, because the image is already mostly assembled.

The structural requirement is that the cache persist across runs and be shared across the many short-lived environments the workflow creates, which is exactly what an ephemeral runner with no shared state cannot provide on its own. A managed runner with a warm, shared layer cache supplies the same cache to every build, every ephemeral environment, and every promotion, which is what lets the most-repeated work in the pipeline be done once and reused everywhere rather than redone on every PR.

• A persistent layer cache rebuilds only changed layers, collapsing the largest pipeline phase to a fraction of its cold cost.
• Because the build is upstream of everything, caching it makes ephemeral environments, deploys, and promotions all cheaper.
• The cache must persist and be shared across short-lived environments, which an ephemeral runner cannot do on its own.

What the fastest Kubernetes teams do differently

The teams shipping to Kubernetes fastest and cheapest have stopped optimizing the part GitOps already perfected and started optimizing the part it does not touch. They treat the image build as the center of gravity of the pipeline, they back their ephemeral environments with a warm shared cache so isolation does not cost a fortune, and they let self-healing absorb the mechanical cluster failures that an integration-heavy workflow generates constantly.

They also instrument the build-and-test phase the way GitOps instrumented the deploy. Because the deploy is observable and the build historically was not, the build is where regressions hide, so the fastest teams track build wall-clock, cache hit rate, ephemeral-environment cost per merge, and transient-failure rate, and they treat a regression in any of them as a bug. The visibility that GitOps brought to the deploy, they extend upstream to the build, which is where the cost actually is.

• Back ephemeral environments with a warm, shared layer cache so per-PR isolation stays affordable.
• Treat the image build as the highest-leverage phase and cache it aggressively across runs.
• Use fast, disposable compute so the constant setup cost of ephemeral environments is amortized, not paid cold.
• Auto-heal image pull backoffs, registry timeouts, and probe flakes so mechanical failures never reach a developer.
• Instrument the build-and-test phase the way GitOps instrumented the deploy.

Recommendations

Optimize upstream of the reconcile, not the deploy

GitOps already made the deploy fast, declarative, and observable, so further tuning there yields almost nothing. The image build and cluster-level integration test that precede the reconcile are over half the pipeline and carry nearly all the variance. Point your optimization effort at the build-and-test phase that GitOps does not touch.

Back ephemeral environments with a warm shared layer cache

A per-PR ephemeral cluster roughly triples CI minutes per merge, almost entirely from cold image rebuilds. A warm, shared layer cache brings the same isolated workflow down near the namespace-per-PR cost while keeping full isolation, so you get the integration coverage of ephemeral environments without the cold-rebuild tax.

Cache the image build, because it feeds everything

The image build is the largest single phase and it sits on the critical path of every environment, every PR, and every promotion. A persistent layer cache that rebuilds only changed layers compounds across all of those paths, making it the change with the widest reach in the entire Kubernetes pipeline.

Use fast, disposable compute for cluster tests

Ephemeral environments pay a fresh setup cost constantly, which punishes slow cold-start runners and rewards fast warm-cache ones. Bigger hosted runners mostly buy a more expensive cold start; a managed runner with a warm cache comes in roughly an order of magnitude cheaper per deploy because it attacks the repeated setup overhead rather than the raw compute.

Auto-heal mechanical cluster failures

Image pull backoffs, registry timeouts, readiness-probe flakes, and not-ready nodes fail pipelines that pass on a clean retry, and the Kubernetes pipeline has a wide surface for them. Retry these transient failures on a fresh environment automatically so the mechanical majority of red pipelines never reaches the pull request, and developers see only real regressions.

Outlook

Expect the gap between the polished GitOps deploy and the under-optimized build-and-test phase to become the central story of Kubernetes CI through 2026. GitOps adoption is now broad enough that the deploy is a solved problem for most teams, which means the differentiation moves entirely upstream, to who has the fastest, cheapest, most reliable image build and cluster-test phase. The teams that extended their instrumentation and optimization upstream of the reconcile will pull away from the teams that stopped at the deploy.

Ephemeral environments will keep spreading because the integration coverage they provide is genuinely better than shared staging, and the question for each team will shift from whether to adopt them to whether they can afford them, which is really a question about caching. The teams that back ephemeral environments with warm shared caches will run them at namespace-per-PR cost and keep full isolation; the teams that run them cold will either pay the tripled bill or quietly retreat to shared staging and lose the coverage.

The durable direction is that Kubernetes CI's leverage has migrated to the layer cache and the disposable runner. The orchestration is commoditized, the deploy is solved, and what is left is the build that feeds the cluster and the compute that stands up the environments, both of which reward warm, shared, fast infrastructure and punish cold ephemeral runners. The teams that build their Kubernetes pipeline on warm caches and fast disposable compute will ship to the cluster faster and cheaper than peers who keep optimizing the deploy that GitOps already perfected.

Methodology

This report combines publicly available cloud-native survey data and published CI pricing with Latchkey's own analysis of Kubernetes pipeline economics. 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. Tool-usage shares are synthesized from public cloud-native ecosystem data and shown as relative weights. Managed-runner savings of roughly 70% reflect Latchkey modeled rates against published GitHub-hosted pricing. Pricing reflects published rates at time of writing and should be verified against current provider pricing. 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

• CNCF Annual Survey
• DORA State of DevOps Report
• GitHub Actions - billing & pricing
• GitHub - Octoverse

More Latchkey reports