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

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.

New to cloud? CAMPUX is a free, build-first course. Start here →

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.

Figure — Terraform records what it has built in a state file. On Azure you keep that state in a Blob container (the remote backend) so the whole team shares one source of truth, and a lease-based lock stops two people running apply at the same moment and corrupting it. Never leave state on one laptop.

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.

Questions people also ask

What is Terraform state used for?

Terraform state is the record that reconciles the resources you have deployed with the resources in your configuration. Terraform reads it before every plan to know what already exists, so it can decide whether to add, update, or delete resources instead of guessing from scratch.

Where should Terraform state be stored?

Not on a laptop, past the solo-experiment stage. Local state does not work once a second person or a pipeline runs Terraform, since nobody else can see it. On Azure, store it in an Azure Storage account with a backend "azurerm" block, so the whole team reads and writes one shared file.

What is Terraform state locking?

State locking stops two applies from writing state at the same time and corrupting it. Azure Storage blobs are automatically locked before any operation that writes state: the blob takes a lease while one apply runs, and a second apply waits its turn, so changes are safely serialized with no extra service to run.

Is Terraform state encrypted in Azure Storage?

Yes. Azure Storage encrypts blobs at rest automatically, so the state file sits encrypted where it lives. Using a remote backend also means Terraform keeps state in local memory only during a run and never writes a plain-text copy to your disk.

Can Terraform state contain secrets?

Yes, and that is the second reason not to leave it local or commit it to Git. State is stored in plain text and can include sensitive values from your configuration. A remote azurerm backend, locked down with least-privilege access and ideally a managed identity, keeps that plain text out of laptops and repositories.