• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Terraform
  • Install
  • Tutorials
    • About the Docs
    • Configuration Language
    • Terraform CLI
    • Terraform Cloud
    • Terraform Enterprise
    • CDK for Terraform
    • Provider Use
    • Plugin Development
    • Registry Publishing
    • Integration Program
  • Registry(opens in new tab)
  • Try Cloud(opens in new tab)
  • Sign up
Terraform Home

Configuration Language

Skip to main content
  • Terraform Language

  • Overview
  • Data Sources
    • Overview
    • Purpose
    • The terraform_remote_state Data Source
    • Backends: State Storage and Locking
    • Import Existing Resources
    • Locking
    • Workspaces
    • Remote State
    • Sensitive Data
  • Upgrading to Terraform v1.3
  • v1.x Compatibility Promises

  • Terraform Internals

  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  • Terraform Registry
    (opens in new tab)
  1. Developer
  2. Terraform
  3. Configuration Language
  4. State
  5. Remote State
  • Terraform
  • v1.2.x
  • v1.1 and earlier

ยปRemote State

By default, Terraform stores state locally in a file named terraform.tfstate. When working with Terraform in a team, use of a local file makes Terraform usage complicated because each user must make sure they always have the latest state data before running Terraform and make sure that nobody else runs Terraform at the same time.

With remote state, Terraform writes the state data to a remote data store, which can then be shared between all members of a team. Terraform supports storing state in Terraform Cloud, HashiCorp Consul, Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.

Remote state is implemented by a backend or by Terraform Cloud, both of which you can configure in your configuration's root module.

Delegation and Teamwork

Remote state allows you to share output values with other configurations. This allows your infrastructure to be decomposed into smaller components.

Put another way, remote state also allows teams to share infrastructure resources in a read-only way without relying on any additional configuration store.

For example, a core infrastructure team can handle building the core machines, networking, etc. and can expose some information to other teams to run their own infrastructure. As a more specific example with AWS: you can expose things such as VPC IDs, subnets, NAT instance IDs, etc. through remote state and have other Terraform states consume that.

For example usage, see the terraform_remote_state data source.

While remote state can be a convenient, built-in mechanism for sharing data between configurations, you may prefer to use more general stores to pass settings both to other configurations and to other consumers. For example, if your environment has HashiCorp Consul then you can have one Terraform configuration that writes to Consul using consul_key_prefix and then another that consumes those values using the consul_keys data source.

Locking and Teamwork

For fully-featured remote backends, Terraform can also use state locking to prevent concurrent runs of Terraform against the same state.

Terraform Cloud by HashiCorp is a commercial offering that supports an even stronger locking concept that can also detect attempts to create a new plan when an existing plan is already awaiting approval, by queuing Terraform operations in a central location. This allows teams to more easily coordinate and communicate about changes to infrastructure.

Edit this page on GitHub

On this page

  1. Remote State
  2. Delegation and Teamwork
  3. Locking and Teamwork
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)