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.
Key takeaways
- An environment is defined by what it is allowed to break and how closely it matches production. The names matter less than those two properties.
- Staging earns its cost only when it matches production in the ways that change behaviour: versions, configuration, network path and the shape of the data.
- Preview environments created per pull request catch integration problems before merge. They need automatic creation, automatic teardown and a cap on how many run at once.
- Production needs its own gate: protected branches, required reviewers and a rollback path. GitHub environments and most GitOps tools can enforce this.
- Many teams run fewer environments than they think. Two stable environments and per-change previews cover most needs for a small team.
At a glance
| Tool | Best for | Pricing model |
|---|---|---|
| Development | Fast feedback. Nothing here needs to be stable, and trying to make it stable slows everyone down. | Usually the cheapest environment: small nodes, scaled down or powered off outside working hours. |
| QA / test | Repeatable verification — regression suites, manual test passes, and anything needing known data. | Moderate. Often the first candidate for scheduled shutdown outside test cycles. |
| Staging | Catching the failures that only appear with production-like data volume, networking and configuration. | The most expensive non-production environment, precisely because resembling production costs what production costs. |
| Preview / ephemeral | Reviewing a change as a running application rather than as a diff, without competing for a shared environment. | Cheap individually, meaningful in aggregate. Limits per environment and automatic teardown are what keep the bill sane. |
| Production | Serving users. Nothing else. | Sized for real traffic, and the one place where saving money by under-provisioning is a false economy. |
1. Development
Where code is written and run, on a developer machine or a shared development cluster. Expected to be broken at any moment.
- 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.
2. QA / test
A deliberately controlled environment where a specific build is verified, often against seeded or anonymised 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.
3. Staging
A near-production environment used as the final gate before release: same topology, same configuration shape, ideally the same infrastructure.
- 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.
4. Preview / ephemeral
A temporary environment created automatically for a branch or pull request, on its own URL, destroyed when the work merges.
- 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.
5. Production
The environment real users reach, holding real data. The only one whose uptime is a promise.
- Not for you if
- Every safeguard you want — rollbacks, progressive delivery, alerting — has to exist before you need it, not after.
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.
What each environment is for
Development is where individual changes are made and run, often on a laptop or a shared dev cluster. Nothing there is guaranteed. QA or test is where a build is checked on purpose, usually with a known data set and a test plan. Staging is a production-like copy that receives the release candidate and is expected to behave like production. Production is the environment real users depend on. Preview environments are the newer layer: one per branch or pull request, created on demand and removed when the change lands or closes.
The distinction that matters is the guarantee each environment gives. A staging environment that runs an older Kubernetes minor version, a different ingress controller and a database with no migrations applied tells you little about production. A preview that is created from the same manifests as production, with the same image build, tells you a great deal about the change. Write down the guarantee for each environment before you decide how many to keep.
Which differences between staging and production matter
The twelve-factor methodology asks for dev and production to stay as similar as possible, and names three gaps that cause most surprises: the time between writing code and deploying it, the people who write it and who deploy it, and the tools used at each stage. In practice the gaps that hurt are configuration, backing services and data. A staging database that is a small local instance, or a message queue that is absent, can pass every test and still fail in production.
Match the things that change behaviour: the image that is built, the Kubernetes and add-on versions, the network path to dependencies, the feature flags and the shape of the data. Accept differences in scale and in the number of replicas, but record them. A list of known differences is more useful during an incident than a staging environment that everyone assumes is identical.
Production data should not be copied into lower environments without masking. A seeded data set with realistic shapes, generated for the tests, avoids that risk and still exercises queries and migrations. Treat any copy of customer data as production data for access and retention purposes.
Preview environments for each pull request
A preview environment is a full deployment of one change, reachable from a URL, that exists only while the change is open. The GitOps tool Argo CD can generate one Application per open pull request with its ApplicationSet pull request generator. The generator filters by repository, and optionally by label, and it renders the Application from a template using the pull request number and head commit. Removing the pull request removes the Application, and with it the namespace and resources.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: web-previews
namespace: argocd
spec:
goTemplate: true
generators:
- pullRequest:
github:
owner: example-org
repo: web
labels:
- preview
requeueAfterSeconds: 300
template:
metadata:
name: 'web-pr-{{.number}}'
spec:
project: default
source:
repoURL: https://github.com/example-org/web.git
targetRevision: '{{.head_sha}}'
path: deploy
destination:
server: https://kubernetes.default.svc
namespace: 'web-pr-{{.number}}'
syncPolicy:
automated: {}
syncOptions:
- CreateNamespace=truePreviews need limits. Without a cap, a busy repository runs dozens of namespaces that nobody checks, and each holds ingress rules and certificates. Set a maximum, define a time-to-live for idle previews, and make sure teardown removes DNS records and certificates too, not only the workload. A preview whose DNS record outlives it is a small but real leak.
Protecting production
GitHub environments let a workflow deploy to a named environment that can require approval from specific reviewers and can restrict which branches may deploy to it. The GitHub documentation describes the protection rules. Pair that with a rule that production changes come only from the main branch, and a deployment record that names the commit. The result is a production history that answers who approved each change and what it contained.
Plan the rollback before the first deploy. For a container image, rollback is redeploying the previous digest. For a database change, rollback is usually a forward migration, because dropping a column is not reversible. Staging is where you rehearse that path, and it only works if staging has the same migration history as production.
How many environments a team needs
A common setup for a small team is one shared development environment, one staging environment that mirrors production, and production. Preview environments are added per change when the team has automation to create and destroy them. Larger teams split staging by region or by product area, which multiplies cost and drift. Each environment you add needs an owner, a refresh schedule and a way to find out it is broken.
Shared, long-lived environments drift. Nobody owns the configuration that was changed by hand three months ago. If you keep a long-lived staging, rebuild it from the same repository as production on a schedule, and treat a manual change as a defect to be removed.
How to choose a setup
Start with the failure you most want to prevent. If integration bugs reach production, add per-change previews. If configuration differences cause incidents, make staging use the production manifests and secrets path. If releases are rare and high-risk, invest in the promotion gate and the rollback rehearsal. Choose a platform after you know which of these you are solving, because a tool cannot fix a gap in the guarantee.
Where SeaGit fits
SeaGit runs each instance on a set of deployment slots. One slot is the main deployment, and the others are ephemeral preview slots that run on the same cluster and in the same environment, each with its own URL. Slots are limited per environment, and a promotion copies a preview into the main slot. That maps onto the ladder above, with the caveat that the feature is limited to AWS and Amazon EKS today.
Sources
Checked as of October 2026.
- The Twelve-Factor App: Dev/prod parity — the three gaps between development and production
- Argo CD: ApplicationSet Pull Request generator — per-pull-request Applications, filters and template fields
- GitHub Docs: Using environments for deployment — required reviewers and branch restrictions on environments
- Kubernetes: Namespaces — namespace-per-preview isolation and its limits
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.