The distinct roles of terraform init, terraform fmt, and terraform validate in a Terraform configuration workflow.
terraform init, terraform fmt, and terraform validate support different parts of authoring a Terraform configuration. None creates infrastructure by itself. HashiCorp’s CLI guidance describes fmt as canonical formatting and validate as a configuration check; the init reference covers working-directory preparation.
| Command | What it does | What it does not do |
|---|---|---|
terraform init |
Initializes backend settings and installs required providers and modules. | Plan or apply infrastructure changes. |
terraform fmt |
Rewrites Terraform configuration into Terraform’s canonical style. | Verify provider credentials, resource semantics, or remote changes. |
terraform validate |
Checks configuration syntax and internal consistency, including argument names and types. | Inspect the change Terraform would make to real infrastructure. |
After cloning a configuration, run terraform init before using the normal plan, apply, or destroy commands. It is safe to run again when requirements, modules, or backend settings change, though a changed backend can require careful migration decisions. Do not casually use -reconfigure or -migrate-state without understanding the backend change.
During editing, use terraform fmt to make formatting predictable and terraform validate as a fast local check. Plan and apply also validate configuration, but validation alone cannot detect every provider-side error and does not compare desired configuration with remote infrastructure. Follow validation with a plan in the intended workspace.
1terraform init
2terraform fmt -check -recursive
3terraform validate
4terraform plan
The -check flag makes fmt report files that need formatting without rewriting them, which is useful in continuous integration. Run plain terraform fmt -recursive when the goal is to apply the canonical formatting.
Validation happens against the configuration available locally. It can identify an invalid argument or an incompatible expression, but it does not prove that credentials are authorized, that an API will accept a request, or that a planned change is safe for production. A provider may need remote information before it can fully evaluate a change, so treat a successful validation as an early check rather than deployment approval.
init installs and records.