When you need this
- Infrastructure was built in the console, and can’t be rebuilt reliably.
- Terraform exists, but it’s one large root module that everyone is afraid to apply.
- Staging doesn’t match production, because they were built differently.
- Changes are applied from someone’s laptop.
Module design
We design a small set of reusable modules (network, service, database, and so on) with sensible defaults, versioned and documented. Every environment is built from the same modules with different inputs, so staging is a smaller copy of production rather than a close guess.
State and environments
State lives remotely, in S3 with locking, and is split by environment and by component, so one mistake can’t reach everything. Provider and module versions are pinned. Secrets stay out of state where possible.
Bringing existing infrastructure under Terraform
We import resources where that’s sensible and rebuild where it isn’t, one environment at a time, starting with the least risky.
Terraform in the pipeline
- Plan on pull request: the planned change is posted for review.
- Apply on merge: only the pipeline applies, and people don’t have write access to production by default.
- Drift detection: a scheduled plan flags anything changed by hand.
See Faster deployments for the full pipeline.
Common questions
Terraform or AWS CDK?
Both work. We’ve built with each, and we recommend Terraform where you want one tool across AWS, Azure and SaaS providers.
Can you review our existing Terraform?
Yes. We look at module boundaries, state layout, hard-coded values, version pinning and how changes are applied, and give you a prioritised list.
Next step
Show us your Terraform
Or tell us there isn’t any. On a 30-minute call we’ll tell you where we’d start.