An Environment represents a deployment target — a specific AWS account and region where your application runs. Environments are organized by application and follow a promotion pipeline.
Promotion Pipeline
Changes flow through environments in order:
dev1 → stage1 → prod1
Each stage serves a purpose:
- Dev — Rapid iteration. Auto-approved, auto-promoted. Changes deploy automatically when code is pushed.
- Staging — Validation. Staff approval required. Mirrors production configuration.
- Production — Live traffic. Staff + client approval. Protected with deletion safeguards.
Opsitron enforces this pipeline — you can’t deploy to production without first succeeding in dev and staging.
What Each Environment Tracks
Every environment in Opsitron stores:
- Cloud Account — Which AWS account it deploys to
- Deployed Module Version — Which version of the infrastructure module is currently running
- Infrastructure Outputs — Cached values from Terraform (ECS cluster name, ALB DNS, etc.)
- Deployment History — Every deployment with status, cost estimate, and blast radius
- DNS Configuration — Service discovery hostname, Route53 zone, ACM certificate
Environment Types
Regular Environments
Follow the promotion pipeline. Changes must pass through earlier stages before reaching later ones.
Ephemeral Environments
Short-lived environments for feature branches or testing. They deploy independently from the promotion pipeline and can be created and destroyed on demand.
Infrastructure as Code
Each environment corresponds to a directory in your config repository:
apps/
my-app/
dev1/
main.tf # Module call with environment-specific config
variables.tf # Input variable declarations
terraform.tfvars # Environment-specific values
backend.tf # Terraform state configuration
stage1/
...
prod1/
...
Every environment has its own isolated Terraform state. Changes to one environment never affect another.