Skip to main content
By default, Terraform stores its state locally in a file named terraform.tfstate inside the working directory that contains your Terraform configuration files. That state file records Terraform’s current view of the resources it manages and is essential for planning and applying changes. Terraform also needs to prevent concurrent writes to the state file while operations that modify state are running. Whether locking is available depends on the backend you select:
  • The local backend (default) does not provide state locking.
  • Many remote backends provide locking (or can be combined with a locking mechanism) to prevent concurrent modifications.
In a team or CI environment, choose a backend that supports locking so multiple users or systems don’t overwrite each other’s changes — the process that obtains the lock proceeds while others wait. Here is an abbreviated example excerpt you might find inside a terraform.tfstate file:
Remote state storage is recommended — and often required — when collaborating. A remote backend lets multiple users and CI systems share the same state safely and enables features such as state locking, versioning, and access controls. Common remote backends and their typical uses: Minimal example: backend configuration for an S3 remote backend (place in a backend block inside terraform configuration):
An infographic titled "Terraform — Remote State" showing Terraform configuration files (main.tf, providers.tf) feeding into the Terraform engine to create cloud resources (AWS, Azure). It also shows the default local state file (terraform.tfstate) and optional remote backend options like Amazon S3, Azure Blob, and HCP Terraform.
Note that when you move from working locally to collaborating with others, you should configure a remote backend that supports locking and state management. If you work alone on a machine, the default local terraform.tfstate file is acceptable for quick experiments.
Use a remote backend with locking (for example, S3 + DynamoDB or Terraform Cloud) when multiple people or automated systems will run Terraform against the same state to avoid conflicts and corruption.
If you’re ready to adopt a remote backend, next steps typically include:
  • Choosing a backend that fits your cloud and team needs (see table above).
  • Creating the remote storage resource (e.g., S3 bucket, Azure storage account, GCS bucket).
  • Optionally creating a locking resource (e.g., DynamoDB table for S3).
  • Configuring the terraform block with the appropriate backend stanza.
  • Migrating existing local state to the remote backend with terraform init and the migration prompts, or using terraform state commands when necessary.
Links and references

Watch Video