Stop 14 · Build Your DevOps PortfolioProjects · 6/7

Multi-Environment (Dev / Staging / Prod) Setup

Part of the DevOps Roadmap

In short

Real companies don't test on production. They have dev, staging and prod that look alike but differ in size and settings. Showing you can run all three from one codebase is a very real-world skill.

Show you can manage the same infrastructure pattern safely across multiple environments with different configurations — a realistic reflection of how most real companies actually organize infrastructure.

The mascot in a costume crown rehearses on a lit school stage in front of empty seats.

Think of it like this

Rehearsal, dress rehearsal, show night

A college play practises roughly in a classroom first. Then a full dress rehearsal on the real stage with lights and costumes. Only then the actual show with the audience. Same script all three times, different settings. Dev, staging and prod work just like that.

Watch it happen

One codebase, three environments

infra repo
modules/
envs/
dev.tfvars
staging.tfvars
prod.tfvars
app module
network module

1/4The shape of the infrastructure is written once, in shared modules.

The big ideas

What you need to know

Must-have: same code

All three environments are built from the same modules. Only variables differ, so staging truly predicts prod.

Separate everything

Separate state files, secrets and ideally cloud accounts per environment. A dev mistake must not reach prod.

Promote, don't rebuild

The same image moves dev to staging to prod. Each step adds more checks or an approval.

Guard production

Protect prod with required approvals, deletion protection and tighter IAM than the other two.

See it in code

Walk through the code

hcl
1# envs/dev.tfvars2env            = "dev"3instance_type  = "t3.micro"4min_replicas   = 15db_multi_az    = false6 7# envs/prod.tfvars8env            = "prod"9instance_type  = "t3.medium"10min_replicas   = 311db_multi_az    = true12 13# Apply one environment at a time, each with its own state:14#   terraform init -backend-config="key=shop/dev.tfstate"15#   terraform apply -var-file=envs/dev.tfvars

1/3dev is small and cheap: one replica, single-zone database.

Instance types here are examples. Workspaces or separate root folders per environment are also common; pick one and explain why.

Save yourself the pain

Common mistakes

Oops

Letting staging drift: someone tweaks it by hand and it no longer matches prod.

Do this instead

Change environments only through code and pipelines, and re-apply often to catch drift.

Oops

Using the same database password and account for all three environments.

Do this instead

Give each environment its own secrets and access. A leaked dev key should be boring, not a disaster.

Your mission

Milestone 1: dev and staging from one module

~40 min

Quick check

Why should staging be built from the same modules as production?

Go deeper

  1. 1Use Terraform workspaces or separate state files to manage 2-3 distinct environments.
  2. 2Show how configuration (e.g. instance size, replica count) differs sensibly between environments.
  3. 3Document your promotion process: how a change moves from dev through to prod.

More projects at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge