Picture a team with one shared staging environment. Three developers deploy their branches to it on the same afternoon, one breaks the database, and nobody can tell whose change caused the bug. QA waits, product managers wait, and releases slow down.
Ephemeral environments fix this bottleneck. Instead of sharing one long-lived staging server, every pull request gets its own short-lived, production-like environment that is created automatically and deleted when the work is done. This guide explains how they work, how to build them, and how to keep them affordable.
What Is an Ephemeral Environment?
An ephemeral environment (also called a preview environment, review app or on-demand environment) is a temporary, isolated copy of your application and its dependencies. It is usually created automatically when a pull request is opened, updated with each new commit, and destroyed when the pull request is merged or closed.
Each environment gets a unique URL, for example a subdomain based on the pull request number, so developers, testers, designers and product managers can review a change in a running system before it is merged.
Ephemeral vs Persistent Environments
- Lifespan: persistent environments such as staging run continuously; ephemeral ones live for hours or days.
- Ownership: persistent environments are shared by everyone; ephemeral ones belong to a single change.
- Drift: long-lived environments slowly drift from production through manual fixes; ephemeral ones are rebuilt from code every time.
- Contention: shared environments create queues and conflicts; ephemeral environments let work proceed in parallel.
Most teams still keep a staging or pre-production environment for final integration and performance checks. Ephemeral environments reduce how much depends on it.
Benefits of Ephemeral Environments
- Faster feedback: reviewers see the real change running, not just a code diff.
- Parallel development: no waiting in line for a shared environment.
- Fewer "works on my machine" problems: every change runs in a consistent, production-like setup.
- Better testing: end-to-end, integration and visual tests run against an isolated environment, with no interference from other changes.
- Earlier involvement for non-engineers: designers and product managers can click through features before merge.
- Reliable infrastructure code: because environments are created from scratch constantly, broken automation is noticed immediately.
These benefits directly improve lead time for changes and change failure rate, two of the key DORA metrics.
How Ephemeral Environments Work
- Trigger: a developer opens or updates a pull request.
- Build: the CI pipeline builds container images tagged with the commit.
- Provision: the pipeline creates an isolated environment, often a Kubernetes namespace, plus any required infrastructure.
- Deploy: the application and its dependencies are deployed using the same manifests or charts as production.
- Seed data: a database is created and filled with safe test or anonymised data.
- Publish: a unique URL is posted back to the pull request as a comment or status check.
- Test: automated tests run against the environment and people review it.
- Tear down: when the pull request is merged or closed, or after a period of inactivity, everything is deleted.
This flow works with any CI system. See GitHub CI/CD and GitLab CI/CD; GitLab calls these "review apps" and has built-in support for them.
Building Blocks and Tools
Infrastructure as Code
Every environment must be reproducible from code. Tools like Terraform, OpenTofu or Pulumi provision cloud resources, while Kubernetes manifests or Helm charts describe the application. Start with what is Infrastructure as Code and how to write reusable Terraform modules.
Kubernetes namespaces
Namespaces are the most common way to isolate preview environments on a shared cluster. Each pull request gets its own namespace with resource quotas and network policies. Helm makes it easy to deploy the same chart with per-environment values.
GitOps controllers
Argo CD's ApplicationSet with the Pull Request generator can create and delete an application automatically for each open pull request. Read what is GitOps to understand this approach.
Platform and hosted options
Front-end platforms like Vercel and Netlify provide preview deployments out of the box. Tools such as Bunnyshell, Uffizzi, Release, Okteto and Qovery specialise in full-stack preview environments. Internal platform teams often expose them through a golden path so every service gets previews by default.
Handling Databases and Dependencies
Data is usually the hardest part. Common options include:
- Fresh database with seed data: simplest and safest, created from migrations and a seed script.
- Database branching: services like Neon and PlanetScale can create a copy-on-write branch of a database in seconds.
- Snapshots of anonymised data: restored from a sanitised copy of production for realistic testing.
Never copy raw production data containing personal information into preview environments. For external services like payment providers or email, use sandbox accounts or mocks. For large microservice systems, deploy only the changed services and route other calls to a shared baseline environment.
Keeping Costs Under Control
Dozens of environments running at once can get expensive quickly. Apply FinOps practices from the start:
- Destroy environments automatically on merge, close, or after a set period of inactivity.
- Scale environments to zero at night and at weekends.
- Use small resource requests and quotas per namespace.
- Share expensive components, such as a cluster or a managed database server, while isolating at the namespace or database level.
- Run preview workloads on spot or preemptible nodes.
- Tag every resource with the pull request and team so costs are visible.
Security Considerations
- Protect preview URLs with authentication or an IP allow-list; they often expose unreleased features.
- Use separate, low-privilege credentials for preview environments, never production secrets. See secrets management in DevOps.
- Be careful with pull requests from forks, which should not automatically receive access to secrets or cloud credentials.
- Apply network policies so preview namespaces cannot reach production systems.
Common Challenges
- Slow creation: if an environment takes 30 minutes to start, people stop using it. Cache images and pre-warm shared components. Our guide on speeding up slow CI/CD pipelines helps here.
- Orphaned resources: failed teardowns leave forgotten resources running. Add a scheduled cleanup job.
- Parity gaps: previews that differ too much from production give false confidence. Use the same images, charts and configuration patterns.
Conclusion
Ephemeral environments give every change its own production-like home, removing the shared-staging bottleneck and bringing feedback forward to the pull request. With Infrastructure as Code, Kubernetes namespaces and automation in your pipeline, they are achievable for most teams. Start with a single service, automate cleanup and cost controls from day one, and expand once the workflow proves its value. They are also a natural feature of self-service infrastructure.
