Environments: dev, staging and production
🎯You'll be able to
Run the same configuration as several environments with separate state, different sizes and names that never collide, and move changes through them in order.
🏠The everyday picture
A theatre company rehearses in a hall, does a dress rehearsal on the real stage, then performs for the audience. It's the same play each time; the audience is what changes. Mistakes are cheapest in the rehearsal hall.
📘What it really is
-
Environments are separate copies of the system:
devfor trying things,stagingto rehearse releases,prodfor real users. They should differ in size and data, not in shape. -
Ways to organise them in Terraform:
- a folder per environment (
envs/dev,envs/prod), each calling shared modules with its own variables and its own backendkey. Clear and hard to mix up; the most common choice for production systems; - workspaces (
terraform workspace new staging): one folder, several states, andterraform.workspacegives the name. Simple, but every workspace shares the backend's credentials, and it's easy to apply in the wrong one; -
one configuration with a variable and separate state chosen at
init(-backend-config=prod.hcl), which is what CI often does. -
Names include the environment. RouteRani's
local.prefix = "routerani-${var.env}"meansrouterani-dev-dbandrouterani-staging-dbcan live on one computer. In a cloud, environments usually also live in separate accounts or projects, so a mistake in dev can't touch prod. -
Promotion: the same change is applied to dev, then staging, then prod, with checks between. The pipeline should apply the same reviewed code to each, not let people edit prod directly.
-
Keep them alike: if staging runs one database copy and prod runs three, some problems appear only in prod. Make differences deliberate and few: sizes, counts, domain names.
📝A worked example
Input: RouteRani's acceptance tests run a second environment next to your own. Look at tests/lib.js: it sets TF_VAR_env=staging and
different ports (TF_VAR_http_port=18080 and so on), and runs Terraform in a copied folder with its own state.
Expected output: while npm run test:infra runs, docker ps shows routerani-staging-* containers alongside your routerani-dev-* ones,
on port 18080 instead of 8080. Your dev environment keeps running untouched, and the test removes staging when it finishes.
🌍Where it's used
- Release pipelines apply to staging, run checks, then apply the same code to production (CD8).
- Cloud account structures: AWS Organizations, Google Cloud folders and Azure management groups keep environments apart.
- Short-lived environments: some teams create a full environment for each pull request and destroy it after merging.
📝Case scenario
A school-management company used Terraform workspaces for dev and prod in one cloud account. An engineer testing a clean-up script ran
terraform destroy believing they were in the dev workspace; they were in prod, which was selected from the previous day. Students couldn't
see timetables for two hours. They moved to a folder per environment, a separate cloud account for prod, and prod applies only from the
pipeline.
🖱️Try it
Apply the finished kit twice: once normally, and once from a copy of the infra/ folder with TF_VAR_env=prod and TF_VAR_http_port=28080
set (and TF_VAR_monitoring=false). Destroy the copy afterwards. Success: two environments run side by side with different names, ports,
passwords and state.
⚠️Common mistakes
- One state for all environments. Sign: a dev change plans changes to prod. Fix: separate state (and ideally accounts) per environment.
- Fixed names. Sign: "name already in use" when creating a second environment. Fix: include the environment in every name.
- Editing prod directly. Sign: prod has settings no file mentions. Fix: promote the same reviewed change through each environment.
🛠️For your project
Every RouteRani test runs in a staging environment next to your dev one, so names must include var.env.
✅Quick check
Why put each environment's state separately?
Show the answer
So a change or mistake in one can't plan or apply changes to another.
What should differ between staging and production?
Show the answer
Size, counts and names, deliberately; not the shape of the system.