Guide
Dev, QA, staging, preview and production environments
By Muhammad Soliman, Founder at SeaGit · Verified September 2026
An environment is a complete, running copy of your application and the infrastructure it needs, kept separate from the others so that work in one cannot break another. The conventional ladder runs: development, on a laptop or a shared dev cluster, where the code changes constantly and nothing is guaranteed; QA or test, where a build is verified deliberately, often with seeded data; staging, which is meant to resemble production closely enough that a release passing there is expected to pass in production; preview or ephemeral environments, created per branch or pull request and destroyed when it merges; and production, the one real users reach. The distinction that matters is not the name but the guarantee: who is allowed to break it, what data it holds, and whether a passing test there tells you anything about production. An environment that differs from production in an important way gives you false confidence, which is worse than no environment.
Below is what each one is for, the mistake teams usually make with it, and where ephemeral environments replace the older model.
1. Development
Where code is written and run, on a developer machine or a shared development cluster. Expected to be broken at any moment.
- Best for
- Fast feedback. Nothing here needs to be stable, and trying to make it stable slows everyone down.
- Not for you if
- It differs from production the most, so "works on my machine" tells you little. Container images and a real cluster narrow the gap.
- Pricing model
- Usually the cheapest environment: small nodes, scaled down or powered off outside working hours.
2. QA / test
A deliberately controlled environment where a specific build is verified, often against seeded or anonymised data.
- Best for
- Repeatable verification — regression suites, manual test passes, and anything needing known data.
- Not for you if
- Becomes a queue. One shared QA environment means one team waiting for another, which is the problem ephemeral environments solve.
- Pricing model
- Moderate. Often the first candidate for scheduled shutdown outside test cycles.
3. Staging
A near-production environment used as the final gate before release: same topology, same configuration shape, ideally the same infrastructure.
- Best for
- Catching the failures that only appear with production-like data volume, networking and configuration.
- Not for you if
- Drifts. Every difference that creeps in — a smaller database, a missing add-on, different DNS — quietly reduces what a passing run proves.
- Pricing model
- The most expensive non-production environment, precisely because resembling production costs what production costs.
4. Preview / ephemeral
A temporary environment created automatically for a branch or pull request, on its own URL, destroyed when the work merges.
- Best for
- Reviewing a change as a running application rather than as a diff, without competing for a shared environment.
- Not for you if
- Only as useful as it is production-like, and it needs automation to create and destroy reliably — otherwise you accumulate orphans that cost money.
- Pricing model
- Cheap individually, meaningful in aggregate. Limits per environment and automatic teardown are what keep the bill sane.
5. Production
The environment real users reach, holding real data. The only one whose uptime is a promise.
- Best for
- Serving users. Nothing else.
- Not for you if
- Every safeguard you want — rollbacks, progressive delivery, alerting — has to exist before you need it, not after.
- Pricing model
- Sized for real traffic, and the one place where saving money by under-provisioning is a false economy.
Vendor descriptions and pricing models were checked against each vendor's public site as of September 2026. Prices and limits change; the links above go to the current pages.
Read next
Frequently asked
What is the difference between staging and production?
- Production serves real users and holds real data; staging is a rehearsal of it. The useful test of a staging environment is whether a release passing there reliably passes in production. If it does not, the environments differ in a way that matters and the gap is worth closing — otherwise staging is providing confidence it has not earned.
Do I still need staging if I have preview environments?
- Often yes, but for a narrower job. Preview environments catch "does this change work" per pull request. Staging catches "does the whole system work together at production-like scale" before a release. Teams with strong ephemeral environments and good production safeguards sometimes drop staging deliberately; teams that drop it by accident usually notice during an incident.
How many environments should a small team have?
- Production, plus one shared non-production environment, plus ephemeral environments per pull request is enough for most small teams. That gives every change its own place to be reviewed without maintaining a ladder of long-lived environments that all drift from production in different ways.
How do I keep non-production environments from costing as much as production?
- Scale them down and turn them off when nobody is using them. Scheduled automation that powers non-production clusters off overnight and at weekends removes most of the bill, and ephemeral environments that destroy themselves on merge prevent the slow accumulation of forgotten deployments.