Dev vs Staging vs Production in GCP

What are dev, staging, and production?

Each environment is a full deployment of your application with its own infrastructure, configuration, and access rules. They share the same codebase but serve very different purposes.

• Development (dev): where developers build and test features. It accepts unstable, frequent deployments and prioritises iteration speed over reliability.
• Staging: a production-like environment used to validate a release before it reaches users. It should be close enough to production to catch realistic problems.
• Production (prod): the live environment serving real users. Every change is deliberate and controlled.

The purpose of separating these environments is blast radius reduction: keeping the consequences of a mistake contained to an environment where mistakes do not matter. A broken dev deployment is a developer problem. A broken staging deployment is a quality gate doing its job. A broken production deployment is a user-facing incident.

Why these environments exist

A change that works in isolation can still fail in production because production has different infrastructure, real data volumes, tighter IAM permissions, and real concurrent users. Each environment is a quality gate that filters out a different class of problem before the next stage.

When a problem is caught in dev, the cost is a code change. When it is caught in staging, the cost is a failed deployment and a fix. When it reaches production, the cost is user impact, potential data problems, and an incident response. Environments exist to move that cost as early in the process as possible.

How it works in a real CI/CD pipeline

In a well-structured pipeline, code flows forward through environments rather than being rebuilt separately for each one.

1. A developer pushes code. Cloud Build runs automated tests and builds a container image.
2. The image is pushed to Artifact Registry and automatically deployed to dev.
3. On merge to the main branch, the same image is promoted to staging. Cloud Deploy manages this promotion and tracks exactly which image version is running in each environment.
4. After staging validation, a human approves the release. Cloud Deploy promotes the exact same image to production.

The critical detail is that the same container image (same digest, same SHA) moves from staging to production. Nothing is rebuilt. This means the artefact users receive in production is identical to the one validated in staging. Rebuilding a new image for production breaks that test-what-you-ship guarantee.

Development environment

Dev exists to give developers a fast feedback loop. It should be cheap, quick to deploy to, and tolerant of instability. A broken dev environment is an inconvenience, not an incident.

Typical dev configuration in GCP

• GCP project: my-app-dev, completely separate from staging and production
• Cloud Run min-instances: 0, scaled to zero between active sessions to save cost
• Cloud Run max-instances: capped low (3 to 5) to prevent cost overruns if something loops
• Database: Cloud SQL on a small tier (db-f1-micro or db-g1-small), populated with synthetic or anonymised test data only
• Deploy trigger: automatic on push to a feature branch, or on merge to main
• IAM: developers have broad access (roles/editor or similar) to investigate issues quickly
• Secrets: dev-specific values in Secret Manager under the dev project, never shared with other environments
• Approvals: none
• Monitoring: optional; no on-call expectations

What dev is good at catching

Dev catches obvious integration errors: does the application start, does it connect to its dependencies, do the core API paths respond correctly. It is not a meaningful proxy for production behaviour. A performance issue that appears under production load will not show up against a micro-tier database with scale-to-zero enabled.

Staging environment

Staging is the most important environment after production. Its value depends entirely on how closely it resembles production. A staging environment that is too small, too loosely configured, or too different in architecture does not catch the problems it is meant to catch. It just adds a step and provides false confidence.

For how to manage environment-specific values without duplicating your pipeline definition, see managing environments in CI/CD.

Typical staging configuration in GCP

• GCP project: my-app-staging, isolated from both dev and production
• Cloud Run min-instances: same as production, or at minimum 1. Not zero.
• Cloud Run max-instances: same as production or a defined fraction
• Cloud Run concurrency: identical to production
• Database: same Cloud SQL tier as production (or one step below), same schema, anonymised production snapshot as data
• Deploy trigger: automatic on merge to main via CI/CD pipeline or Cloud Deploy
• IAM: developers have read access; all changes go through the pipeline
• Secrets: staging-specific values in Secret Manager; see secrets in CI/CD pipelines for per-environment setup
• Approvals: automatic deployment from main; human review required before promoting to production
• Monitoring: full monitoring active; no on-call pager, but alerts should be reviewed

What staging is good at catching

Staging catches problems that only appear with production-like infrastructure: database connection pool exhaustion under realistic query patterns, IAM permission errors invisible in dev (where developers have broad access), Cloud Run cold start times with real image sizes, and memory pressure that only surfaces at production concurrency levels.

Production environment

Production serves real users. Every change is deliberate and traceable. This is the environment where mistakes have immediate consequences, so the configuration reflects that: tighter access, mandatory approvals, full observability, and rollback readiness built in from the start.

Typical production configuration in GCP

• GCP project: my-app-prod
• Cloud Run min-instances: 2 or more, which keeps instances warm so users do not experience cold start latency
• Cloud Run max-instances: sized for peak traffic with headroom
• Database: full production Cloud SQL tier, automated backups, point-in-time recovery enabled
• Deploy trigger: Cloud Deploy promotion from staging with manual approval
• IAM: developers have read-only access; each service runs as a least-privilege service account; no direct console changes
• Secrets: production values in Secret Manager, rotated on schedule
• Approvals: required: a Cloud Deploy approval gate before any deployment proceeds
• Monitoring: full Cloud Monitoring with alerting policies and on-call rotation active
• SLOs: defined, tracked, and tied to alert escalation

What changes in production compared with lower environments

The key differences are not just about scale. Production has different governance rules:

• No developer deploys directly from their laptop or local machine
• Every deployment goes through the same pipeline path that ran through staging
• Rollback must be fast, using Cloud Deploy rollback or traffic splitting
• Manual console changes that bypass Terraform or the pipeline are not permitted, even for urgent fixes

# Deploying to Cloud Run with production configuration
gcloud run deploy api-service \
  --image=europe-west2-docker.pkg.dev/my-app-prod/api/api:v1.2.3 \
  --region=europe-west2 \
  --service-account=api-service@my-app-prod.iam.gserviceaccount.com \
  --set-env-vars=ENVIRONMENT=production \
  --update-secrets=DATABASE_URL=database-url:latest

Dev vs staging vs production: side-by-side

Dev vs staging vs production vs test

Some teams add a dedicated test or QA environment between dev and staging. The terminology gets used inconsistently, so it is worth being clear about what each one is for.

• Dev: developer sandbox with frequent, unstable deployments; catches obvious errors
• Test / QA: a more stable environment for automated integration tests or manual QA sign-off, separate from individual developer work
• Staging: production-like environment for final validation before release; confirms the deployment process and infrastructure configuration will hold up in production
• Production: live environment serving real users

Staging is not the same as QA. QA is for finding bugs. Staging is for confirming that the deployment process and infrastructure configuration will work correctly under production conditions. Many teams combine QA and staging into one environment, which is fine as long as staging still closely mirrors production.

When to use this setup

Three separate environments is the right default for any application with real users. The specifics change depending on your situation.

• Solo developer or small startup: all three environments still make sense. The overhead is low. Separate GCP projects cost nothing beyond the resources you deploy. Even a two-person team benefits from staging once the product has real users.
• Regulated or high-risk workloads: three environments is a minimum. Regulated industries often require a full audit trail of every deployment, mandatory approval workflows, and data separation enforced by project boundaries rather than just by convention.
• Internal tools: you might temporarily use only dev and production while the tool is in early development. That is a conscious trade-off, not a permanent approach. Internal tools can still cause serious damage if production is the only gate.
• Customer-facing systems: all three environments with proper staging parity are non-negotiable once you have paying customers or SLAs.

If you are planning your Terraform directory structure to support multiple environments, Terraform project structure covers how to organise environment directories. For keeping Terraform state isolated per environment, see Terraform state management.

Best practices for GCP environment separation

• Use a separate GCP project for each environment, giving each its own IAM boundary and billing visibility
• Give each service its own service account per environment, with the minimum IAM roles it actually needs
• Store all secrets in Secret Manager with one instance per project and nothing shared between environments
• Keep separate Terraform state per environment so a terraform destroy in staging cannot touch production resources
• Promote the same container image through the pipeline rather than rebuilding at each stage
• Configure full observability in staging, not just production. You cannot tune what you cannot see.
• Plan rollback before you need it. Cloud Deploy supports rollback to a previous release, and canary deployments in production can limit blast radius further.
• Use anonymised data snapshots for staging: realistic enough to surface issues, safe enough to give QA access
• Document which environment each Cloud Build trigger targets so new team members understand the pipeline without having to reverse-engineer it