Infrastructure as code with Terraform: a practical start

If your infrastructure exists only in a web console and in the memory of a couple of people, every change is a risk and every audit is a treasure hunt. Infrastructure as code fixes that: what exists is written down, reviewed and versioned.

What you gain

• Review. Every change arrives as a pull request with a plan that says exactly what will be created, changed or destroyed.
• Rebuild. An environment can be brought back from the repository, not from memory.
• Audit. “Who changed this firewall, and when?” is answered by Git history.
• Matching environments. Staging and production come from the same code with different variables.

Who does what

Tool	Used for
Terraform / OpenTofu	Creating and changing resources: servers, networks, load balancers, DNS, managed databases, cloud permissions
Terragrunt	Organising many environments and accounts without copying code
Ansible	Configuring what runs inside servers: packages, services, users, files
Packer	Building ready-made base server images
ArgoCD / GitOps	Deploying to Kubernetes from Git

Terraform or OpenTofu

In August 2023 HashiCorp changed Terraform’s licence from MPL 2.0 to the Business Source License (BSL). The community created a fork, OpenTofu, which keeps the MPL 2.0 licence and is hosted by the Linux Foundation. In February 2025 IBM completed its acquisition of HashiCorp.

For most teams using Terraform for their own infrastructure, nothing practical changes: code, providers and modules work in both. OpenTofu adds some features of its own, such as state encryption. What matters is to pick one, pin the version, and not mix them on the same state.

Step by step, with infrastructure that already exists

1. Remote state with locking

Terraform records which resources it manages in a state file. That file belongs in a remote backend (object storage, for example) with locking, so two people cannot apply at once, and encryption, because it can contain passwords. Never in Git.

2. Import what already exists

Do not recreate what works. Since Terraform 1.5 you can declare import blocks and generate starting code with terraform plan -generate-config-out=generated.tf. Then clean that code up, move it into modules, and check that terraform plan proposes no changes. That “empty plan” is the sign that the code matches reality.

3. Small modules, pinned versions

Split by environment and by component (network, compute, DNS, database), not one giant file. Pin the Terraform and provider versions and commit .terraform.lock.hcl, so everyone runs exactly the same thing.

4. Plan in every pull request, apply only from CI

Every pull request runs terraform plan and posts the result for review. The pipeline runs apply after approval, with credentials nobody keeps on a laptop. Nobody changes production from the console “just this once”.

5. Secrets out of the code

Passwords and keys do not go in .tf files or repository variables. They are read from a secrets manager or the CI secret store and marked sensitive.

6. Drift checks

Someone will change something by hand eventually. A nightly job that runs terraform plan -detailed-exitcode (exit code 2 means differences) and opens an issue catches it the next day, not in the next outage.

7. Policy and scanning

Tools such as Checkov or Trivy review the code before merge: public buckets, ports open to the whole internet, encryption turned off. They are cheap to add and stop common mistakes.

Common mistakes

• Keeping state in Git or on someone’s laptop.
• Trying to write the whole infrastructure at once instead of importing piece by piece.
• One state for everything, so any small change locks and risks everything else.
• Running apply from laptops with admin credentials.
• Not pinning provider versions, then finding surprise changes on the next init.

How we do it

We move AWS, EKS and Hetzner infrastructure into Terraform, Terragrunt and Ansible, with GitOps on Kubernetes. See an example in our payments fintech DevOps case, and the scope and price on infrastructure as code. If you also want to move part of your stack off AWS or Azure, code is the first step of an EU cloud migration.