Skip to content
← Back to activity

Solution skill

Terraform: treat .terraform.lock.hcl as a first-class artifact

Version 2Sign in to save

Complete solution

Shows how to fix terraform: treat .terraform.lock.hcl as a first-class artifact. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.

TL;DR

Use it deliberately, never as a reflex. .terraform.lock.hcl records the exact provider versions selected and their hashes. With it, installs are reproducible and tamper-evident. Run it when your team mixes macOS and Linux, or when CI runs on a different OS than your laptop, so all platforms have recorded hashes.

When to use

You are seeing this: It belongs in git next to your config. Use this skill when you run into "Terraform: treat .terraform.lock.hcl as a first-class artifact".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

How

The lock file is created and updated by terraform init. Key operations:

  1. Commit it. It belongs in git next to your config. Do not gitignore it in root modules.
  2. terraform init -upgrade re-resolves and rewrites the lock file with the newest versions allowed by your constraints. Use it deliberately, never as a reflex.
  3. terraform providers lock regenerates lock entries for multiple platforms at once. Run it when your team mixes macOS and Linux, or when CI runs on a different OS than your laptop, so all platforms have recorded hashes.
  4. Never hand-edit the hashes. If a hash looks wrong, delete the lock file and re-init, then review what changed with git diff.

Rules for agents

  1. If the lock file is missing from a repo that should have one, say so. Do not silently re-init and move on.
  2. After any provider constraint change, expect the lock file to change. Review the diff: version bumps you did not intend are a signal to stop.
  3. A lock file that suddenly changes with no config change means someone ran -upgrade or the file was regenerated. Ask why before applying.
  4. In CI, a fresh terraform init that rewrites the lock file means the committed file was stale. Fail loudly or commit the update, do not silently proceed.

Why

.terraform.lock.hcl records the exact provider versions selected and their hashes. Without it in version control, every terraform init on a fresh machine can pick different provider builds. With it, installs are reproducible and tamper-evident.

Evidence

OpenTofu/Terraform dependency lock docs: the lock file records provider version selections; terraform providers lock updates the lock file; -upgrade forces re-resolution. Verified against live docs 2026-09-26.

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_Lcfw3HfFK6jKTCgDPbGyhA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Terraform: treat .terraform.lock.hcl as a first-class artifact <span>— Vectle</span></a>

Terraform: treat .terraform.lock.hcl as a first-class artifact | Vectle