Terraform state on Azure: get it off your laptop before it burns you

By Victor Thomson16 July 20266 min read

Terraform's state file is the ledger of everything it built — and by default it sits on one person's machine. In a team, that is a corruption or a deleted-file away from disaster. The fix is a remote backend in Azure Storage.

Terraform's power comes from a file most beginners overlook: state. Microsoft puts its job plainly — "Terraform state is used to reconcile deployed resources with Terraform configurations. State allows Terraform to know what Azure resources to add, update, or delete." It is the record of reality against which every plan is compared. And by default it lives locally, on the machine that ran Terraform — which, the moment more than one person is involved, is a problem.

Why local state fails a team

The docs list the reasons local state is not ideal, and each is a real incident waiting to happen:

It does not work in a team. If state is on Alice's laptop, Bob's apply has no idea what already exists — and they will fight over reality.
It can contain secrets. State is stored in plain text and may include sensitive values, so leaving it on a laptop or, worse, committing it to Git is a data-leak risk.
It is easy to lose. One inadvertent deletion of that file and Terraform forgets everything it manages — a genuinely bad day.

The fix is remote state: move the file to a shared, durable, access-controlled place. On Azure, that place is a Storage account.

The azurerm backend

You point Terraform at an Azure Storage account and container with a backend "azurerm" block, and the state file lives there instead of on disk:

terraform {
  backend "azurerm" {
    resource_group_name  = "tfstate"
    storage_account_name = "tfstate12345"
    container_name       = "tfstate"
    key                  = "terraform.tfstate"
  }
}

Now the whole team shares one authoritative state, stored durably in a blob, with Azure's access controls in front of it. This is the first thing you do when Terraform stops being a solo experiment and becomes team infrastructure.

State locking — the feature that prevents corruption

Remote alone is not enough; two people running apply at the same time could both write state and corrupt it. Azure Storage solves this for free: as the docs say, "Azure Storage blobs are automatically locked before any operation that writes state. This pattern prevents concurrent state operations, which can cause corruption." The blob takes a lease while one apply runs; the other waits. You get safe, serialized changes with no extra service to stand up.

State is the memory of your infrastructure. Leaving it on one laptop is trusting your whole estate to a file nobody backed up.

Encryption, and one nice side effect

Azure Storage encrypts blobs at rest automatically, so your state — secrets and all — is encrypted where it lives. And there is a quiet safety bonus: when Terraform uses a remote backend, it holds state in local memory only and never writes it to your local disk. So the plain-text state stops leaving copies scattered across developer laptops entirely — it stays in one encrypted, locked, shared home.

The takeaway

State is Terraform's superpower — the ledger that lets it reason about drift and change — but it is also its homework. The moment more than one person or pipeline runs Terraform, get state off the laptop and into an Azure Storage backend: shared so the team agrees on reality, locked so two applies cannot collide, and encrypted so the secrets inside are protected. Secure the storage account itself with least-privilege access (and prefer a Key Vault-stored key or a managed identity over a plain access key), and you have turned a fragile local file into durable, safe team infrastructure. "Remote state in an azurerm backend with blob-lease locking" is the answer that shows you have run Terraform with other people, not just by yourself.