Remote state & backends
State for teams, locked and shared.
Local state does not work for a team — two people applying at once corrupt each other’s state. A remote backend fixes this by storing state in shared infrastructure (S3, Azure Blob, GCS, or an HTTP backend) and providing state locking so only one apply runs at a time. OpenTofu supports the same backends as Terraform, configured the same way.
backend.tofu
terraform {backend "s3" {bucket = "acme-tofu-state"key = "prod/network.tfstate"region = "us-east-1"dynamodb_table = "tofu-locks" # lock table => no concurrent appliesencrypt = true # server-side encryption on the bucket}}
Locking and safety
With a locking backend, tofu apply takes a lock before touching state and releases it when done; a second apply waits or fails fast rather than racing. Enable versioning on the state bucket so you can recover a previous state if one is corrupted, and restrict access tightly — the backend store is as sensitive as the state itself.
terminal
$ tofu applyAcquiring state lock. This may take a few moments...# if someone else holds it:Error: Error acquiring the state lockLock Info: who: alice@acme, created: 2m ago
A remote backend is not encryption of the state contents
encrypt = true on an S3 backend encrypts the object at rest on the bucket, but anyone who can read the bucket still gets plaintext state (with any secrets in it) via the API. Server-side backend encryption and OpenTofu’s client-side state encryption (next section) are different controls — the advanced lesson shows the stronger one.