Small teams often set up their cloud accounts by clicking through the console. It's fast and it works, until someone needs to know why a firewall rule exists, or the staging environment needs to match production, or the person who set everything up leaves.
We use Terraform (or OpenTofu, its open-source fork) for client infrastructure from the first environment. It adds maybe a day to the initial setup. We've found it pays that back quickly.
What you get
A written record. Every server, database, bucket and DNS record lives in a file in git. You can read what exists without clicking through twenty console pages, and git history tells you who changed what and why.
Identical environments. Staging and production come from the same code with different variables. When a bug appears only in production, "the environments are different" stops being the explanation.
Reviewable changes. A change to infrastructure is a pull request. terraform plan shows exactly what will be created, changed or destroyed before anyone applies it. Reviewers catch the security group that opens port 5432 to the internet before it happens.
Recovery. If an account gets compromised or a region has a bad day, you can rebuild the infrastructure from code into a new account. Data still needs backups, but you won't be reconstructing settings from memory.
Where we keep it simple
Terraform can grow into a project of its own. For small teams we avoid that:
- One repository for infrastructure, organised by environment.
- Remote state in a storage bucket with locking, so two people can't apply at once.
- Modules only when something repeats three or more times. Early abstraction makes the code harder to read than the console.
- Managed services over self-built ones, so there's less to define.
Where it doesn't pay off
We don't put everything in Terraform. One-off experiments can stay manual and get deleted. Some settings change daily through an application, such as feature flags, and belong in the app. Secrets values stay in the secrets manager; Terraform creates the empty secret and the app reads it.
Adopting it on an existing account
You don't need to start from scratch. We import the resources that matter most (DNS, databases, networking, load balancers) one by one, check that plan shows no changes, and leave the rest for later. After a few weeks the important parts are in code and new resources get created there by default.
The test
Ask yourself: if your cloud account disappeared tomorrow, how long would it take to rebuild the setup, and who would know how? If the answer is "days" and "one person", infrastructure as code is worth the day it costs.
