---
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.
