Our approach: structure, method and boundaries
1. Structure starts with the repo
The basis of a healthy Terraform landscape lies in a clear repository structure.
Many organisations spread their modules across multiple repositories to encourage reuse. This sounds logical, but in practice it often leads to dependency chaos: versions diverge, simple changes require updates in multiple repos, and CI/CD pipelines become unnecessarily complex.
A monorepo works better in many cases. Everything stays together, dependencies are visible, and modules and environments evolve at the same pace. This is not to say that you shouldn’t create separate modules; on the contrary, good use of modules creates generic and reusable code, which increases development speed. Specifically, splitting modules into different repositories often causes problems at Terraform.
The following applies here: do not make modules too small. Too many small modules will cause a domino effect with every change. A module should be a logical building block – independently usable and decoupled from its parent. Use clear interfaces (outputs and inputs) and avoid hardcoded names or IDs; these are ticking time bombs for refactors.
For example, a monorepo might look like this:
terraform/
├── modules/ # Reusable modules ↪So_
│ ├── network/
│ ├── compute/
│ └── storage/
└── platforms/ # Main modules to be deployed
├── data_domain/
└── data_science/
Clear, consistent and recognisable.
2. The developer way-of-work
A good structure is only valuable if it is worked with properly.
Teams should be able to develop and test locally, but only be allowed to deploy via controlled pipelines. So no terraform apply from a laptop, but via CI/CD.
Infrastructure as Code is code, and thus belongs to the same discipline: work via pull requests, plan → review → merge → apply. Automate checks with terraform fmt, validate, tflint and security/policy scans. Use drift detection to spot anomalies early.
Good governance also means clear boundaries: freedom where you can, control where you must. Policies and scripts can prevent anyone from accidentally stepping outside their scope.
The result? A workflow in which developers can work quickly, without compromising the stability of production.
3. Setting limits: not everything belongs in Terraform
A mature Terraform landscape knows where the boundaries are. Some organisations want to manage everything with Terraform, even app configuration or data pipelines. But that makes infrastructure heavy and inflexible.
Terraform excels in stable infrastructure components such as networking, compute, storage, identity, security. For dynamic resources, such as dashboards, pipelines or temporary workloads, another mechanism is often better.
Not wanting to do everything in Terraform is not a weakness, but a sign of maturity.
