Before planning a new AWS instance, initialize the working directory with `terraform init`. It prepares the directory for Terraform commands; it does not create the instance. The usual deployment flow is to initialize, inspect a plan, and then apply the reviewed changes. section 1.4 section 2.1.6
Initialization sets up the backend first. A backend stores Terraform state; the default local backend is sufficient for a simple starting project. Terraform then installs the required providers and any modules. Providers and modules can come from the public Terraform Registry or a configured private registry. section 1.4.2 section 2.4.1
Initialize an AWS working directory
Run `terraform init` after writing a configuration that requires `hashicorp/aws` at `~> 4.0`. The example output initializes the backend, installs AWS provider v4.41.0, and creates `.terraform.lock.hcl` to record the provider selection. Commit that lock file so future initialization uses the same selection by default. Configure AWS access before proceeding to `terraform plan`; review the plan before `terraform apply`. section 1.4.2 section 2.1.6
Listing 1.1 Initializing a Terraform project
$ terraform init #1 Initializing the backend... #2 Initializing provider plugins... #3 - Finding HashiCorp/aws versions matching "~> 4.0"... #4 - Installing HashiCorp/aws v4.41.0... #5 - Installed HashiCorp/aws v4.41.0 (signed by HashiCorp) #6 Terraform has created a lock file .terraform.lock.hcl to record the provider selections it made above. Include this file in your version control repository so that Terraform can guarantee to make the same selections by default when you run "terraform init" in the future. Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.
The CLI output shows the order of backend and provider initialization, the selected provider version, and the lock-file guidance. section 1.4.2
Reinitialize when the working directory’s setup changes, and choose backend options deliberately:
- Run `terraform init` again after changing modules or backend configuration. A module referenced from a Git repository is downloaded and installed during initialization. section 2.1.6 section 3.8.5
- If a changed backend is detected, initialization stops and suggests `-migrate-state` to move the current state or `-reconfigure` to start fresh with the new backend. Older state versions are not migrated automatically. section 6.4.6
- For automated `terraform validate` checks that do not need a backend, use `terraform init -backend=false`. A Make target can use the resulting `.terraform` directory to avoid repeating initialization unnecessarily. section 7.3.1
A CLI wrapper can expose common initialization options, such as a backend configuration file or disabled backends, while passing through additional flags. This keeps the same initialization step available in automated workflows. section 11.1.3
