Terraform Basics for Developers Who Need to Manage Infrastructure

Terraform is infrastructure as code: it lets you define servers, databases, DNS records, and certificates in text files that you commit to git, review in pull requests, and apply with a single command. As an application developer, you should know enough Terraform to manage your own infrastructure without depending entirely on a dedicated ops person.

What Problem Terraform Solves

Without infrastructure as code, infrastructure is configured manually through cloud provider dashboards. This creates two problems: the configuration is invisible (nobody knows exactly what settings were chosen without logging into every dashboard) and it is not reproducible (recreating the same infrastructure for a new environment requires remembering every manual step).

Terraform solves both problems. Your infrastructure configuration is in HCL (HashiCorp Configuration Language) files. Those files are committed to git. To recreate your entire infrastructure in a new environment, you run terraform apply. To make a change, you edit a file, review the diff, and apply it.

Core Concepts

Providers: Terraform providers are plugins that know how to create resources in a particular service. There are providers for AWS, Google Cloud, Azure, Vercel, Cloudflare, GitHub, PlanetScale, Stripe, and hundreds more. Each provider is declared in your Terraform configuration and downloaded by terraform init.

terraform {
  required_providers {
    vercel = {
      source  = "vercel/vercel"
      version = "~> 1.0"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

Resources: resources are the things you create: a Vercel project, a Cloudflare DNS record, an Upstash Redis instance. Each resource has a type (from the provider) and a configuration block.

resource "vercel_project" "web" {
  name      = "my-app"
  framework = "nextjs"

  git_repository = {
    type = "github"
    repo = "myorg/my-app"
  }
}

Data sources: data sources read existing resources that Terraform did not create. Useful for referencing a zone ID in Cloudflare without hard-coding it.

data "cloudflare_zone" "main" {
  name = "example.com"
}

Variables: parameterize your configuration so the same code works for different environments (staging, production) with different values.

variable "environment" {
  type    = string
  default = "production"
}

Outputs: expose values from your Terraform resources for use in other systems or by humans:

output "deployment_url" {
  value = vercel_project.web.url
}

The Workflow: init, plan, apply, destroy

terraform init: downloads the required providers and initializes the working directory. Run this once when setting up the project, and again when you add new providers.

terraform plan: Terraform reads your configuration, compares it to the current state of your infrastructure, and shows you what changes would be made. This is a dry run. No changes are made. Read the plan carefully before applying.

terraform apply: applies the changes shown in the plan. Terraform prompts you to confirm before making any changes. After you confirm, it creates, updates, or destroys resources to match your configuration.

terraform destroy: destroys all resources managed by your configuration. Use carefully.

State Management

Terraform tracks what it has created in a state file (terraform.tfstate). This file maps your HCL configuration to real-world resource IDs. Without it, Terraform does not know what exists.

Why local state is dangerous for teams: if two team members apply Terraform simultaneously from their local machines with different state files, they will create conflicting resources or destroy each other's changes. State must be shared.

Remote state: store state in a backend that supports locking. The most common options:

• S3 + DynamoDB: store the state file in an S3 bucket, use DynamoDB for locking. The traditional AWS approach.
• Terraform Cloud: HCP Terraform (formerly Terraform Cloud) provides remote state, locking, and a web UI for plan/apply history. Free tier includes 500 resource hours per month.
• GitLab CI / GitHub Actions backend: some CI providers offer Terraform state backends natively.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
  }
}

Real Use Case: Next.js App with Vercel + Cloudflare + Upstash

A practical example of what Terraform manages for a Next.js application:

# Vercel project
resource "vercel_project" "web" {
  name      = "my-nextjs-app"
  framework = "nextjs"
}

# Environment variables for the Vercel project
resource "vercel_project_environment_variable" "redis_url" {
  project_id = vercel_project.web.id
  key        = "UPSTASH_REDIS_REST_URL"
  value      = upstash_redis_database.cache.rest_url
  target     = ["production", "preview"]
}

# Upstash Redis database
resource "upstash_redis_database" "cache" {
  database_name = "my-app-cache"
  region        = "us-east-1"
  tls           = true
}

# Cloudflare DNS pointing to Vercel
resource "cloudflare_record" "web" {
  zone_id = data.cloudflare_zone.main.id
  name    = "app"
  value   = "cname.vercel-dns.com"
  type    = "CNAME"
  proxied = true
}

Running terraform apply creates all of this in one command. Running it again after changing the Redis region updates only the Redis database. Running terraform plan before any change shows exactly what will be modified.

When Terraform Is Overkill

Terraform adds overhead. For a single-developer project or a simple app with one deployment, managing everything through the Vercel and Cloudflare dashboards is faster and simpler. The complexity of Terraform becomes worthwhile when:

• You have multiple environments (staging and production) that need identical configuration
• Multiple team members need to make infrastructure changes safely
• You need to recreate your infrastructure reproducibly (disaster recovery, new region)
• Your infrastructure is complex enough that the dashboard-clicking approach loses track of what was changed and when

When Terraform Is Essential

For any team beyond two or three developers, Terraform (or an equivalent tool like Pulumi) is essential. Infrastructure changes become part of your normal code review process. You catch mistakes before they hit production. You have an audit log of every infrastructure change. And you can on-board new engineers to your infrastructure without giving them dashboard access to click through.

Keep Reading

• Vercel vs Cloudflare Pages vs Netlify - the platforms Terraform manages
• GitHub Actions Guide for Developers - running Terraform in CI/CD pipelines
• Coolify vs Fly.io vs Render - self-hosted alternatives if you want to avoid cloud provider complexity

Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace - chat, projects, time tracking, AI meeting summaries, and invoicing - in one tool. Try it free.