Terraform

01The idea: infrastructure as code

Infrastructure as code means your servers, networks and DNS are defined in text files, kept in Git and changed through pull requests like application code. Terraform uses a declarative language, HCL: you describe the end state you want (one server of this size, one DNS record pointing to it), not the steps to get there. Terraform works out the steps itself. The benefits are concrete. A staging environment can be an exact copy of production. A new team member reads the code to understand the infrastructure. Changes are reviewed before they happen, and Git history shows who changed what and why. Disaster recovery becomes faster because you can recreate infrastructure from code, although data still has to come from backups.

• Declarative: describe what, not how.
• Versioned and reviewed like application code.
• Terraform provisions infrastructure; tools like Ansible configure what runs inside servers.

02Providers and resources

Terraform itself knows nothing about AWS or DigitalOcean. Providers are plugins that translate your code into API calls for one platform; there are providers for AWS, Google Cloud, Azure, DigitalOcean, Hetzner, Cloudflare, GitHub, Kubernetes and hundreds more. You declare which providers you need and pin their versions, then terraform init downloads them and records exact versions in a lock file that you commit. A resource block describes one object to manage: a server, a bucket, a DNS record. A data block reads something that already exists without managing it. Variables make code reusable, outputs expose useful values such as an IP address, and credentials come from environment variables rather than from the code.

1terraform {
2  required_version = ">= 1.10"
3  required_providers {
4    digitalocean = { source = "digitalocean/digitalocean", version = "~> 2.0" }
5    cloudflare   = { source = "cloudflare/cloudflare", version = "~> 5.0" }
6  }
7}
8 
9# tokens come from DIGITALOCEAN_TOKEN and CLOUDFLARE_API_TOKEN env vars
10provider "digitalocean" {}
11provider "cloudflare" {}
12 
13variable "ssh_key_fingerprint" { type = string }
14variable "cloudflare_zone_id" { type = string }

03Example: a server and its DNS record

Here is a complete, small piece of real infrastructure: an Ubuntu server and a DNS record pointing a hostname at it. Notice the reference digitalocean_droplet.web.ipv4_address inside the DNS record. Terraform reads these references to build a dependency graph, so it knows the server must exist before the record can be created, and it can create independent resources in parallel. If you later change the server size, the plan will show an in-place update; if you change the image, it will show that the server must be destroyed and recreated, which is exactly the kind of surprise the plan is there to reveal. The output prints the new IP after apply.

1resource "digitalocean_droplet" "web" {
2  name     = "web-1"
3  image    = "ubuntu-24-04-x64"
4  region   = "fra1"
5  size     = "s-1vcpu-2gb"
6  ssh_keys = [var.ssh_key_fingerprint]
7}
8 
9resource "cloudflare_dns_record" "app" {
10  zone_id = var.cloudflare_zone_id
11  name    = "app.example.com"
12  type    = "A"
13  content = digitalocean_droplet.web.ipv4_address
14  ttl     = 1
15  proxied = true
16}
17 
18output "server_ip" { value = digitalocean_droplet.web.ipv4_address }

04Plan and apply

The everyday workflow has a fixed rhythm. terraform init prepares the working folder and downloads providers. terraform fmt and validate catch style and syntax problems. terraform plan compares three things: your code, the state file, and the real resources, then prints every action with a symbol: plus for create, tilde for update in place, minus for destroy, and minus-plus for replace. Read the plan carefully, especially any destroy. Saving the plan to a file and applying exactly that file guarantees that what you reviewed is what runs. In a team, CI runs plan on every pull request and posts the result for review; apply runs after merge, from CI, not from someone's laptop. Use prevent_destroy on precious resources like databases.

1terraform init
2terraform fmt -check
3terraform validate
4terraform plan -out=tfplan
5terraform apply tfplan
6 
7# inspect and troubleshoot
8terraform state list
9terraform output server_ip

05State, remote state and locking

Terraform keeps a state file: a map from each resource in your code to the real object it manages, with its ID and attributes. Without state, Terraform cannot know that web in your code is server 12345 at the provider. By default state is a local file, which breaks as soon as two people or a CI job are involved. Store it remotely, in an S3 bucket or compatible storage, Terraform Cloud, or another backend, with versioning enabled so you can recover a bad write. Locking stops two applies from running at once and corrupting state. The S3 backend now supports native locking with use_lockfile; the older DynamoDB table method is deprecated. State can contain secrets such as database passwords, so encrypt it and restrict access.

1terraform {
2  backend "s3" {
3    bucket       = "example-terraform-state"
4    key          = "prod/terraform.tfstate"
5    region       = "eu-central-1"
6    encrypt      = true
7    use_lockfile = true
8  }
9}

06Modules, drift and the tool landscape

A module is a folder of Terraform code with inputs and outputs, like a function. Write a web-server module once and call it for staging and production with different sizes. Keep modules small and focused, pin versions of shared ones, and keep environments in separate state files so a mistake in staging cannot touch production. Drift is when reality no longer matches the code, usually because someone changed something by hand in the console. terraform plan reveals it; then you either update the code to match or apply to restore the declared state. As for tools: HashiCorp moved Terraform to the Business Source License in 2023 and is now part of IBM. OpenTofu is the open-source fork, largely compatible, with extras such as built-in state encryption. Pulumi uses TypeScript, Python or Go instead of HCL.

1module "web_staging" {
2  source = "./modules/web-server"
3  name   = "web-staging"
4  size   = "s-1vcpu-1gb"
5}
6 
7module "web_prod" {
8  source = "./modules/web-server"
9  name   = "web-prod"
10  size   = "s-2vcpu-4gb"
11}

07How plan really works: the graph, unknowns and replacement order

Terraform turns your configuration into a dependency graph. Every resource, data source, variable and output is a node, and every reference creates an edge. During plan it refreshes each managed resource from the provider, compares the refreshed state with the configuration, and asks the provider what action is needed. Values that only exist after creation, such as a new server's IP, appear as known after apply and flow onward as unknowns, which is why some plans show a cascade of changes. Terraform walks the graph in parallel, ten operations at a time by default, adjustable with -parallelism. When an argument cannot be updated in place, the provider marks it as forcing replacement, and by default Terraform destroys the old object before creating the new one. create_before_destroy reverses the order to avoid downtime, as long as names do not collide. Use depends_on only for hidden dependencies that no reference expresses.

1resource "aws_launch_template" "web" {
2  name_prefix   = "web-"            # unique names allow create-before-destroy
3  image_id      = var.ami_id
4  instance_type = "t4g.small"
5 
6  lifecycle {
7    create_before_destroy = true
8    ignore_changes        = [tags["LastScannedAt"]]   # set by another tool
9  }
10}

08count versus for_each, and refactoring without destroying

count creates a list of instances addressed by index: server[0], server[1], server[2]. Remove the middle item from the input list and every later index shifts, so Terraform plans to destroy and recreate servers that did not really change. for_each creates a map addressed by key, server["api"], server["worker"], so removing one key affects only that instance; prefer it whenever items have a natural identity. Renaming a resource or moving it into a module changes its address too, and without help Terraform would destroy the old address and create the new one. A moved block declares the rename in code, so the plan shows a move with no changes, and teammates and CI pick it up automatically, which terraform state mv cannot do. To stop managing a resource without destroying it, use a removed block with lifecycle destroy = false. To adopt an existing resource, use an import block.

1resource "digitalocean_droplet" "app" {
2  for_each = { api = "s-2vcpu-4gb", worker = "s-1vcpu-2gb" }
3  name     = "app-${each.key}"
4  size     = each.value
5  image    = "ubuntu-24-04-x64"
6  region   = "fra1"
7}
8 
9moved {
10  from = digitalocean_droplet.web
11  to   = digitalocean_droplet.app["api"]
12}
13 
14import {
15  to = cloudflare_dns_record.legacy
16  id = "zone_id/record_id"
17}

09Secrets: sensitive, ephemeral and write-only values

Marking a variable or output sensitive = true only hides it in plan output and logs; the value is still written to the state file in plain text. That is why state must be encrypted and access-controlled. Newer releases go further. Terraform 1.10 added ephemeral input variables, outputs and ephemeral resources, values that exist during a run but are never written to plan or state files, such as a password fetched from a secret manager. Terraform 1.11 added write-only arguments, named with a _wo suffix, which let managed resources accept those ephemeral values: the provider sends the secret to the API but never stores it. Because Terraform cannot see the stored value, you bump a companion version argument to rotate it. An even simpler option, where the platform supports it, is to let the service generate and manage the secret itself, as RDS can with manage_master_user_password, so Terraform never sees it.

1ephemeral "random_password" "db" {
2  length = 32
3}
4 
5resource "aws_db_instance" "main" {
6  identifier          = "app-prod"
7  engine              = "postgres"
8  instance_class      = "db.t4g.medium"
9  allocated_storage   = 50
10  username            = "app"
11  password_wo         = ephemeral.random_password.db.result
12  password_wo_version = 1          # bump to rotate
13}

10Guardrails: validation, checks, tests and policy as code

Terraform has several layers of built-in checking. Variable validation blocks reject bad input before planning, such as an unknown environment name or an instance size outside an allowed list. Preconditions and postconditions inside a resource's lifecycle state assumptions that must hold, for example that the chosen image is in the right architecture. Check blocks run assertions after apply, such as an HTTP request to the new endpoint, and report warnings without blocking. The terraform test command, with files ending in .tftest.hcl, runs plan or apply against test inputs and asserts on the results, which is how module authors catch regressions. Outside Terraform itself, tflint finds provider-specific mistakes, scanners such as Checkov or Trivy flag insecure settings like open security groups, and policy engines such as OPA with Conftest, or Sentinel in HCP Terraform, enforce organisation rules on the plan before apply.

1variable "environment" {
2  type = string
3  validation {
4    condition     = contains(["staging", "prod"], var.environment)
5    error_message = "environment must be staging or prod."
6  }
7}
8 
9check "site_up" {
10  data "http" "health" { url = "https://app.example.com/healthz" }
11  assert {
12    condition     = data.http.health.status_code == 200
13    error_message = "Health check did not return 200."
14  }
15}