CI-CD
Terraform
Infrastructure as code for AWS, Azure, GCP, and the rest — every resource defined, reviewed, and reproducible.
How we use it
Terraform is how we define infrastructure. Servers, databases, networks, and security groups live in versioned HCL — so rebuilds, reviews, and disaster recovery are real, not tribal knowledge.
Practices we stick to
- Modules — reusable networking, data, and cluster pieces
- Environments — separate state for dev, staging, production
- Remote state — locked backend with versioning
- Review — every change is a PR with a plan attached
- CI — plan on PR, apply on merge (with the right gates)
Typical patterns
- Same code, different vars — dev / staging / prod
- Disaster recovery — rebuild from the repo, not from memory
- Cost awareness — state and tags that show what you are paying for
- Policy as code — encryption and network rules enforced in modules
- Ephemeral stacks — full staging for a feature branch when it helps
Our standards
If it is not in Terraform, it should not exist in production. Modules reviewed like application code. Plan on every PR so drift is visible before apply. A full environment must be reproducible from the repository.
Related services
- Cloud Migration — Terraform-first target estates
- Kubernetes & DevOps — ongoing platform changes as code
FAQs
Q: How do you handle secrets? Secrets Manager / Key Vault / Secret Manager — never hardcoded. Terraform references them at apply time.
Q: Where does state live? Encrypted remote backend with locking (S3 or equivalent). Concurrent applies are blocked on purpose.
Q: What about drift? CI runs plan regularly. Console edits get flagged. The repo is the source of truth.
Using Terraform in production?
Tell us what you run today. We will say whether Terraform fits, what we would change, and what it would take — no deck.