mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-03-03 05:01:30 -05:00
63 lines
3.1 KiB
Plaintext
63 lines
3.1 KiB
Plaintext
---
|
|
description: >-
|
|
OpenTofu can store the state remotely, making it easier to version and work
|
|
with in a team.
|
|
---
|
|
|
|
# Remote State
|
|
|
|
By default, OpenTofu stores state locally in a file named `terraform.tfstate`.
|
|
When working with OpenTofu in a team, use of a local file makes OpenTofu
|
|
usage complicated because each user must make sure they always have the latest
|
|
state data before running OpenTofu and make sure that nobody else runs
|
|
OpenTofu at the same time.
|
|
|
|
With _remote_ state, OpenTofu writes the state data to a remote data store,
|
|
which can then be shared between all members of a team. OpenTofu supports
|
|
storing state in [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software),
|
|
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
|
|
|
|
Remote state is implemented by a [backend](../../language/settings/backends/configuration.mdx) or by
|
|
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software), both of which you can configure in your configuration's root module.
|
|
|
|
## Delegation and Teamwork
|
|
|
|
Remote state allows you to share
|
|
[output values](../../language/values/outputs.mdx) 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 OpenTofu states consume that.
|
|
|
|
For example usage, see
|
|
[the `terraform_remote_state` data source](../../language/state/remote-state-data.mdx).
|
|
|
|
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 OpenTofu configuration that writes to Consul using
|
|
[`consul_key_prefix`](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/resources/key_prefix) and then
|
|
another that consumes those values using
|
|
[the `consul_keys` data source](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/data-sources/keys).
|
|
|
|
## Locking and Teamwork
|
|
|
|
For fully-featured remote backends, OpenTofu can also use
|
|
[state locking](../../language/state/locking.mdx) to prevent concurrent runs of
|
|
OpenTofu against the same state.
|
|
|
|
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) 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 OpenTofu operations in a central location.
|
|
This allows teams to more easily coordinate and communicate about changes to
|
|
infrastructure.
|