How do I set up staging and production on a cloud host?

A good staging/production setup on a cloud host usually means two isolated environments that are as similar as possible, but kept separate so you can test safely before releasing.

Recommended setup

1) Use separate environments

Create:

• staging: for testing releases, QA, previews
• production: live user-facing app

Keep them separated by:

• different URLs, like:
  • staging.example.com
  • example.com
• different databases
• different API keys/secrets
• ideally separate cloud resources or at least separate instances

---

2) Mirror production in staging

Staging should match production closely:

• same app version/runtime
• same OS/container image
• same web server config
• same background jobs
• same caching setup
• same third-party integrations, but pointing to sandbox/test accounts

This reduces “works in staging, fails in prod” issues.

---

3) Separate data stores

Use different:

• databases
• object storage buckets
• queues
• email/SMS providers or sandbox modes
• analytics properties

Never let staging write to production data.

---

4) Separate configuration and secrets

Use environment-specific variables:

• DATABASE_URL
• REDIS_URL
• API_KEY
• SECRET_KEY
• S3_BUCKET
• APP_ENV=staging|production

Store secrets in the cloud host’s secret manager or environment settings, not in code.

---

5) Deploy via CI/CD

Use a pipeline such as:

• push to main → deploy to staging automatically
• after approval/tag → deploy to production

Common flow:

1. code merged into main
2. build artifact or container image
3. deploy to staging
4. run tests/migrations
5. manual approval
6. deploy same artifact to production

Use the same build artifact for both environments when possible.

---

6) Use deployment protections

For production:

• manual approval gates
• restricted access
• rollback strategy
• health checks
• blue/green or rolling deployments

For staging:

• auto-deploy from branch
• allow test data resets
• allow more logging/debugging

---

7) Infrastructure choices

There are a few common patterns:

Simple pattern

• 1 VM/container for staging
• 1 VM/container for production

Good for small apps.

Better pattern

• separate app instances
• separate managed databases
• load balancer in front of production
• staging behind basic auth or IP restriction

More advanced pattern

• infrastructure as code with Terraform/Pulumi/CloudFormation
• separate cloud accounts/projects for staging and production

This is best for stronger isolation and safety.

---

8) Domain and access setup

Typical setup:

• production: public and optimized
• staging: restricted access via:
  • password/basic auth
  • VPN
  • IP allowlist
  • cloud auth proxy

This prevents search engines and users from accidentally using staging.

---

9) Observability

Set up separate:

• logs
• metrics
• error tracking
• alerts

Make sure staging noise doesn’t trigger production alerts.

---

10) Database migrations

Treat migrations carefully:

• test migrations in staging first
• use backward-compatible migrations when possible
• deploy code that supports both old and new schema during rollout
• run destructive changes only after verifying

---

A practical example

If you’re on a typical cloud platform:

• Staging
  • app service: myapp-staging
  • database: myapp_staging_db
  • domain: staging.myapp.com
  • secrets: staging-only
• Production
  • app service: myapp-prod
  • database: myapp_prod_db
  • domain: myapp.com
  • secrets: production-only

CI/CD deploys the same container image to both, but with different environment variables.

---

Best practices checklist

• Separate staging and production
• Separate databases and secrets
• Use same app version/runtime in both
• Deploy staging first
• Use approvals for production
• Restrict staging access
• Monitor and alert separately
• Keep rollback simple
• Test migrations in staging

If you want, I can also give you:

1. a Docker + cloud VM example,
2. a Kubernetes example, or
3. a specific setup for AWS / GCP / Azure / Render / Fly.io / Heroku.