Infrastructure as code (IaC)
Infrastructure as code (IaC) means defining servers, networks, databases, and other cloud resources in text files that tools can apply automatically, instead of clicking through consoles.
Popular tools include Terraform, OpenTofu, AWS CloudFormation, and Pulumi. While IaC is sold on speed, its bigger payoff is consistency: environments built from the same code behave the same, and every change can be reviewed like software.
Infrastructure as code (IaC), explained at three levels
At home
Instead of setting up a computer by hand, imagine writing a recipe that a robot follows to set it up exactly the same way every time. Infrastructure as code is that recipe for servers and cloud services.
At work
With IaC, a company can recreate its whole cloud setup from files stored in version control. That makes it easier to build test environments, recover from disasters, and see exactly what changed when something breaks.
At home
Most IaC tools are 'declarative': you describe what you want (three servers, one database) and the tool figures out the steps. Before applying changes, tools like Terraform show a 'plan' of what will be created, changed, or destroyed.
At work
IaC fits into CI/CD: proposed changes go through pull requests, automated checks scan for security misconfigurations, and the plan is reviewed before applying. Reusable modules standardize common patterns, like a secure storage bucket, across teams.
At home
Terraform tracks what it created in a 'state' file, mapping code to real resources. If state is lost or corrupted, the tool can't safely manage those resources. In my opinion, state management is the least glamorous and most important part of running IaC well.
At work
Mature IaC practice includes remote, locked state storage, policy as code (for example, Open Policy Agent or Sentinel) to block risky changes, drift detection, and clear module versioning. Teams also weigh tool choice: Terraform or OpenTofu for multi-cloud, cloud-native tools for single providers, or general-purpose languages with Pulumi or the AWS CDK when logic gets complex.
Real-world examples
At home
Aisha wanted a test copy of her side project's cloud setup. Because she'd written it in Terraform, she ran one command with a different environment name and had an identical copy in ten minutes.
At work
Jerome is a cloud architect at a Canadian retailer. After a misconfigured storage bucket exposed files, his team moved all cloud resources into IaC with automated security checks. The same mistake is now blocked before it reaches production.
How it compares
| feature | Infrastructure as code (IaC) | Manual setup (ClickOps) |
|---|---|---|
| How infrastructure is created | From reviewed code files | Through web consoles by hand |
| Repeatability | High | Low |
| Change history | Full, in version control | Limited to cloud logs |
| Disaster recovery | Rebuild from code | Rebuild from memory and screenshots |
IaC trades a learning curve for environments you can trust and rebuild.
For analysts
If your cloud setup only exists in people's heads and console clicks, that's a business continuity risk. I'd prioritize IaC for anything you'd need to rebuild after an outage, starting with networking and security settings.
History & origin
Configuration management tools started the movement: CFEngine appeared in 1993, followed by Puppet (2005), Chef (2009), and Ansible (2012). As cloud computing grew, AWS launched CloudFormation in 2011, and HashiCorp released Terraform in 2014, which worked across many cloud providers. In August 2023, HashiCorp changed Terraform's licence to the Business Source License, prompting the community to fork it as OpenTofu under the Linux Foundation. IBM completed its acquisition of HashiCorp in early 2025. In my view, the licence fight was a reminder that the tools at the base of your infrastructure carry business risk, not just technical risk.