Terraform IaC: What It Actually Automates, and What It Doesn't

Infrastructure as code means describing servers, databases, and networks in a text file instead of clicking through a console, then letting a tool reconcile reality to match that file. Terraform is the tool most teams mean when they say IaC, and its whole design follows from one idea: a plan you can read before you run it.

“Terraform IaC” is really two questions stacked together: what infrastructure as code is as a practice, and what Terraform specifically does with that idea. They get conflated because Terraform is so dominant that the terms are nearly synonymous in conversation, but understanding them separately is what tells you whether you actually need either one.

Table of contents

• Infrastructure as code, without the buzzword
• Terraform’s model: providers, resources, state
• A small example, end to end
• Remote state, locking, and drift
• OpenTofu: the fork that exists because of a license change
• When IaC is genuinely overkill
• When a managed platform removes the need entirely
• How this fits the rest of the stack
• FAQ

Infrastructure as code, without the buzzword

IaC just means your infrastructure’s definition lives in a file, checked into version control, instead of in the memory of whoever clicked the buttons in a cloud console. The file describes the desired end state: this many servers, this database engine, these firewall rules, this DNS record.

A tool then reads that file and makes the real infrastructure match it. The value isn’t the automation alone, it’s that the file is the source of truth. You can diff it, review it in a pull request, and roll it back the same way you’d roll back application code.

This matters more as a team grows. Console changes are invisible until someone asks why a firewall rule exists and nobody remembers adding it. A file with a commit history answers that question by itself.

IaC also changes how you recover from disaster. Rebuilding infrastructure from a description you can re-run is a fundamentally different exercise than reconstructing it from memory and screenshots in a wiki, especially at three in the morning when a region has a bad day and half the team is asleep.

Terraform’s model: providers, resources, state

Terraform reads HCL configuration files describing resources, resolves them through providers (plugins for AWS, GCP, Cloudflare, and hundreds of others), and tracks what it created in a state file. The state file is Terraform’s memory of the real world, separate from your configuration and separate from the cloud itself.

• Providers translate generic Terraform resources into API calls for a specific platform
• Resources are the individual things being managed: a VM, a bucket, a DNS record
• State maps your configuration to the real, already-created infrastructure
• The dependency graph lets Terraform figure out create/update/destroy order automatically

That state file is also Terraform’s biggest operational gotcha. If it goes missing or two people apply changes against it at the same time, Terraform loses track of what it owns, which is why remote state is treated as mandatory rather than optional past a single-person project.

Modules are the last piece of the model worth knowing early: a module is just a reusable bundle of resources with inputs and outputs, the same idea as a function in a programming language. A well-designed module for “a web service with a database” turns a fifty-line block of repeated configuration into a five-line call, reused across every environment that needs the same shape.

A small example, end to end

A minimal HCL file for a single cloud resource is short enough to read in full, which is part of the appeal over a wall of console screenshots in a wiki page.

resource "aws_s3_bucket" "assets" {
  bucket = "runxbuild-example-assets"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

The workflow around that file is always the same three commands: init downloads the providers, plan shows exactly what will change before anything happens, and apply executes it.

terraform init
terraform plan
terraform apply

Plan is the step that earns Terraform its trust. It’s a dry run that prints a diff of additions, changes, and deletions, so an apply is rarely a surprise if you actually read the plan output first.

Remote state, locking, and drift

Running Terraform from a laptop with a local state file works for a demo and breaks the moment a second person touches the same infrastructure. Remote state, typically an S3 bucket or a Terraform Cloud workspace, gives everyone the same source of truth.

Locking prevents two applies from running at the same time and corrupting that state. Most remote backends support it natively; skipping it is how two engineers running plan and apply in the same ten minutes end up with a state file that no longer describes anything real.

Drift is what happens when reality and state disagree, usually because someone made a manual change in the console that Terraform doesn’t know about. Terraform will try to “fix” it back to match your config on the next apply, which is exactly why manual console changes on Terraform-managed infrastructure are a recurring source of surprise outages.

OpenTofu: the fork that exists because of a license change

In August 2023, HashiCorp relicensed Terraform from the open-source Mozilla Public License to the Business Source License, restricting how competitors could use it commercially. A group of companies and contributors forked the last MPL-licensed release into OpenTofu, now a Linux Foundation project.

OpenTofu is a drop-in replacement for most workflows: same HCL syntax, same provider ecosystem, same state file format. The practical decision for most teams is less about ideology and more about which one their CI tooling and existing modules already assume, since the two have started to diverge slightly in new features.

For a new project starting today, the choice is less consequential than it feels. Both read the same configuration files, both work with the same provider plugins, and migrating a small codebase between them later is mostly a matter of swapping the binary your CI pipeline calls. Pick one, commit to consistent tooling across your team, and revisit only if a specific feature genuinely diverges in a way that affects you.

When IaC is genuinely overkill

A small team running one or two services on a handful of resources can spend more time maintaining Terraform modules than they save from having them. State file management, provider version pinning, and module design are real ongoing costs, not a one-time setup fee.

The honest signal that you need it: multiple environments that must stay consistent, multiple people who need to change infrastructure without stepping on each other, or infrastructure complex enough that a console click could plausibly break something you’d only notice later.

The version of this mistake that shows up most often isn’t skipping Terraform when you needed it. It’s adopting it for a single environment with one contributor, and then spending real time maintaining provider version pins and module refactors for a benefit that was already available for free: a console you can click through in under a minute.

When a managed platform removes the need entirely

Terraform earns its cost when you’re assembling primitives: a VPC here, a load balancer there, an autoscaling group behind it, each one a resource block with its own configuration surface.

A platform that already bundles those primitives into a single deploy step removes the need to describe them at all. If your infrastructure is “a web service, a database, and some storage,” that’s a shape a managed platform can hand you directly, without a state file to lock, back up, or lose.

How this fits the rest of the stack

The right amount of IaC is the amount your team actually needs to keep multiple environments honest, not the amount a blog post says is best practice. If your current stack is a state file describing three primitives that a managed platform would hand you as one deploy, it’s worth checking what the simpler path actually costs: the RunxBuild hosting calculator prices out the service, the database, and the storage together, without a provider block in sight.

For a small team whose infrastructure is one service and one database, creating both from the RunxBuild dashboard may well be less code than the Terraform that would describe them.

Useful related references:

• Terraform Deployment: A Practical Walkthrough From Init to Apply
• Terraform Locals: When a Value Deserves Its Own Name
• DevOps Automation: What Actually Gets Automated and What Doesn’t
• Services on RunxBuild

FAQ

What is the difference between Terraform and other IaC tools?

Terraform is a declarative, provider-agnostic tool that keeps a central state file and works through a plan-then-apply cycle. Alternatives like Pulumi use general-purpose programming languages instead of HCL, while cloud-native tools like AWS CloudFormation only manage that one provider’s resources.

Is Terraform free to use?

Terraform itself is free to download and run. HashiCorp charges for Terraform Cloud and Enterprise, which add remote state hosting, policy enforcement, and collaboration features on top of the open-source CLI.

What is OpenTofu and why does it exist?

OpenTofu is a community-maintained fork of Terraform, created after HashiCorp moved Terraform from an open-source license to the Business Source License in August 2023. It is now hosted by the Linux Foundation and aims to stay compatible with existing Terraform configurations.

Do I need Terraform for a small project?

Not necessarily. If you’re managing a handful of resources alone, a managed platform or a few CLI commands can be simpler than maintaining Terraform state and modules. IaC pays off once multiple environments or multiple people need to stay in sync.

What happens if the Terraform state file is lost?

Terraform loses track of what infrastructure it owns, which usually means manually reconstructing or re-importing resources into a new state file. This is the core reason remote state with locking is treated as mandatory for anything beyond a solo experiment.