Most engineering organisations have at least one production server that nobody is willing to reboot, set up by hand and modified over SSH for years by an engineer who has since moved on. That machine is not infrastructure. It is undocumented risk with an IP address.
The industry has already voted on the fix. Firefly's State of IaC 2025 report found that 89% of organisations now use infrastructure as code in some form, yet only 6% have fully codified their cloud environments.
A working definition before anything else
Infrastructure as code (IaC) is the practice of defining servers, networks, databases and other cloud resources in configuration files rather than through manual console work. The files live in version control, go through code review, and are applied by a tool such as Terraform, OpenTofu, Pulumi or CloudFormation. Because the code is the source of truth, any environment can be rebuilt from it, audited against it, and rolled back through it.
Manual cloud provisioning fails silently, then all at once
Hand-managed environments accumulate configuration drift. An engineer widens a security group during an incident and never reverts it, and months later a release that passed every test brings production down. Most teams are flying blind here: Firefly found that fewer than one-third of organisations continuously monitor drift, and Gartner has projected that through 2025, 99% of cloud security failures will be the customer's fault, driven overwhelmingly by misconfiguration.
Those misconfigurations carry a known price tag. IBM's 2025 Cost of a Data Breach Report puts the global average breach at $4.44 million, and the United States average at $10.22 million. An open storage bucket or an over-broad IAM role is precisely the kind of error a pull request review catches and a console session does not.
The chart tracks IBM's breach cost data over six years, with US costs crossing $10 million for the first time in 2025. Reviewed, versioned configuration is the cheapest control against that trend.
The same discipline also makes teams faster. DORA's 2021 Accelerate State of DevOps report found elite performers deploying 973 times more frequently than low performers, with a lower change failure rate, a combination only possible when provisioning is a pull request rather than a ticket in an ops queue. Sensible cloud architecture decisions reinforce all of this, since systems built around replaceable components drift far less than long-lived hand-fed servers.
Terraform best practices start with state management
Terraform remains the default choice, with the largest provider ecosystem and hiring pool. Its main alternative is OpenTofu, the open-source fork that joined the CNCF as a Sandbox project in April 2025 and stays compatible with mainstream Terraform workflows, so the choice comes down to licensing posture rather than capability. Whichever you pick, projects rarely fail over tooling but over how state, modules and pipelines are handled around it.
Nearly every serious Terraform incident traces back to state, the file recording what the tool believes it created. The production guidance from HashiCorp and Google Cloud reduces to three rules. Use a remote, encrypted backend from day one, since state can contain secrets in plaintext. Enable state locking so concurrent applies block instead of corrupting each other. And split state by environment and component, because one giant state file makes every plan slow and every mistake global. Keep modules small and single-purpose, with module and provider versions pinned.
The last piece is execution. Firefly found that around 30% of teams still run Terraform manually from local machines, which quietly undoes the model. The mature pattern runs plan and apply through CI/CD pipelines, posts the plan on every pull request, requires approval before apply, and adds policy checks with a tool like Open Policy Agent so an insecure resource fails the build rather than the audit.
FAQ
What is infrastructure as code in simple terms?
It means describing your servers, networks and cloud services in configuration files instead of building them by hand. A tool such as Terraform then makes the real infrastructure match those files, so environments become reproducible, reviewable and recoverable.
Should a new project choose Terraform or OpenTofu?
Either works, because OpenTofu remains compatible with mainstream Terraform configurations and the skills transfer directly. Choose OpenTofu if open-source licensing and CNCF governance matter to you, and Terraform if you want the largest commercial ecosystem.
A pragmatic adoption sequence
Standardise on one tool per layer, Terraform or OpenTofu for anything multi-cloud.
Configure a remote, encrypted backend with locking before writing your first real resource.
Codify one new, low-risk service end to end, then move plan and apply into your pipeline with review on every pull request.
Add policy checks, then import existing high-risk resources incrementally, starting with IAM and networking.
Enable drift detection and restrict console write access in production.
Manual infrastructure simply becomes less knowable every month until the person who understood it leaves and the outage arrives on its own schedule. If you are looking at a console-built environment and wondering how to codify it safely, talk to the engineering team at BeyondPixl Studio about planning an incremental IaC migration.