Infrastructure as Code¶
At CDS, infrastructure as code (IaC) is how we manage cloud configuration. It is not an optional practice for complex engagements — it is how we work, applied consistently from the start of every deployment.
Why IaC matters¶
Manual configuration is difficult to review, hard to audit, and impossible to test before it is applied. It drifts. Over time, the gap between what a system is documented to do and what it actually does grows — and that gap is where vulnerabilities live.
Configuration managed as code behaves differently. It can be peer-reviewed before deployment in the same way code is. It can be tested. It creates a clear change history. When something goes wrong, you can see exactly what changed, when, and why. When you need to replicate an environment, you run the code.
For security-critical configuration in particular — edge protection, network access controls, firewall rules — IaC is a security practice as much as an engineering one. We treat it as such.
Our approach¶
Terraform is our default IaC tool for cloud infrastructure and Cloudflare configuration. It has wide client adoption, a mature ecosystem, and strong support across the cloud providers and platforms we work with most frequently.
Configuration lives in version control. Infrastructure configuration belongs in the same repository as the application it supports, or in a dedicated infrastructure repository with the same review and merge discipline applied to application code. It does not live in someone's local environment or in a shared folder.
Peer review before deployment. Infrastructure changes go through pull request review before they are applied. The review should check for correctness, security implications, and consistency with the wider architecture — not just syntax.
The client owns the codebase. When CDS delivers an IaC implementation, the Terraform codebase is a deliverable. The client receives it, owns it, and is the intended long-term maintainer. We write it accordingly: clearly structured, documented, and sized to what the client's team can realistically maintain without us.
IaC and Cloudflare¶
CDS maintains a shared, pen-tested Terraform baseline for Cloudflare application services. See the Cloudflare page for detail on the baseline and how it is applied across engagements.
Standards and tooling¶
| Tool | Use |
|---|---|
| Terraform | Primary IaC tool for cloud infrastructure and Cloudflare configuration |
terraform plan | Always run and review before apply; output should be part of the PR where practical |
tflint | Linting for common Terraform errors and best practices |
| Remote state | State stored remotely (Azure Blob, AWS S3, or Terraform Cloud) — never committed to the repository |
Warning
Never commit Terraform state files or secrets to version control. Use remote state backends and a secrets management solution (Azure Key Vault, AWS Secrets Manager, or equivalent) from the start of the engagement.
Relationship to other practices¶
IaC sits at the intersection of engineering, security, and operations. The Architecture page covers the principles that inform infrastructure decisions. The Source Control and Delivery page covers the repository and pipeline standards that IaC configuration should follow.