An ephemeral environment is a short-lived, isolated deployment of an app, usually created per pull request. The right answer is per-PR previews for a team that wants to test before merge (a full-stack app, a team that does manual QA), the wrong answer is per-PR previews for a team that has 200 PRs and a tight budget. The right answer for the cost is to share the database across previews, the right answer for the speed is to cache the build.
Table of contents
- The PR-preview pattern — the right answer for a team that wants to test before merge
- The on-demand spin-up — the right answer for a one-off test
- The cost — the deployment, the database, the storage
- The speed — the build, the deploy, the warm-up
- The platform options — Render, Fly, Vercel, Shipyard, Northflank
- The one that actually saves you money
- How this fits the rest of the stack
- FAQ
The PR-preview pattern — the right answer for a team that wants to test before merge
The PR-preview pattern is the standard use case for an ephemeral environment. Every pull request gets a unique URL, the URL is deployed automatically, the team (or the reviewer) can click the URL and test the change. The right answer is PR previews for a team that wants to test before merge, a team that does manual QA, a team that has a full-stack app (the frontend and the backend both change).
The gotcha: the PR preview is a real deployment, it costs real money, the team that has 200 open PRs has 200 deployments. The right answer is to set a TTL on the preview (the preview is destroyed after 7 days, the team’s cost is bounded).
The on-demand spin-up — the right answer for a one-off test
The on-demand spin-up is for a team that wants to test a specific branch without creating a PR. The right answer is the on-demand pattern for a team that wants to test a feature branch before opening the PR, a team that wants to test a fix in a production-like environment.
The cost — the deployment, the database, the storage
The cost of an ephemeral environment is the deployment (the running service), the database (a Postgres per preview, or a shared one), the storage (any persistent data). The right answer for the cost is to share the database across previews (the team’s data is reset between PRs, the team’s Postgres is one), the right answer for the deployment is to spin down the preview when it’s not in use (the preview is suspended after 30 minutes of inactivity).
The wrong answer is one Postgres per preview. The team’s cost is multiplied by the number of PRs, the team’s database is fragmented, the team has migration drift. The right answer is one shared Postgres with reset-on-PR-merge, the right answer for sensitive data is a per-PR Postgres with anonymized data.
The speed — the build, the deploy, the warm-up
The speed of an ephemeral environment is the build time, the deploy time, the warm-up time (the first request is slow). The right answer for the build is to cache the dependencies (Docker layer cache, npm cache), the right answer for the deploy is to use a fast platform (Fly, Render), the right answer for the warm-up is to add a health check that hits the preview on creation.
The platform options — Render, Fly, Vercel, Shipyard, Northflank
The right answer for a managed platform is Render (the preview environment), Fly (the apps per branch), Vercel (the preview deployment), Shipyard (the ephemeral environment), Northflank (the preview environment). The right answer is the platform that the team’s main app is on, the wrong answer is to add a new platform just for previews.
The one that actually saves you money
The one that saves money is the platform that reuses the build cache, shares the database, and suspends the preview when not in use. The right answer is Render or Fly for a team that has 10-50 open PRs (the cost is bounded, the previews are useful), the wrong answer is Vercel for a team that has 200 open PRs (the cost is not bounded, the team is paying for inactive previews).
The right answer is to set a TTL (7 days is the standard) and to have the preview destroyed on PR close. The wrong answer is to have the preview live forever (the team is paying for a deployment that no one is using).
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is an ephemeral environment?
A short-lived, isolated deployment of an app, usually created per pull request.
How do I create an ephemeral environment?
Use a platform that supports previews (Render, Fly, Vercel, Shipyard, Northflank). The right answer is the platform that the team’s main app is on.
How much does an ephemeral environment cost?
The deployment, the database, the storage. The right answer is to share the database across previews, the right answer for the deployment is to spin down the preview when not in use.
Should I have one Postgres per preview?
No — share the database across previews, reset the data on PR merge. The right answer for sensitive data is a per-PR Postgres with anonymized data.
How do I set a TTL on the preview?
In the platform’s config (Render: autoDestroy: true, Fly: min_machines_running: 0). The right answer is to set a TTL of 7 days.
What is the right platform for ephemeral environments?
Render, Fly, Vercel, Shipyard, Northflank. The right answer is the platform that the team’s main app is on.
Can I use ephemeral environments for production?
No — the right answer is a permanent environment for production, an ephemeral for the PR preview. The wrong answer is to spin down the production environment to save money.
How do I share the database across previews?
Use one shared Postgres, reset the data on PR merge. The right answer is a migration tool that drops and recreates the schema on PR merge.