What Is Terraform? Infrastructure as Code Without the Infrastructure Degree

Your Cloud Has a Blueprint File Now

Here's a scenario that's becoming more and more common. You're building a SaaS product. You ask Claude to help you set up your production environment — a server, a database, a bit of networking. The AI doesn't open a browser and start clicking buttons in your AWS console. Instead, it generates a handful of files that end in .tf.

Those files are Terraform. And they describe your entire cloud infrastructure in plain text — the same way a blueprint describes a building before anyone breaks ground.

If you've worked in construction or contracting, this is going to click immediately. A blueprint isn't the building. It's a precise description of what the building should be — every room, every wall, every electrical outlet — written in a language that builders know how to execute. Terraform is the same thing for cloud infrastructure. The .tf files are your blueprint. The clouds (AWS, DigitalOcean, Google Cloud) are the construction crew. Terraform is the project manager that hands the blueprint to the crew and makes sure everything gets built in the right order.

Before Terraform existed, setting up cloud infrastructure meant navigating dashboards, clicking through menus, making sure you checked the right boxes in the right sequence. Every time you needed to recreate that environment — for a staging server, for a new client, after a disaster — you'd start over from memory. Or from a document someone wrote six months ago that's already out of date.

Terraform changed that by making infrastructure declarative. You declare what you want — "I want a server with 2GB RAM running Ubuntu, connected to a PostgreSQL database, with DNS pointing my domain at it" — and Terraform figures out how to make that real. You're not clicking through steps. You're describing the end state and letting the tool work out the execution.

Why AI Keeps Generating Terraform Files

If you've been using Claude, Cursor, or any AI coding tool to help set up cloud deployments, you've probably seen .tf files appear in your project. There are good reasons why AI defaults to Terraform when you ask for infrastructure help.

First, Terraform has an enormous body of examples online. Its configuration language (HCL — HashiCorp Configuration Language) is readable, well-documented, and consistent. AI tools have trained on millions of Terraform configurations. When you ask "set up a VPS with a Postgres database," generating Terraform is the most natural, reproducible answer the AI can give.

Second, Terraform is genuinely the professional standard for production infrastructure. It's what most real engineering teams use to manage cloud resources. When AI acts like an experienced engineer on your behalf, it reaches for the same tools an experienced engineer would reach for.

Third, and maybe most importantly for vibe coders: Terraform files are text. AI can generate them, explain them, modify them, and reason about them in the same way it reasons about any other code. Compare that to "click this button in the AWS console" — the AI can't see your console. It can't guide you through a UI. But it can write you a complete infrastructure definition and explain every line.

The result: if you're building anything beyond a simple front-end hosted on Vercel or Netlify, there's a decent chance your AI will hand you Terraform at some point. Understanding what you're looking at — before you run it — is not optional once real money and real data are involved.

Real Example: A VPS, a Database, and a Domain in 60 Lines

Let's look at what a real Terraform setup looks like. This is a simplified but functional example for deploying a web application: a VPS (virtual private server) running your app, a managed PostgreSQL database, and DNS records pointing your domain at the server — all on DigitalOcean.

Here's what the AI generates (broken into parts so we can explain each piece):

The provider block — telling Terraform which cloud to use:

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

This is like the cover sheet on a blueprint — it tells the construction crew which jurisdiction they're building in and who authorized the project. The provider block tells Terraform "we're working in DigitalOcean, here's the API token to authenticate." The token itself isn't hardcoded here — it's stored as a variable (more on that in a moment).

The variables block — defining inputs:

variable "do_token" {
  description = "DigitalOcean API token"
  type        = string
  sensitive   = true
}

variable "domain_name" {
  description = "Your domain, e.g. myapp.com"
  type        = string
}

variable "region" {
  description = "DigitalOcean region"
  type        = string
  default     = "nyc3"
}

Variables are the blanks on a form — the parts that change between projects or environments. Your API token, your domain name, which region to deploy to. These get set in a separate terraform.tfvars file or as environment variables, so your secrets never live in the blueprint itself. This is important: never commit your terraform.tfvars file to GitHub if it contains real tokens or passwords.

The VPS (Droplet) resource:

resource "digitalocean_droplet" "web" {
  name   = "web-server"
  size   = "s-2vcpu-2gb"
  image  = "ubuntu-22-04-x64"
  region = var.region

  ssh_keys = [data.digitalocean_ssh_key.default.id]

  tags = ["web", "production"]
}

This is your server order form. Size s-2vcpu-2gb means 2 virtual CPUs and 2GB RAM — DigitalOcean's slugs for their server sizes. The image specifies Ubuntu 22.04. The ssh_keys line says "allow access via my registered SSH key." When Terraform runs this, DigitalOcean spins up a server matching this exact spec. Not approximately — exactly.

The managed database:

resource "digitalocean_database_cluster" "postgres" {
  name       = "app-postgres"
  engine     = "pg"
  version    = "15"
  size       = "db-s-1vcpu-1gb"
  region     = var.region
  node_count = 1
}

resource "digitalocean_database_firewall" "postgres_fw" {
  cluster_id = digitalocean_database_cluster.postgres.id

  rule {
    type  = "droplet"
    value = digitalocean_droplet.web.id
  }
}

This creates a managed PostgreSQL 15 database cluster and a firewall rule that only allows your web server to connect to it. Notice digitalocean_droplet.web.id — Terraform is referencing the server it created above. It knows to create the server first, get its ID, then configure the database firewall with that ID. This dependency management is one of Terraform's most valuable features. You don't have to script "first do this, then do that." Terraform figures out the order from the references.

The DNS records:

resource "digitalocean_domain" "default" {
  name = var.domain_name
}

resource "digitalocean_record" "www" {
  domain = digitalocean_domain.default.id
  type   = "A"
  name   = "www"
  value  = digitalocean_droplet.web.ipv4_address
}

resource "digitalocean_record" "root" {
  domain = digitalocean_domain.default.id
  type   = "A"
  name   = "@"
  value  = digitalocean_droplet.web.ipv4_address
}

This sets up DNS so that yourdomain.com and www.yourdomain.com point to your server's IP address. Again, Terraform references digitalocean_droplet.web.ipv4_address — the actual IP that gets assigned when the server is created. You don't have to manually copy-paste an IP address from one place to another. Terraform handles the wiring.

Outputs — getting the info you need afterward:

output "server_ip" {
  value = digitalocean_droplet.web.ipv4_address
}

output "database_url" {
  value     = digitalocean_database_cluster.postgres.uri
  sensitive = true
}

After Terraform builds everything, outputs print the key information you need: your server's IP address, your database connection URL. These are your handoff documents — the information you'll need to configure your application.

The Plan/Apply Workflow: Measure Twice, Build Once

This is the part of Terraform that separates it from just running a shell script. Before Terraform changes anything, you get to see exactly what it's going to do.

The workflow has three commands:

# Step 1: Download the providers (one-time setup)
terraform init

# Step 2: Preview what will change — nothing gets built yet
terraform plan

# Step 3: Build it
terraform apply

terraform init downloads the provider plugins — the DigitalOcean adapter in our example. Think of this as getting your tools before the job starts. You run this once when you first set up a project or when someone adds a new provider.

terraform plan is where Terraform does a dry run. It reads your .tf files, checks what already exists (by reading the state file), and shows you exactly what it intends to create, modify, or destroy. The output looks like this:

Terraform will perform the following actions:

  # digitalocean_droplet.web will be created
  + resource "digitalocean_droplet" "web" {
      + id     = (known after apply)
      + image  = "ubuntu-22-04-x64"
      + name   = "web-server"
      + region = "nyc3"
      + size   = "s-2vcpu-2gb"
    }

  # digitalocean_database_cluster.postgres will be created
  + resource "digitalocean_database_cluster" "postgres" {
      + engine     = "pg"
      + name       = "app-postgres"
      + node_count = 1
      + size       = "db-s-1vcpu-1gb"
      + version    = "15"
    }

Plan: 6 to add, 0 to change, 0 to destroy.

The + sign means "will be created." A ~ means "will be modified." A - means "will be destroyed." Read this output carefully before you proceed. That - symbol next to a database resource is not something you want to casually approve.

In construction terms: terraform plan is the final blueprint walkthrough with the client before groundbreaking. Everyone sees exactly what's going to be built. Changes here are free. Changes after apply cost money and time.

terraform apply executes the plan. It shows you the same plan output and then asks you to type yes to confirm. After confirmation, it starts building — creating resources, waiting for each one to finish, then moving to the next. When it's done, your infrastructure exists.

To tear everything down later (useful for dev environments, expensive if you do it by accident in production):

# This destroys EVERYTHING Terraform created
# Only run this when you mean it
terraform destroy

The plan/apply pattern is also why AI-generated Terraform is much safer than AI-generated scripts. A script just runs. Terraform shows you what it's going to do first. You get a chance to catch mistakes before they happen.

State Files: Terraform's Memory

Here's the concept that trips up almost everyone the first time: the state file.

When Terraform builds your infrastructure, it saves a record of everything it created in a file called terraform.tfstate. This file is Terraform's memory. It maps the resources in your .tf files to the real things that exist in the cloud.

Think about it this way. Your blueprint says "build a server called web-server." DigitalOcean builds that server and assigns it ID 1234567 and IP address 157.90.1.23. The state file records: "the resource digitalocean_droplet.web in my code corresponds to DigitalOcean Droplet ID 1234567."

The next time you run terraform plan, Terraform checks the state file against what you currently have in your .tf files. If nothing changed, it says "no changes needed." If you changed the server size in your .tf file, it says "I need to resize this server." It knows which server to resize because the state file told it which real-world resource maps to that code.

Without the state file, Terraform can't tell the difference between "this resource was already built" and "this resource needs to be built." It would try to create everything from scratch on every run, potentially creating duplicates — and incurring double the cloud costs.

The Rules for State Files

Here are the things you need to know to avoid state file disasters:

Never delete the state file. If you delete terraform.tfstate, Terraform loses track of everything it built. It won't destroy the real infrastructure — those servers and databases keep running and costing you money — but Terraform will think they don't exist and try to create everything again. You'll end up with duplicate infrastructure and a confusing mess to clean up.

Never edit the state file by hand. It's JSON, so it looks editable. It's not. Manually editing it almost always corrupts it. If you need to modify Terraform's understanding of state, use terraform state commands.

Don't commit the state file to a public GitHub repo. The state file often contains sensitive information — IP addresses, database connection strings, sometimes even credentials. Add terraform.tfstate and terraform.tfstate.backup to your .gitignore.

For anything beyond a solo project, use remote state. If you're working with a team or want state backed up properly, store it in a remote backend. Terraform supports storing state in AWS S3, Google Cloud Storage, HashiCorp's Terraform Cloud, and others. Remote state means the file lives in the cloud, everyone on your team shares the same version, and it doesn't disappear when your laptop dies.

# Storing state in S3 (add this to your terraform block)
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"
  }
}

For a solo side project, the default local state file is fine. For anything with multiple environments or collaborators, remote state is worth the setup.

Alternatives: Pulumi and CloudFormation

Terraform isn't the only infrastructure-as-code tool. Two others come up constantly, and it's worth knowing when each one makes sense.

Pulumi

Pulumi does the same thing as Terraform — declare cloud infrastructure in code and have it built automatically — but with one major difference: you write it in real programming languages. TypeScript, Python, Go, C#. Whatever you already know.

// Pulumi in TypeScript — same infrastructure, different syntax
import * as digitalocean from "@pulumi/digitalocean";

const droplet = new digitalocean.Droplet("web-server", {
  image: "ubuntu-22-04-x64",
  region: "nyc3",
  size: "s-2vcpu-2gb",
});

export const serverIp = droplet.ipv4Address;

If you already code in TypeScript or Python, Pulumi can feel more natural. You get real loops, real conditionals, real functions — not HCL's limited templating. You can also use your existing package ecosystem and IDE tooling.

The tradeoff: Terraform has a much larger community, more examples online, and AI tools generate Terraform more reliably than Pulumi (though Pulumi support is improving fast). For most vibe coders starting out, Terraform is the better first choice.

AWS CloudFormation

CloudFormation is AWS's built-in infrastructure-as-code tool. It's tightly integrated with AWS services and free to use (you don't need a separate CLI or account). If you're 100% committed to the AWS ecosystem, it works.

The downsides are significant though. CloudFormation uses verbose YAML or JSON syntax that's genuinely painful to write by hand. It's AWS-only — you can't use it to manage a DigitalOcean database or a Cloudflare DNS record. And debugging CloudFormation failures is notoriously difficult.

# CloudFormation equivalent — much more verbose
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.small
      ImageId: ami-0c55b159cbfafe1f0
      Tags:
        - Key: Name
          Value: web-server

Terraform has largely eaten CloudFormation's mindshare outside of large enterprises that are deeply locked into AWS. For vibe coders, Terraform is almost always the better starting point — it works everywhere, has better tooling, and AI generates it more accurately.

The Decision Table

Use Terraform when: You're working across multiple cloud providers, you want the largest community and most examples, or your AI is generating .tf files and you need to understand and modify them.

Use Pulumi when: You're already comfortable with TypeScript or Python and want to use real language features for complex infrastructure logic.

Use CloudFormation when: You're on a team already heavily invested in AWS tooling and there's an organizational reason to stay within the AWS ecosystem.

When You Actually Need Terraform (And When You Don't)

This is the honest part that most Terraform tutorials skip: for a lot of what vibe coders build, Terraform is overkill. Reaching for it when you don't need it adds complexity that slows you down. Not reaching for it when you do need it leads to infrastructure you can't reproduce and can't audit.

Here's a practical guide.

You probably don't need Terraform if:

• You're deploying to Railway, Render, or Fly.io. These platforms handle the underlying infrastructure for you. You push your code, they handle the servers, databases, networking. Their own config files (railway.toml, fly.toml) serve a similar purpose within their ecosystems. There's nothing to Terraform.
• You're hosting static sites on Vercel or Netlify. These platforms exist specifically to remove infrastructure from the equation. Your vercel.json or Netlify config is enough.
• You have one server and one database and you set them up manually. If your infrastructure is simple enough to set up in 20 minutes by hand, Terraform adds more overhead than it saves.
• You're building a prototype or MVP. Speed matters more than reproducibility at this stage. Managed platforms and dashboards are fine.

You probably do need Terraform if:

• You have multiple environments. Staging, production, maybe a QA environment. Terraform lets you use the same code to spin up matching environments reliably. Without it, staging and production gradually diverge in invisible ways.
• You're working on a client project. Infrastructure you built for a client needs to be documented, reproducible, and transferable. Terraform is documentation that also runs.
• You need to recreate infrastructure after a disaster. If your server dies tomorrow and you don't have Terraform, you're rebuilding from memory. With Terraform, you run terraform apply and it rebuilds everything exactly as it was.
• You're managing more than 3-4 cloud resources. Once you have a server, database, load balancer, CDN, DNS, and monitoring service all in play, keeping track of how they're configured and connected is genuinely hard without code.
• You're deploying on raw cloud providers. If you're working directly in AWS, GCP, or Azure — not through a platform layer like Railway — Terraform is the professional standard.

A useful way to think about it: Terraform is worth the investment when the cost of rebuilding or debugging your infrastructure manually is higher than the cost of learning Terraform. For a side project on Railway, that calculation never tips toward Terraform. For a production SaaS with paying customers, it almost always does.

Working With AI-Generated Terraform: What to Check

When your AI generates Terraform files, it's usually doing a pretty good job. Terraform is one of the areas where AI tools are genuinely reliable — the patterns are well-established, HCL syntax is consistent, and there are millions of examples in the training data.

That said, here's what to check before you run terraform apply on AI-generated code:

1. Look for hardcoded secrets. The AI should be using variables for API tokens, passwords, and keys — not putting them directly in the resource definitions. If you see a raw API key or password anywhere in the .tf files, that's a problem. Refactor it into a variable before you commit or run anything.

2. Check the resource sizes. Cloud resources cost money. The AI picks reasonable defaults, but double-check server sizes and database tiers. A managed database cluster at the wrong tier could add $100/month to your bill. The AI doesn't know your budget.

3. Understand the destroy behavior. Some Terraform resources, when changed, can only be updated by destroying and recreating them. Databases are the scary case — changing certain properties on a database resource can trigger a destroy-then-create cycle, wiping your data. Look for lifecycle blocks in the generated code:

resource "digitalocean_database_cluster" "postgres" {
  # ...
  lifecycle {
    prevent_destroy = true  # Terraform will error rather than destroy this
  }
}

If the AI didn't add prevent_destroy = true to your database resource, add it manually before running anything in production.

4. Review the plan output carefully. Before you type yes on terraform apply, read the full plan. Count the resources being created. Make sure nothing is being unexpectedly destroyed. The one minute you spend reading the plan can prevent hours of recovery work.

Terraform works alongside other infrastructure concepts you should understand. Docker handles packaging and running your app; Terraform handles building the environment the app runs in. Understanding both is what gives you genuine control over your production stack.

What to Learn Next

Terraform makes most sense when you understand what it's building. Here's where to go from here:

• What Is a VPS? — Terraform most commonly creates virtual private servers. Understanding what a VPS actually is — and what it means to "own" a server in the cloud — makes Terraform resource definitions much more concrete.
• What Is Docker? — Docker and Terraform are the two most common tools in a production deployment stack. Docker packages your app; Terraform builds the environment. Understanding both is worth the investment.
• What Are Environment Variables? — Terraform variables and application environment variables work differently, but the same principle applies: secrets and configuration belong outside your code. Understanding the distinction helps you structure both correctly.
• What Is CI/CD? — Once you have Terraform managing your infrastructure, the next step is automating infrastructure changes through your deployment pipeline. CI/CD is how that works.
• What Is DNS? — Terraform frequently manages DNS records. Understanding what DNS actually does — how domain names map to IP addresses — helps you understand what those digitalocean_record resources are accomplishing.

Frequently Asked Questions