How do ephemeral environments reduce infrastructure costs?
- Persistent environments accumulate infrastructure costs even when nobody is using them. Idle compute, overprovisioned resources, and environments that are left running after work is complete all contribute to unnecessary spend.
- Ephemeral environments reduce this waste by provisioning infrastructure on demand and automatically managing its lifecycle. TTLs, automatic teardown, scale-to-zero, database forking, and path filters can further reduce resource usage.
- Northflank provides full-stack ephemeral environments with automatic provisioning and teardown, resource controls, database forking, and preview blueprints, so teams can create isolated environments for each pull request without turning every environment into permanent infrastructure.
What is Northflank? Northflank is a cloud platform for building, deploying, and running applications, with infrastructure for ephemeral environments, managed databases, GPUs, jobs, and more. Run full-stack preview environments on Northflank's managed cloud or in your own cloud account. Get started with Northflank or book a demo.
Most staging environments run continuously. They are provisioned once, sized for peak load, and left running through nights, weekends, and public holidays. The applications deployed on them may be actively used for only a few hours each working day. The rest of the time, compute is running at low utilization, databases are holding connections, and cloud bills are accumulating for work nobody is doing.
Ephemeral environments change the cost model. Instead of maintaining always-on infrastructure, environments are provisioned on demand when a pull request opens and torn down automatically when it closes. This reduces compute costs by aligning infrastructure usage with the time a workload is actually active, rather than keeping resources running while an environment sits idle.
An ephemeral environment is a short-lived, isolated environment provisioned on demand for a specific purpose and automatically destroyed when that work is complete. In a development workflow, the most common example is a preview environment: a complete deployment of an application created when a pull request opens, used for testing and review, and torn down when the PR merges or closes.
Ephemeral environments differ from persistent environments such as staging and QA because they are designed to be temporary from the start. They are not intended to accumulate state, require ongoing maintenance, or keep running when nobody is using them. The lifecycle is simple: create, use, destroy. The cost follows the same lifecycle, with resources available when they are needed and released when they are not.
The cost difference between ephemeral and persistent environments is not primarily about the compute rate per hour. It is about how long the infrastructure actually runs and how much of that time it is being used.
A persistent staging environment can consume compute, memory, database, and storage resources continuously, even when nobody is using it. An ephemeral environment ties those resources to a specific workload, allowing teams to provision them when needed and remove them when the work is complete.
| Cost factor | Persistent environment | Ephemeral environment |
|---|---|---|
| Idle compute | Runs continuously, including nights and weekends | Runs only while the environment is needed |
| Database costs | Database remains provisioned continuously | Database can be created or forked for the environment and removed when it is no longer needed |
| Orphaned resources | Resources can remain after a branch or test is abandoned | Automatic teardown or TTLs can remove unused environments |
| Overprovisioning | Resources are often sized for a broad range of workloads | Resources can be right-sized for each environment |
| Concurrent environments | Teams may share a small number of persistent environments | Each PR or workload can have its own environment when required |
The key difference is simple: persistent environments pay continuously, while ephemeral environments can release resources when the workload is finished. The more time an environment would otherwise spend idle, the greater the potential for cost savings.
Ephemeral environments reduce infrastructure costs by controlling how long resources run, how much capacity they use, and when they are removed. The key controls are automatic teardown, TTLs, scale to zero, database forking, and selective builds.
- Automatic teardown on PR close: When a pull request is merged or closed, its environment can be torn down automatically. This releases compute, databases, storage, and other resources without requiring manual cleanup. It also prevents resources from continuing to run after the work they were created for is finished.
- TTLs and auto expiry: A time to live (TTL) puts a maximum lifetime on an environment. This is useful for long-running pull requests, temporary test environments, and abandoned branches where the normal teardown trigger may not happen. Once the TTL is reached, the environment can be automatically removed.
- Scale to zero: Not every environment needs to be running at full capacity all the time. Services that are not receiving traffic can scale to zero, reducing compute usage while keeping the environment configuration available to start again when needed. This can be useful for preview environments that remain open but are only accessed occasionally.
- Database forking: Instead of maintaining a separate full-size database for every environment, teams can create isolated database forks for testing. These can be based on existing database data and removed when the environment is torn down, reducing the resources required to maintain persistent database copies.
- Path filters and selective builds: In a monorepo, a pull request may change only a small part of the application. Path filters can limit builds and deployments to the services affected by those changes, avoiding unnecessary build and compute usage for unrelated services.
Ephemeral environments can reduce infrastructure costs, but they are not automatically cheaper in every configuration. The cost depends on how much infrastructure each environment provisions and how long it runs. The main trade-offs are fidelity, startup time, and isolation.
- Fidelity vs cost: A full fidelity environment can run every service the application depends on and use a realistic database, making it useful for testing complex changes. A lighter environment can use fewer services, smaller resources, or seeded test data to reduce cost and start faster. The right level of fidelity depends on what the pull request changes. A frontend change may not need the same infrastructure as a database migration or backend change.
- Startup time vs cost: Larger environments, more services, large container images, and database restoration can increase the time it takes to provision an environment. Prebuilt images, caching, smaller resources, and selective builds can reduce this overhead. Teams need to balance how quickly an environment becomes available with how much infrastructure they provision.
- Isolation vs cost: Giving every pull request its own services, database, and supporting infrastructure provides stronger isolation but also requires more resources. Sharing some resources can reduce costs, but introduces dependencies between environments. The right level of isolation depends on the workload and what needs to be tested independently.
- AI-generated PR volume: AI coding agents can increase the number of pull requests and temporary environments a team creates. At higher volumes, the cost of each environment becomes more important. Controls such as TTLs, automatic teardown, selective builds, scale to zero, and different environment configurations can help teams manage that growth without keeping every environment running at full capacity.
Northflank provisions full-stack preview environments for pull requests and branches using preview blueprints. A blueprint defines the resources that should be created for each environment, including services, databases, jobs, volumes, and networking. When a preview is created, these resources are provisioned together as an isolated environment, and they can be removed automatically when the preview is no longer needed.
- Automatic cleanup: Northflank can automatically delete preview environments when the associated pull request closes, or its branch is deleted. When a preview is deleted, its services, databases, volumes, and other resources are removed with it. This prevents resources from remaining active after the development work is complete.
- Preview expiry: Preview blueprints support automatic expiry after a configured lifetime. The expiry timer can also be reset when the preview is updated, allowing active environments to remain available while still putting a limit on how long unused previews can exist.
- Teardown schedules: Preview environments can be configured to shut down during periods when they are not needed, such as nights and weekends. This is useful when teams want to keep previews available without running their full infrastructure continuously.
- Right-sized resources: Preview environments do not need to use the same resource plans as production. Northflank recommends using smaller resource plans for previews where appropriate, allowing teams to match CPU and memory allocation to the workload being tested rather than provisioning production-sized infrastructure for every pull request.
- Database isolation: Databases can be included directly in Preview Blueprints, so each preview environment can have its own isolated database alongside the application services. The database is then removed when the preview is deleted. Northflank supports multiple database types for this model, including PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ.
- Path filters and selective builds: Northflank supports per-service path filters that determine which file changes should trigger a build. In a monorepo, this means a pull request that changes one service does not need to rebuild unrelated services, reducing both preview creation time and build compute.
- Concurrency controls: Teams can also limit the number of concurrent preview environments. This provides another layer of cost control when a repository has many open pull requests or generates previews frequently.
- Bring Your Own Cloud (BYOC): With Northflank BYOC, preview environments can run in your own cloud account, with support for providers including AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. Existing Kubernetes infrastructure, including on-premises and bare-metal environments, can be connected through BYOK.
Together, these controls let teams decide how much infrastructure each ephemeral environment should use and how long it should exist. The result is not simply a temporary copy of staging, but an environment with a defined lifecycle and resource policy.
Ephemeral environments can reduce infrastructure costs by tying resource usage to actual development work instead of keeping staging infrastructure running continuously. Automatic teardown, TTLs, right-sized resources, selective builds, and database isolation help limit how much infrastructure each environment consumes and how long it remains active. The goal is not simply to make environments temporary, but to give each environment a lifecycle that matches the work it supports.
Northflank provides full-stack ephemeral environments with the controls needed to manage that lifecycle. Teams can automatically create isolated environments for pull requests, right-size their resources, set expiry and teardown schedules, and clean up environments when they are no longer needed.
Start building ephemeral environments with Northflank to reduce wasted infrastructure while keeping every pull request isolated and ready to test, or book a demo to see how Northflank can fit into your development workflow.
An ephemeral environment is a short-lived, isolated infrastructure environment that is provisioned on demand for a specific purpose and removed when that work is complete. In a development workflow, the most common example is a preview environment created for a pull request and removed when the pull request closes.
Persistent staging environments continue running even when nobody is actively using them. Compute, databases, storage, and other resources can remain provisioned during nights, weekends, and periods of low activity. Resources can also remain active after they are no longer needed if they are not cleaned up manually.
There is no fixed percentage because the savings depend on how the existing infrastructure is used. The biggest opportunity usually comes from environments that spend significant amounts of time idle. Provisioning resources only when they are needed, right-sizing them for the workload, and removing them automatically can reduce the amount of infrastructure that remains active without being used.
Automatic teardown removes an environment when a specific event occurs, such as when a pull request is merged or closed. A TTL, or time to live, sets a maximum lifetime for an environment regardless of whether that event occurs. Using both provides a normal cleanup mechanism for completed work and a safety net for environments that remain open longer than expected.
Not necessarily. Ephemeral environments can reduce costs by running infrastructure for less time and by allowing resources to be sized for specific workloads, but a full fidelity environment with many services and databases can still consume significant resources. The cost advantage comes from combining ephemeral environments with lifecycle and resource controls such as automatic teardown, TTLs, right-sizing, selective builds, and database isolation.
