terraform init Command Reference

Initialize a Terraform working directory before any plan or apply.

terraform init downloads providers, installs modules, and configures the backend. It is the first command in every Terraform pipeline and the one CI most often blocks on.

What it does

terraform init prepares a working directory: it installs the providers in required_providers, fetches child modules, configures the backend for remote state, and writes the dependency lock file (.terraform.lock.hcl). It is idempotent and required before plan or apply.

Common flags and usage

• -backend-config=KEY=VALUE or =FILE: supply backend settings from CI instead of hardcoding them
• -reconfigure: ignore saved backend config and reconfigure from scratch
• -migrate-state: move existing state to a newly configured backend
• -upgrade: bump providers and modules to the newest versions allowed by constraints
• -input=false: never prompt (always set this in CI)
• -lockfile=readonly: fail if the lock file would change

Example

# .github/workflows/terraform.yml
- name: Terraform Init
  run: |
    terraform init -input=false \
      -backend-config="bucket=${TF_STATE_BUCKET}" \
      -backend-config="key=prod/terraform.tfstate" \
      -backend-config="region=us-east-1"

In CI

Run init with -input=false so a missing value fails fast instead of hanging on a prompt. Commit a lock file generated for every platform your team and runners use (terraform providers lock -platform=linux_amd64 -platform=darwin_arm64); otherwise Linux CI fails with an inconsistent dependency lock file error. Avoid -upgrade in CI unless you intend to bump versions.

Key takeaways

• init installs providers and modules and configures the backend; it must run before plan or apply.
• Pass backend settings with -backend-config and always set -input=false in CI.
• Lock provider checksums for every CI platform so init is reproducible across runners.

Related guides