Terraform Apply: The Definitive Guide

Terraform is an open-source infrastructure as a code tool that lets you create, change, and improve infrastructure safely and predictably.

The command you’ll reach for most often is terraform apply. It creates, updates, or destroys infrastructure resources. When you run it, Terraform first generates a plan showing what it will do. You can review and approve that plan before anything actually changes.

Why use Terraform Apply?

The main appeal is safety. Terraform uses declarative configuration, so you describe the end state you want and Terraform figures out how to get there. If your configuration says “three EC2 instances running,” Terraform won’t stop until that matches reality.

Your Terraform files live in version control alongside your application code. This means you get a full audit trail of infrastructure changes and can roll back if something goes wrong.

Automation fits naturally. You can hook Terraform into your CI/CD pipeline to deploy infrastructure changes automatically. In practice, this means no more “someone manually changed a server and now nobody knows why it’s broken.”

When to use Terraform Apply?

Any time you want to change infrastructure. Creating new resources, modifying existing ones, or tearing things down when you don’t need them anymore.

How to use Terraform Apply

First, make sure Terraform is installed. Then navigate to your project directory and run:

terraform apply main.tf

Terraform will show you a plan and wait for confirmation. Press Enter to approve, or Ctrl+C to bail out.

Examples

Create an EC2 instance

Add this to your Terraform file:

resource "aws_ec2_instance" "example" {
  ami = "ami-0123456789abcdef0"
  instance_type = "t2.micro"
}

Then run terraform apply. Terraform talks to AWS, creates the instance, and records the result in its state file.

Update an existing instance

Change the configuration and apply again:

resource "aws_ec2_instance" "example" {
  ami = "ami-0123456789abcdef0"
  instance_type = "t2.micro"
  name = "my-instance"
}

Destroy an instance

Remove the resource block from your configuration and run terraform apply. Terraform sees the desired state no longer includes the instance and destroys it.

You can also use terraform destroy, which is effectively terraform apply -destroy under the hood. Both approaches work; pick whatever makes sense to you.

Initialize first

Before applying for the first time in a new project, run:

terraform init

This downloads the provider plugins Terraform needs and sets up the working directory.

Preview with plan

Run terraform plan to see what would change without actually making changes. Useful for review workflows or when you’re unsure what Terraform thinks should happen.

How terraform apply works

When you run terraform apply, Terraform follows a specific sequence:

1. Reads your configuration - Terraform loads your .tf files and figures out what resources you want and how they depend on each other.

2. Reads current state - Terraform checks its state file, which records what’s actually running right now. If you’re using a remote backend, it fetches the latest state from there.

3. Compares desired vs. actual - Terraform diffs your configuration against the current state. If you want 3 instances and AWS shows 2, it knows to create one more.

4. Generates an execution plan - Before touching anything, Terraform writes out exactly what it plans to do: create this, update that, destroy this other thing.

5. Executes the plan - Terraform makes API calls to your provider (AWS, GCP, Azure, etc.) to bring reality in line with your configuration. It updates its state file as changes complete.

The key insight is that Terraform always works toward the desired state you declared. If something already matches your configuration, Terraform leaves it alone. If it doesn’t match, Terraform changes it.

Wrapping up

terraform apply is the workhorse command in any Terraform workflow. The plan-then-act pattern means you always know what you’re agreeing to before AWS, GCP, or Azure actually changes. That visibility alone has saved many teams from making infrastructure changes they didn’t intend.