Installing Terraform and the CLI

Terraform ships as a single static binary with no runtime dependency — no language interpreter to install, nothing to compile. Getting it onto a machine is genuinely trivial, which is why this topic spends most of its time on the part that actually causes trouble: keeping everyone on a team running the same version so their plans agree.

A version mismatch is not cosmetic. A newer Terraform can write a state file an older one refuses to read, and two versions can plan the same configuration differently. The install is a five-minute job; version discipline is the lesson worth keeping.

Installing the Binary

On Linux, add HashiCorp's official apt or yum repository and install the terraform package. On macOS, use Homebrew's HashiCorp tap. On Windows, use the installer or a package manager like Chocolatey. In every case the result is one binary on your PATH; confirm it with terraform version, which prints both the core version and the versions of any installed providers.

Avoid installing from a random script or an unofficial package — those drift stale and can miss the features your configuration relies on. When you install outside the official repos, verify the download's checksum and signature, because this binary will hold credentials and change your infrastructure.

Version Management Across a Team

Different engineers running different Terraform versions is the quiet source of "works on my machine" infrastructure bugs. Two tools solve it: a version manager like tfenv or mise that pins and switches the version per project automatically, and the required_version setting inside the configuration, which makes Terraform refuse to run under a version outside the allowed range.

The block below pins both the Terraform core version and a provider version. With this committed, anyone — including CI — who runs an incompatible Terraform gets a clear, early error instead of a subtly different plan. Pin the version on day one; retrofitting it after a state file has been written by several versions is harder.

terraform {
  required_version = "~> 1.13"          # require Terraform 1.x at this minor or newer
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

The Command Surface

The daily vocabulary is small. init downloads providers and sets up the backend; plan previews changes; apply makes them; destroy tears them down. Around those four sit fmt (format), validate (check consistency), state (inspect and surgically edit state), and output (read computed values). That is nearly the entire set of commands you use in a normal week; the rest are specialized tools you reach for occasionally.

CLI Configuration and Shell Integration

A few settings, configured once, smooth daily use. The CLI configuration file (.terraformrc) can define a shared plugin cache so providers are downloaded once and reused across projects, point at provider mirrors for air-gapped environments, and set credentials helpers. Tab completion and the TF_* environment variables (such as TF_VAR_ for inputs and TF_LOG for debugging) round out the setup.

One flag worth knowing early is -chdir, which runs Terraform against another directory without first cd-ing into it. It is safer than changing directories by hand, where it is easy to run the wrong environment's configuration from the wrong place.