🚨 Terraform Error Guide: 'Backend initialization required, please run "terraform init"' — Re-Init the Backend

Overview

Terraform records how a working directory’s state is stored in .terraform/terraform.tfstate (the backend state stub) and caches the resolved backend settings there during terraform init. Before any command that needs state — plan, apply, state, import — Terraform compares your current backend/cloud configuration against that cached copy. If there is no cached backend, or the configured backend no longer matches what was initialized, Terraform stops and demands a re-init:

Error: Backend initialization required, please run "terraform init"

Reason: Initial configuration of the requested backend "s3"

The "backend" is the interface that Terraform uses to store state and perform
operations. This may be caused by the following reasons:
 - You have added a new backend configuration to an existing configuration.
 - You have changed the backend configuration for an existing configuration.
 - The backend configuration is unchanged, but the .terraform directory has been
   removed or corrupted.

Please run "terraform init" with either the "-reconfigure" or "-migrate-state"
flags to use the current configuration.

The Reason: line varies — Initial configuration of the requested backend "s3", Backend configuration changed, or similar — but the header and remedy are constant: the on-disk backend cache and your configuration disagree, and only terraform init can reconcile them.

Symptoms

• terraform plan / apply / state list fails instantly with Backend initialization required, please run "terraform init".
• The Reason: line mentions either an initial configuration of a backend or that the backend configuration changed.
• It appears right after adding a backend "s3" {} (or gcs, azurerm, remote, cloud) block to a previously local-state project.
• It appears in CI on a fresh checkout where the .terraform/ directory was never created (it is, correctly, git-ignored).
• It appears after someone deleted .terraform/ to “clean up,” or after switching git branches where the backend config differs.

Common Root Causes

• A backend block was added to a configuration that previously used local state (or no explicit backend).
• The backend configuration changed — a different S3 bucket/key/region, a new GCS bucket, a renamed Terraform Cloud workspace, or a switch between backend types.
• .terraform/ is missing or corrupted — a fresh clone, a cleaned CI runner, a deleted directory, or an interrupted previous init.
• Partial backend config drift — values passed via -backend-config (files or KEY=VALUE) changed between runs, so the cached settings no longer match.
• Switching branches / workspaces where the committed backend block differs from what was last initialized locally.
• Upgrading or migrating from a local backend to a remote one, which requires an explicit state migration decision.

Diagnostic Workflow

First confirm whether the backend cache even exists and what it thinks is configured:

ls -la .terraform/
cat .terraform/terraform.tfstate     # shows the currently-initialized backend
terraform version

Look at the backend block your configuration declares now:

terraform {
  backend "s3" {
    bucket         = "acme-tfstate"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "acme-tf-locks"
    encrypt        = true
  }
}

If .terraform/terraform.tfstate points at a different bucket/key than the block above, the backend changed and you must decide whether to migrate existing state or reconfigure fresh. The two remedies do very different things:

# Fresh checkout / missing .terraform, config unchanged -> plain init is enough
terraform init

# Backend settings changed and you WANT to copy existing state to the new backend
terraform init -migrate-state

# Backend settings changed and you want to IGNORE the old cache (no state copy)
terraform init -reconfigure

For partial-config setups, supply the missing values so the cached settings match again:

terraform init -backend-config=backend-prod.hcl
terraform init -backend-config="bucket=acme-tfstate" -backend-config="key=prod/network/terraform.tfstate"

Example Root Cause Analysis

A project ran happily on local state during prototyping. To share state across the team, an engineer added an S3 backend block and immediately ran terraform plan:

terraform {
  backend "s3" {
    bucket = "acme-tfstate"
    key    = "prod/network/terraform.tfstate"
    region = "us-east-1"
  }
}

plan failed with Backend initialization required ... Reason: Initial configuration of the requested backend "s3". Terraform had never initialized any backend for this directory, so its cache still described the implicit local backend. The engineer ran:

terraform init -migrate-state

Terraform detected the existing terraform.tfstate local file and prompted:

Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. ...
  Enter "yes" to copy and "no" to start with an empty state.

Answering yes copied the local state into the S3 bucket, and subsequent plan/apply ran against the remote backend. A week later a CI job hit the same error on a clean runner — but there the fix was simply terraform init (no migration), because the backend config was unchanged and only the git-ignored .terraform/ directory was absent.

Prevention Best Practices

• Always run terraform init on a fresh checkout — .terraform/ is (correctly) git-ignored, so CI and new clones must initialize before any other command. Make init the first step of every pipeline.
• Use -migrate-state deliberately when moving state to a new backend, and confirm the copy prompt; use -reconfigure only when you intend to discard the old backend association.
• Externalize environment-specific settings with partial backend config (-backend-config=env.hcl) instead of hard-coding, so the same code initializes cleanly per environment.
• Never hand-delete .terraform/ to “fix” problems on a shared machine mid-operation; if you do, follow with a plain terraform init.
• Pin backend values in version control and review changes to the backend block carefully — any change forces a reconfigure/migrate decision for everyone.
• Add terraform init -input=false early in CI so missing initialization fails fast and loud rather than surfacing deep in a plan.

Quick Command Reference

# Standard initialization (fresh clone, unchanged backend)
terraform init

# CI-friendly: never prompt
terraform init -input=false

# Backend changed and you want to copy existing state across
terraform init -migrate-state

# Backend changed and you want to drop the old association (no copy)
terraform init -reconfigure

# Supply partial/omitted backend settings
terraform init -backend-config=backend-prod.hcl
terraform init -backend-config="key=prod/network/terraform.tfstate"

# Inspect what backend is currently initialized
cat .terraform/terraform.tfstate

# Re-init and upgrade providers at the same time
terraform init -upgrade

Conclusion

Backend initialization required means the backend Terraform has cached in .terraform/ does not match the backend your configuration currently declares — because you added a backend, changed it, or the cache directory is gone. The remedy is always terraform init, but which flags matter: a plain init on a fresh checkout, -migrate-state when you want to carry existing state to a new backend, and -reconfigure when you want to ignore the old association entirely. Make init the unconditional first step of every workflow and pipeline, and this error becomes a one-command fix instead of a mid-apply surprise.