Anyone who manages even a couple of servers knows the scene well. You log into a cloud provider’s control panel, click to create a virtual machine, open a few firewall ports by hand, wire up a domain. It works. Then, six months later, you need to build the exact same thing in a second environment, or rebuild in a hurry something that broke, and nobody remembers the precise sequence of clicks. That’s exactly the problem Infrastructure as Code sets out to solve.

What Infrastructure as Code is

Infrastructure as Code - usually shortened to IaC - is the idea of describing your infrastructure in text files, instead of configuring it by hand by clicking through a panel. Rather than remembering which buttons to press, you write a document that states how everything should be: how many machines should exist, what size they are, which networks connect them, which firewall rules apply, which DNS records point where.

A program reads those files and takes care of making the real infrastructure match the description. If the text says two servers should exist and there’s only one, the program creates the second. If something no longer matches, it brings it back to what’s written.

The key point is that these files are plain text, just like the source code of a program. And like code, they can be kept in a version control system such as Git - a tool that tracks every change, who made it and when. The infrastructure stops living only inside the provider’s console and in the head of whoever built it, and becomes something you can read, share and rebuild.

Why it’s worth it

The benefits aren’t abstract. They address problems that show up every time an infrastructure grows or changes hands.

Repeatability. The same file always produces the same result. Need a staging environment identical to production? Reuse the same description. Need to recreate an entire setup after a failure? Start from the text, not from memory. What used to be a long, forgetful manual procedure becomes a repeatable operation.

Review. When infrastructure is text, every change can be read and discussed before it’s applied, and checked by a machine the way it happens in a CI/CD pipeline, exactly the way it’s done with an application’s code. You can see in advance what will change, a colleague can check it, and there’s a history of who changed what. Opening a firewall port stops being an invisible click and becomes a line someone wrote, with a date and a reason.

Fewer human errors. Configuring lots of things by hand, often in a hurry, is fertile ground for mistakes: a rule forgotten on one server, a parameter that differs between two environments meant to be identical. Describing everything in a file and letting a machine apply it removes much of that waste. The same description produces the same infrastructure, with no variations introduced by tiredness or haste.

Documentation by default. In most projects the infrastructure documentation either doesn’t exist or is out of date. IaC eases the problem at the root: the files are the up-to-date description of what actually runs, because they’re the same thing that created it. There’s no separate document that risks drifting from reality - reality is the document.

Desired state and idempotency

Two concepts help explain how an IaC system works, and they show up in almost every tool.

The first is desired state. With the manual approach you issue imperative commands, one after another: “create this machine”, “then open this port”, “then install that”. IaC does the opposite: you describe the final result you want - the desired state - and leave the tool to work out which steps are needed to get there. You don’t say how to do it, you say what should exist. This way of thinking is called declarative, and it has a practical benefit: the description stays valid whether you start from scratch or almost everything already exists.

The second is idempotency. It’s a technical term for a simple idea: applying the same description once or ten times leads to the same result. If the infrastructure already matches what’s written, applying it again creates no duplicates and changes nothing. That property is what makes IaC tools safe to re-run: there’s no risk that running the same file twice doubles your servers. The tool compares what exists with what’s described, and acts only on the difference.

What it looks like in practice

An IaC file looks like a series of orderly descriptions. Here, as an example, is how you might describe a single virtual machine with Terraform, one of the most widely used tools:

resource "aws_instance" "web" {
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

You don’t need to know the syntax to get the gist: the block says “a virtual machine of this type, called web-server, should exist”. It doesn’t explain how to create it, it just states that it should exist. It’s text, so it can be read, commented on, versioned.

The typical work cycle is made of a few recurring steps. First you write the description. Then you ask the tool for a preview - often called a plan - which compares the text with reality and shows exactly what it would create, change or destroy, without touching anything yet. Only after reading and approving that preview do you apply it, and at that point the tool carries out the changes in the right order. This preview step is one of the most important differences from manual work: you see what will happen before it happens.

Terraform and its ecosystem

When it comes to IaC for cloud infrastructure, the most frequently mentioned tool is Terraform, developed by the company HashiCorp. The official documentation describes it as a tool that lets you “build, change, and version cloud and on-prem resources safely and efficiently”, defining them in human-readable configuration files.

Terraform uses its own language, HCL (HashiCorp Configuration Language), designed to be readable even by people who don’t know it well. It doesn’t talk to each platform directly: it uses providers, components that translate the description into the specific calls of a service - Amazon Web Services, Google Cloud, Azure, and many others. HashiCorp and the community have written thousands of providers, available in a public registry, which is why the same approach works across very different platforms. Terraform also keeps a state file it uses as a reference for what it has already created.

One piece of context is worth knowing. In 2023 HashiCorp changed Terraform’s license, moving from an open-source license to the more restrictive Business Source License. In response, part of the community created an independent derivative called OpenTofu, now hosted by the Linux Foundation and kept open source. For most people who use these tools to manage their own infrastructure the day-to-day practical difference is small, but it’s useful to know when getting your bearings: Terraform remains the most widely used tool, and is no longer the only one.

In short

Infrastructure as Code moves your infrastructure from a series of hard-to-remember clicks to a description in text files, readable and versioned. The benefits are concrete: you recreate everything the same way, you review each change before applying it, you cut down manual mistakes, and the description becomes the documentation itself. Two ideas sit underneath it: declaring the desired state instead of issuing step-by-step commands, and idempotency, which makes it safe to reapply the same description. Terraform is today the most widely used tool for this, but the real value isn’t the tool - it’s giving up trusting your infrastructure to memory and starting to write it down.

Sources

• What is Terraform? - HashiCorp
• Terraform - Configuration Syntax (HCL)
• OpenTofu Announces Fork of Terraform