The State of Ephemeral Environments 2026

Per-PR environments have gone mainstream: this is what they cost, how fast they spin up, who runs them, and where the meter quietly runs while a PR waits for review.

Executive summary

Ephemeral environments, a fresh isolated stack spun up for each pull request and torn down on merge, have moved from a luxury at well-funded platform teams to a default expectation on many product repositories. They let reviewers click a real URL instead of trusting a screenshot, and they catch integration breakage before it reaches a shared staging box that everyone fights over. The pattern has crossed from novelty to baseline on the kind of repos where review quality matters.

But the convenience has a meter running underneath it. Every PR environment is provisioning work: pull images, restore caches, boot dependencies, seed data, and run health checks before the link is live. That spin-up time blocks reviewers, and the compute behind it, much of it idle while a PR waits for review, is a line item that scales with pull-request volume rather than with headcount. A busy repository with many small PRs can run more environment-hours than a quiet repository with twice the engineers.

This report quantifies where the spin-up minutes and dollars go, and where the cheap wins are. We model adoption by org size, spin-up time by application shape, the breakdown of a typical spin-up, and the per-environment compute cost across runner choices. The recurring finding is that the dominant costs, cold start and idle wait, are infrastructure properties rather than application properties, which means they are addressable at the runner and lifecycle layer without changing the application.

Two failure modes dominate the cost story. The first is tear-down discipline: teams are good at spinning environments up and bad at tearing them down, so orphaned stacks accumulate and bill quietly. The second is idle wait: an environment that boots in minutes then sits live for hours waiting on review burns compute the whole time. Both are lifecycle problems, and both are fixable with mechanical controls rather than heroic effort.

For engineering leaders the practical message mirrors the broader CI picture. The waste in ephemeral environments is mechanical, repeated, and tied to lifecycle and cold-start rather than to anything fundamental about previews. Tie the environment lifecycle to the PR state, scale to zero on idle, warm the cold-start path, and heal transient provisioning failures, and per-PR environments become an affordable default rather than a surprise on the cloud bill.

Adoption is real, but tear-down discipline lags provisioning

Per-PR environments have crossed into the mainstream, with adoption rising steeply by org size from a small minority of the smallest teams to the majority of large engineering organizations. The pattern is no longer a platform-team luxury; it is a default expectation on product repos where reviewers want to click a real URL rather than trust a screenshot.

But teams are good at spinning environments up and bad at tearing them down. Orphaned per-PR stacks, left running after a PR is closed, merged, or abandoned, are one of the most common sources of surprise cloud spend on repositories that adopt ephemeral environments. The asymmetry is structural: spin-up is triggered by an obvious event (a PR opening) while tear-down depends on a less salient one (a PR closing, often days later and unnoticed).

The fix is mechanical rather than cultural. Tie the environment lifecycle to the PR state webhook so a close or merge always triggers tear-down, and set a hard idle TTL as a backstop for the abandoned PRs that never formally close. The adoption chart below shows how broadly per-PR environments are now used, which is also the scale at which orphaned stacks quietly accumulate if tear-down is not automated.

Spin-up time is dominated by cold start, not your app

The largest slice of spin-up time is image pull and cold start before any of your code runs, followed by dependency and cache restore. Together those two infrastructure phases dominate the timeline, ahead of data seeding and health checks, which means the reviewer is mostly waiting on the platform rather than on the application.

That changes where the highest-leverage speedups live. They are infrastructure, not application: warm runner capacity, a fast dependency cache, and pre-pulled base images shave more wall-clock off the review wait than micro-optimizing application boot. A team that spends days shaving seconds off its app startup is optimizing the smaller slice while the cold-start slice it could remove with warm capacity sits untouched.

Self-healing managed runners with warm capacity remove the cold-start slice that reviewers feel most. Because the cold-start phase is the largest and is purely an infrastructure property, warming it is the single most effective way to make a per-PR environment feel fast. The donut below shows cold start and image pull as the dominant slice, which is exactly the slice warm capacity eliminates.

• Image pull and cold start are the largest spin-up slice, before any application code runs.
• The high-leverage speedups are infrastructure: warm capacity, fast caches, pre-pulled images.
• Micro-optimizing app boot tackles the smaller slice while the cold-start slice goes unaddressed.

The idle-wait tax is the hidden cost

A per-PR environment that boots in minutes but then sits live for hours waiting on review burns compute the whole time it idles. The spin-up cost is visible and gets all the attention, but the idle-wait cost is invisible and frequently larger, because review latency is measured in hours while spin-up is measured in minutes.

Modeled across typical review latency, idle wait can cost more than the spin-up itself. Our per-environment cost model shows the hosted-plus-idle-wait case running well above the bare hosted spin-up, because the meter keeps running for every hour the environment waits for a reviewer who is busy with other work. The cost scales with review latency, which is exactly the variable a busy team is least able to control.

Scale-to-zero on idle, or provisioning the environment lazily on first reviewer click, removes most of that tax without changing the reviewer experience. The reviewer still clicks a live URL; the difference is that the compute only runs when someone is actually looking, not during the hours the PR sat in a queue. The cost chart below shows how much the idle-wait case adds, and how far a managed runner with scale-to-zero pulls the per-environment cost back down.

Transient provisioning failures quietly double spin-up time

Environment provisioning is a chain of network-bound steps: registry pulls, package installs, and migrations run against a fresh database. Any one of those steps can fail transiently, and because they run in sequence, a single failed step partway through forces a full re-provision from the start rather than a resume.

A single flaky step therefore doubles the reviewer wait for that PR, because the whole spin-up runs again. This is worse than the equivalent failure in plain CI, where a re-run is annoying but expected, because here a human reviewer is blocked on the live URL and experiences the doubled wait directly as friction in their review.

Most of these failures are mechanical and pass on a clean retry: a registry blip, a transient network error, a migration that raced a not-yet-ready database. Automated recovery at the runner layer retries the failed step on a fresh environment rather than failing the whole provision, which matters as much for environments as it does for plain CI precisely because a blocked reviewer is more expensive than a blocked pipeline. Healing transient failures keeps reviewers from waiting twice and helps hold change-confidence in the elite 0-15% band by keeping infrastructure noise out of the review signal.

Spin-up time scales with stack shape, and so does the right strategy

Spin-up time varies sharply by application shape, from a couple of minutes for a static site or single-page app to many times that for a microservices stack or a heavy-fixture data application. The shape of the stack, not the size of the team, sets the spin-up cost, which is why two organizations of identical headcount can have wildly different per-PR environment economics.

The strategy has to match the shape. A static or SPA preview is cheap enough to provision eagerly on every PR; a heavy microservices stack with large data fixtures is expensive enough that eager provisioning on every PR wastes compute on environments no one clicks. For the heavy shapes, lazy provisioning on first reviewer click and aggressive fixture caching are what keep the pattern affordable.

Fixture and seed cost is the lever teams most often overlook on the heavy shapes. Data seeding and migrations are a substantial slice of the spin-up, and a heavy fixture set re-seeded from scratch on every environment is the equivalent of an uncached dependency install: repeated work that a snapshot or a cached seed would eliminate. The spin-up chart below shows how steeply the timeline grows with stack complexity, which is the same axis along which the provisioning strategy should change.

Lazy provisioning beats eager provisioning at PR volume

The default per-PR pattern provisions an environment eagerly the moment a PR opens, but a large share of PRs are reviewed late, merged on green CI without anyone clicking the preview, or abandoned. Eager provisioning pays the full spin-up and idle cost for every one of those environments, including the many that no reviewer ever opens.

Lazy provisioning inverts this: the environment is prepared only when a reviewer actually requests it, typically on first click of the preview link. This concentrates the compute on the environments that are actually used and removes the cost of the ones that are not, which at high PR volume is a large fraction of the total. The reviewer experience is nearly identical, a brief wait on first click rather than a link that was warm but unused.

Lazy provisioning composes with the other levers rather than competing with them. Warm runner capacity makes the first-click wait short, fixture caching makes the seed step fast, and scale-to-zero handles the idle period after the reviewer finishes. Together these turn the per-PR environment from a fixed cost per PR into a cost that tracks actual review activity, which is the right shape for a line item that otherwise scales with raw PR volume.

The managed-runner inflection point for environments

Provisioning environments on hosted runners means paying hosted per-minute rates for work that is mostly idle and bursty, which is the worst possible workload shape for a fixed hosted rate. The bursty spin-up wants elastic capacity, and the idle wait wants scale-to-zero, neither of which a hosted per-minute model provides well.

Managed runners capture most of the compute savings, modeled near 69% lower runner cost, while warm capacity cuts the cold-start slice that reviewers feel most. The two benefits hit the two dominant costs directly: the lower rate attacks the per-spin-up compute cost, and the warm capacity attacks the cold-start wait, which is the largest slice of spin-up time.

For teams running per-PR environments at volume, that combination changes the break-even math in favor of managed, and the case strengthens as the cost levers compound. Lower per-minute cost, warm cold-start, scale-to-zero on idle, lazy provisioning, and self-healing of transient failures all point at the same managed, demand-scaled runner layer. The cost chart below shows the managed case well below every hosted case, including and especially the hosted-plus-idle-wait case that the idle tax produces.

• Bursty spin-up plus long idle is the worst workload shape for a fixed hosted per-minute rate.
• Managed runners model near 69% lower cost while warm capacity cuts the cold-start wait.
• Lower rate, warm start, scale-to-zero, lazy provisioning, and self-healing converge on one runner layer.

Recommendations

Tie environment lifecycle to the PR state webhook

Drive tear-down from the PR close and merge webhook so an environment is never orphaned by a less-salient close event, and set a hard idle TTL as a backstop for abandoned PRs that never formally close. Orphaned stacks are the most common source of surprise cloud spend on repos that adopt ephemeral environments, and the fix is mechanical rather than cultural.

Warm the cold-start path, not the application boot

The dominant slice of spin-up time is image pull and cold start before any application code runs, so invest in warm runner capacity, fast dependency caches, and pre-pulled base images rather than micro-optimizing app startup. Warming the infrastructure removes the largest slice of the reviewer wait, which is the slice reviewers actually feel.

Scale to zero on idle to remove the hidden idle-wait tax

An environment that sits live for hours awaiting review can cost more than its own spin-up. Scale the environment to zero when idle so compute only runs while a reviewer is actually looking, which removes the idle-wait tax without changing the reviewer experience of clicking a live URL.

Provision lazily and match strategy to stack shape

For heavy microservices and large-fixture stacks, provision on first reviewer click rather than eagerly on every PR, since a large share of PRs are merged or abandoned without anyone opening the preview. Cache fixtures and seed data so the data-seed slice does not re-run from scratch each time, and reserve eager provisioning for cheap static and SPA previews.

Auto-heal transient provisioning failures

Provisioning is a chain of network-bound steps where one transient failure forces a full re-provision and doubles the reviewer wait. Retry the failed step on a fresh environment automatically so a registry blip or a migration race does not make a blocked reviewer wait twice, keeping infrastructure noise out of the review signal.

Outlook

Expect per-PR environments to keep moving toward a usage-shaped cost model through 2026. As lazy provisioning and scale-to-zero become standard rather than advanced, the cost of the pattern will increasingly track actual review activity instead of raw PR volume, which is what makes it sustainable for high-throughput repositories. The teams still provisioning eagerly and tearing down by hand will feel the divergence as their cloud bill grows faster than their review activity.

The infrastructure direction is toward warm, elastic, self-healing capacity as the default substrate for previews. Because the dominant spin-up cost is cold start and the dominant standing cost is idle wait, both infrastructure properties, the environments that feel fast and cost little will be the ones running on a managed, demand-scaled runner layer rather than on fixed-rate hosted runners. The application itself moves very little of the number.

For most teams the practical takeaway is that ephemeral environments do not need a dedicated platform team to run affordably. They need lifecycle tied to PR state, a warm cold-start path, scale-to-zero on idle, lazy provisioning matched to stack shape, and automated recovery for transient failures. The teams that adopt those mechanical controls get the review-quality benefit of real preview URLs without the surprise bill, while their peers keep paying for orphaned stacks and idle waits they cannot see.

Methodology

This report synthesizes publicly available industry data (developer surveys, published cloud and CI runner pricing) with Latchkey's own analysis of ephemeral-environment provisioning economics. Per-PR adoption rates, spin-up times, and the spin-up split are modeled estimates derived from typical stack shapes and published runner pricing (Linux at $0.008/min, managed at $0.0025/min), intended to show direction and magnitude rather than precise population values, not a primary survey. 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
• CNCF Annual Survey
• GitHub Actions - billing & pricing
• GitHub Actions documentation

More Latchkey reports