Ephemeral environment
An ephemeral environment is a short-lived, on-demand copy of an application and its supporting services, created for a specific purpose such as one change or one test run and destroyed when that purpose ends. Teams create them with scripted infrastructure so that nobody has to queue for a shared test environment or clean one up afterwards.
The longer version
The class is defined by its lifecycle, not by what it contains. Something requests the environment, usually a pull request or a pipeline stage. Scripts build the application, provision a database and its backing services, load seed data and return an address. When the work is done, the environment is torn down, either by an event such as a merge or by a time limit. A preview environment is the common instance, one for each pull request and meant for people to review. Others are built for a test run alone and live only for minutes, with nobody ever visiting them.
The gain over a long-lived shared environment is isolation. Two changes cannot corrupt each other's data, a failing test leaves nothing behind, and a tester gets the same clean state on every run. Cost follows use, because an environment that exists only while needed is billed only then, as long as the teardown actually runs. Orphaned environments left behind by a failed cleanup are the usual leak, which is why they carry a time limit or an owner tag. Making one is the harder part: a full copy of a large system takes time and money to start, third-party services have to be mocked or given sandbox accounts, and seed data has to be realistic without being real customer data.
Over the life of one pull request that changes a billing page, the pipeline builds the branch, starts a database seeded with a few fixture customers, points payments at the provider's sandbox and posts the address. The reviewer approves, the merge triggers teardown, and nothing is left running. What the example leaves out is production's scale and configuration, and a pass in the copy proves nothing about behaviour that depends on them; staging is where that gets checked.
Common questions
What is an ephemeral environment?
An ephemeral environment is a temporary, automatically created copy of an application and its dependencies, built for one change or test run and deleted afterwards. It exists only as long as it is needed, which removes the queue for shared environments and the clutter that long-lived ones collect.
Is a preview environment an ephemeral environment?
A preview environment is one kind of ephemeral environment, created for each pull request so people can review a change at a live address. The wider class also covers environments built for automated test runs or experiments, which nobody opens in a browser. See the preview environment entry for the review case.
How are ephemeral environments created?
A pipeline or a platform creates one from scripted definitions, such as container manifests or infrastructure-as-code templates. A trigger like opening a pull request starts the build, provisioning and seeding, and a second trigger such as a merge, a close or a timeout destroys it.
Why use ephemeral environments instead of a shared staging environment?
A shared staging environment can hold only one set of changes at a time, so testers queue and one team's bad data affects another. An ephemeral environment gives each change its own isolated copy, which lets reviews and tests run in parallel and start from a known state.
What are the downsides of ephemeral environments?
Good automation is a prerequisite, large systems take time and money to start, and third-party services must be mocked or sandboxed. Cost can also leak if teardown fails. Since each is a reduced copy, a pass in one does not replace a check on production-shaped infrastructure.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.