mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-04-15 18:01:09 -04:00
ddf9635af6
We typically try to avoid making subjective, boasty claims in our documentation in recent times, but there remained both some older documentation that we've not recently revised and also some newer examples that are, in retrospect, also perhaps more "boasty" than they need to be. We prefer not to use this sort of boasty language because not everyone using Terraform has the same background and experience, and so what is "easy" or "intuitive" to one person may not be so to another person, and that should not suggest that the second person is in any way wrong or inadequate. In reviewing some of our use of the word "easy" here I tried as much as possible to surgically revise the existing content without getting drawn into a big rewrite, but in some cases the content was either pretty unsalvageable (due to talking about obsolete features that were removed long ago) or required some broader changes to make the result hopefully still get the same facts across. In those cases I've both removed some content entirely or adjusted larger paragraphs. This was not an exhaustive review and so I'm sure there's still plenty of room for similar improvements elsewhere. I also resisted the urge to update some pages that contain outdated information about currently-active features.
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "State: Remote Storage"
|
|
sidebar_current: "docs-state-remote"
|
|
description: |-
|
|
Terraform can store the state remotely, making it easier to version and work with in a team.
|
|
---
|
|
|
|
# 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](https://www.hashicorp.com/products/terraform/),
|
|
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
|
|
|
|
Remote state is a feature of [backends](/docs/backends), which you can activate
|
|
in your configuration's root module.
|
|
|
|
## Delegation and Teamwork
|
|
|
|
Remote state allows you to share
|
|
[output values](/docs/configuration/outputs.html) 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](/docs/providers/terraform/d/remote_state.html).
|
|
|
|
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](https://www.consul.io/) then you
|
|
can have one Terraform configuration that writes to Consul using
|
|
[`consul_key_prefix`](/docs/providers/consul/r/key_prefix.html) and then
|
|
another that consumes those values using
|
|
[the `consul_keys` data source](/docs/providers/consul/d/keys.html).
|
|
|
|
## Locking and Teamwork
|
|
|
|
For fully-featured remote backends, Terraform can also use
|
|
[state locking](/docs/state/locking.html) to prevent concurrent runs of
|
|
Terraform against the same state.
|
|
|
|
[Terraform Cloud by HashiCorp](https://www.hashicorp.com/products/terraform/)
|
|
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.
|