Preview environment cost per pull request, measured properly
Preview environments are worth paying for, but most teams have never calculated the per pull request price. The number depends far more on lifespan and shared infrastructure than on the workload itself. Here is the arithmetic and the levers that move it.
Quick answer
Preview environment cost per pull request is the hourly cost of the environment multiplied by its lifespan, plus a share of the always-on infrastructure behind it. A dedicated stack at about 0.28 dollars per hour living 3 days costs roughly 20 dollars per pull request, while a namespace on a shared cluster with scale to zero can land near 1 to 3 dollars. The levers that matter are lifespan, sharing expensive singletons, and scaling to zero between pushes, not shaving instance sizes.
Preview environments earn their keep. Reviewers click a link instead of pulling a branch, product managers check behavior before merge, and integration problems surface days earlier. The question is never whether to have them, it is what each one costs and which design choices drive that number.
Most teams cannot answer it, because preview cost hides inside a shared cluster bill or a general non-production account. Working the arithmetic out explicitly usually reveals that the expensive part is not what anybody assumed.
The formula
Cost per pull request equals hourly cost of the dedicated resources multiplied by hours alive, plus the pull request's share of always-on supporting infrastructure. The second term is the one people forget, and on smaller teams it dominates.
| Design | Hourly | 3 day lifespan | 150 pull requests a month |
|---|---|---|---|
| Dedicated stack per pull request | About 0.28 dollars | About 20 dollars | About 3,000 dollars |
| Namespace on shared cluster | About 0.04 dollars | About 2.90 dollars | About 435 dollars |
| Shared cluster, scale to zero idle | About 0.04 dollars active only | About 0.90 dollars | About 135 dollars |
| Serverless containers, request billed | Near zero idle | Under 1 dollar | Under 150 dollars |
The dedicated row assumes its own small database, two nodes, a load balancer, and a NAT gateway share. The shared rows assume the cluster, ingress, and egress path already exist for other reasons and the preview adds only pods and a small logical database.
Lifespan is the biggest multiplier
A preview environment that is deleted on merge lives for the review time of the pull request, commonly 1 to 4 days. One that is deleted by a nightly sweep of closed pull requests lives a day longer on average. One with no cleanup lives forever and stops being a preview environment at all.
Hooking deletion to the pull request closed webhook, rather than to a schedule, typically cuts total preview spend by 20 to 40 percent on its own. Keep a backstop sweep for abandoned branches, say 7 days with no push, but the webhook should be doing most of the work.
Idle time is most of the lifespan
A preview environment alive for 72 hours is genuinely used for maybe 30 minutes. Everything else is idle compute waiting for a reviewer to click a link. That makes scale to zero the second big lever.
Scaling deployments to zero after 30 minutes of no traffic, with an ingress that wakes them on the first request, converts 72 billable hours into roughly 2. The tradeoff is a cold start of a few seconds on the first click, which reviewers tolerate easily. For stateless services this is usually straightforward, and the same reasoning drivesscheduled scaling for dev environments.
Share the expensive singletons
The items that make dedicated previews expensive are almost never the application containers. They are the load balancer, the NAT gateway, the managed database instance, and the cluster control plane. Each is a fixed monthly charge that does not care how small the workload is.
Share all of them. One ingress controller with host based routing serves hundreds of previews from a single load balancer. One database instance hosts a schema or logical database per pull request instead of an instance per pull request, which alone often takes 25 to 60 dollars per preview down to cents. One NAT gateway or, better, VPC endpoints serve the whole cluster.
Watch the data seeding bill
Cost that surprises teams in preview environments usually comes from data, not compute. Restoring a 200 GB production snapshot into every preview means storage charges per environment plus the cross-AZ or cross-region transfer to move it. At 150 pull requests a month that gets expensive quickly and it is slow.
Use a small curated seed dataset, a few hundred megabytes of representative rows, or copy on write clones where the database supports them. Reviewers almost never need full production volume, and the ones who do can request a heavier environment explicitly.
Put the number in the pull request
Since preview environments are created from Terraform or a Helm chart backed by Terraform, you can estimate their cost before they exist. c3x prices the plan statically with no cloud credentials and posts the result as a pull request comment, so the same comment that links to the preview can carry its estimated cost.
That matters most when a pull request changes the preview template itself. A change that adds a dedicated cache to every preview is a 150 pull requests a month decision, not a single environment decision, and seeing the per environment delta in the review is what prevents it from being discovered later. Combine that with webhook driven deletion, scale to zero, shared singletons, and light seed data, and preview environments settle into single digit dollars per pull request, which is a price nobody argues with.
FAQ
How much does a preview environment cost per pull request?
It depends almost entirely on design. A dedicated stack with its own database, nodes, load balancer, and NAT share runs about 0.28 dollars per hour, which is roughly 20 dollars over a 3 day lifespan. A namespace on a shared cluster costs around 2.90 dollars for the same period, and with scale to zero it drops under 1 dollar. At 150 pull requests a month that is the difference between 3,000 dollars and 135 dollars.
What is the biggest driver of preview environment cost?
Lifespan, followed by idle time. Deleting on the pull request closed webhook rather than on a nightly schedule typically cuts total preview spend by 20 to 40 percent. Beyond that, an environment alive 72 hours is genuinely used for maybe 30 minutes, so scaling to zero after 30 minutes of no traffic converts 72 billable hours into about 2.
Should preview environments share infrastructure?
Yes. The expensive parts of a dedicated preview are the load balancer, NAT gateway, managed database instance, and cluster control plane, all fixed charges that ignore workload size. One ingress controller with host based routing serves hundreds of previews from a single load balancer, and one database instance hosting a schema per pull request turns a 25 to 60 dollar per preview charge into cents.
Why are preview environments expensive to seed with data?
Restoring a large production snapshot into every preview adds per environment storage charges plus cross-AZ or cross-region transfer to move the data, and it is slow. At 150 pull requests a month that compounds fast. A few hundred megabytes of curated representative rows, or copy on write clones where the database supports them, covers almost every review without the storage and transfer bill.
Can I see preview environment cost in the pull request itself?
Yes. Preview environments created from Terraform can be priced from the plan before they exist. C3X estimates statically with no cloud credentials and posts the result as a pull request comment, so the comment linking to the preview can also carry its cost. This matters most when a pull request changes the preview template, since that is a decision multiplied across every future pull request.
What to do next
Price your preview environments before they spin up. C3X estimates Terraform cost and comments on the pull request. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.