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.

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
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
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.tfvars1/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
Quick check
Why should staging be built from the same modules as production?
Go deeper
- 1Use Terraform workspaces or separate state files to manage 2-3 distinct environments.
- 2Show how configuration (e.g. instance size, replica count) differs sensibly between environments.
- 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.