Terraform & OpenTofu: Infrastructure as Code in 2026

Infrastructure as Code (IaC) means describing your cloud -- networks, VMs, databases, DNS, IAM -- in version-controlled text instead of clicking through consoles. Terraform (from HashiCorp, now part of IBM) and its open-source fork OpenTofu (governed by the Linux Foundation) are the two dominant declarative, provider-agnostic IaC tools. You write the desired end state in HashiCorp Configuration Language (HCL); the tool computes the diff against reality and makes the minimal set of API calls to converge.

Both tools are drop-in compatible today: the same HCL, the same providers, the same state format. The core practices that keep IaC safe in production:

• Everything in Git -- Every resource lives in .tf files under version control. The repository is the single source of truth; changes flow through pull requests and code review, never a console.
• Remote, locked state -- Never keep terraform.tfstate on a laptop. Store it in a remote backend (S3, GCS, Terraform Cloud/HCP) with state locking so two applies can never corrupt it.
• Plan before apply -- terraform plan is a dry run. Review the diff -- especially destroys and replacements -- before apply touches anything. In CI, post the plan on the pull request.
• Small, reusable modules -- Factor common patterns (a VPC, a bucket, a GKE cluster) into versioned modules. Compose infrastructure instead of copy-pasting resource blocks.
• Policy & scanning in CI -- Gate applies with policy-as-code (OPA/Conftest, Sentinel) and static scanning (tfsec, Checkov, Trivy) to catch open security groups and public buckets before they ship.

A minimal but complete configuration -- pin the tool version, declare the provider, create one resource:

# main.tf -- works identically on Terraform and OpenTofu
terraform {
  required_version = ">= 1.9"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "state_demo" {
  bucket = "josenobile-iac-demo-2026"
  tags   = { Environment = "dev", ManagedBy = "terraform" }
}

In August 2023 HashiCorp relicensed Terraform from the open-source MPL-2.0 to the Business Source License (BSL/BUSL 1.1) -- a source-available license that forbids using Terraform to build a competing product, converting to open source only four years after each release. The community responded with a fork: OpenTofu, accepted into the Linux Foundation in September 2023 and kept under MPL-2.0. IBM's $6.4B acquisition of HashiCorp closed in February 2025 and did not change the license. As of mid-2026 Terraform ships the 1.14.x line while OpenTofu ships 1.12.x -- the codebases have started to diverge, but everyday HCL still works on both.

HashiCorp Configuration Language (HCL) is declarative: you describe blocks of desired state, and the engine figures out the order of operations from an implicit dependency graph built by reference. You rarely write loops or conditionals imperatively -- for_each, count, and expressions cover most of it.

The building blocks of every configuration:

• Providers -- Plugins that talk to an API (aws, google, azurerm, kubernetes, cloudflare). Declared in required_providers and pinned with a version constraint; downloaded by terraform init.
• Resources & data sources -- resource blocks create/manage objects; data blocks read existing ones. References like aws_vpc.main.id create dependencies automatically.
• Variables -- Typed inputs (variable) with defaults, descriptions, and validation blocks. Set via .tfvars, -var, or TF_VAR_* environment variables.
• Outputs & locals -- output exposes values (and feeds module composition); locals name intermediate expressions so you don't repeat yourself.

Variables, a resource driven by for_each, and an output:

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment environment"
  default     = "dev"
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment must be dev, staging, or prod."
  }
}

variable "bucket_names" {
  type    = set(string)
  default = ["logs", "assets", "backups"]
}

# main.tf
resource "aws_s3_bucket" "app" {
  for_each = var.bucket_names
  bucket   = "josenobile-${var.environment}-${each.key}"
}

# outputs.tf
output "bucket_arns" {
  value = { for k, b in aws_s3_bucket.app : k => b.arn }
}

A module is just a directory of .tf files with inputs (variables) and outputs. Every configuration is already the "root module"; you compose it from child modules to avoid copy-pasting. Modules are how you turn a proven pattern -- a VPC, a database, a Kubernetes cluster -- into a versioned, reviewed, reusable building block shared across teams and environments.

Consuming a registry module and wiring its output into another resource:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 6.0"

  name            = "prod-vpc"
  cidr            = "10.0.0.0/16"
  azs             = ["us-east-1a", "us-east-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
  enable_nat_gateway = true
}

resource "aws_security_group" "app" {
  name   = "app-sg"
  vpc_id = module.vpc.vpc_id   # output from the module
}

State is how Terraform and OpenTofu map your HCL to real-world objects. The state file records resource IDs, attributes, and metadata so the tool knows what it already manages and can compute an accurate diff. Lose or corrupt state and the tool no longer knows what it owns -- so treating state as critical, shared, protected data is the single most important operational discipline in IaC.

Remote backends and locking. A backend defines where state lives. Local state is fine for a solo experiment; a team needs a remote backend so everyone reads and writes the same state. The essential guarantee is state locking: while one apply holds the lock, everyone else blocks, so two people can't mutate infrastructure concurrently and corrupt state. As of Terraform 1.11 / OpenTofu 1.11+, the S3 backend locks natively via a use_lockfile object in the bucket -- the old separate DynamoDB lock table is no longer required (though still supported). GCS locks on the object automatically; HCP Terraform and Terraform Cloud lock server-side.

Encryption & drift. State often contains secrets (DB passwords, keys), so encrypt it at rest -- enable bucket SSE, and on OpenTofu use built-in client-side state encryption so the file is unreadable even to whoever holds the bucket. Detect drift (out-of-band console changes) by running terraform plan (or plan -refresh-only) on a schedule in CI; a non-empty plan means reality diverged from code. Keep versioning on the state bucket so you can roll back a bad write.

The core loop is init → plan → apply. init downloads providers and configures the backend; plan shows exactly what will be created, changed, or destroyed; apply executes it. destroy tears it down. Save a plan to a file and apply that exact plan so what you reviewed is what runs:

terraform init                 # or: tofu init
terraform fmt -recursive       # canonical formatting
terraform validate             # static config check
terraform plan -out=tfplan     # review the diff
terraform apply tfplan         # apply the reviewed plan
terraform destroy              # tear everything down

Terraform ships a native testing framework (generally available since 1.6, with provider/resource mocking added in 1.7; OpenTofu has an equivalent tofu test). Tests live in *.tftest.hcl files and let you assert on plan or apply results without a separate language. This is how you validate modules before publishing them.

• .tftest.hcl files -- Test files sit beside your module (or in tests/). Run them with terraform test; each file contains one or more run blocks executed in order.
• run blocks & assertions -- Each run does a plan or apply and checks assert { condition = ... }. command = plan is fast and hits no cloud; command = apply provisions real (or mocked) resources then tears them down.
• Mocks & overrides -- mock_provider fakes an entire provider so unit tests run offline and free; override_resource/override_data pin specific values. No cloud credentials or spend required for logic tests.
• CI gating -- Run fmt -check, validate, test, and a security scan (tfsec/Checkov) on every pull request. Fail the build on any test or policy violation before the plan is ever reviewed.

A test that mocks the provider (no AWS account needed) and asserts on the plan:

# tests/bucket.tftest.hcl
mock_provider "aws" {}

run "bucket_name_is_prefixed" {
  command = plan

  variables {
    environment  = "prod"
    bucket_names = ["logs"]
  }

  assert {
    condition     = aws_s3_bucket.app["logs"].bucket == "josenobile-prod-logs"
    error_message = "Bucket name was not prefixed with the environment."
  }
}

The safe pattern: run plan automatically on every pull request and post the diff as a comment; run apply only on merge to the main branch, using short-lived cloud credentials via OIDC (never long-lived keys in secrets). Layer policy-as-code on top so risky changes are blocked automatically.

These tools overlap but solve different problems. Terraform/OpenTofu are declarative provisioners for cloud infrastructure. Ansible is a procedural configuration-management and orchestration tool. Pulumi is a declarative provisioner like Terraform but you write it in a general-purpose programming language. Many teams use two together -- Terraform to build the servers and network, Ansible to configure what runs on them.