OpenTofu Error: 'Inconsistent dependency lock file' — Cause, Fix, and Troubleshooting Guide
Fix OpenTofu 'Error: Inconsistent dependency lock file' by running tofu init -upgrade and recording every platform hash in .terraform.lock.hcl.
- #opentofu
- #iac
- #troubleshooting
- #errors
Stuck on this OpenTofu error? Get the free incident triage checklist
A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.
What this error means
OpenTofu pins the exact provider versions and checksums it selected in .terraform.lock.hcl. On every later run it enforces that lock. If your configuration now needs a provider or version the lock does not cover — or the lock has no checksum for the current OS/arch — tofu init stops:
Error: Inconsistent dependency lock file
The following dependency selections recorded in the lock file are inconsistent
with the current configuration:
- provider registry.opentofu.org/hashicorp/aws: locked version selection
5.40.0 doesn't match the updated version constraints "~> 5.60"
To update the locked dependency selections to match a changed configuration,
run:
tofu init -upgrade
When it appears
tofu init(orplan/apply) fails withInconsistent dependency lock file.- The message names a provider whose locked version no longer satisfies
required_providers. - A variant reports no matching checksum for the current platform (
linux_amd64in CI,darwin_arm64locally). - It surfaces right after editing constraints, adding a provider, or moving between macOS and Linux/CI.
Configuration causes
- Constraint changed — you edited
required_providersbut did not refresh the lock. - New provider added with no entry in the lock file.
- Missing platform hashes — the lock was generated on one platform and lacks checksums for CI’s.
- Lock not committed — CI regenerates a different selection than local.
- Manual edits to
.terraform.lock.hclleft it internally inconsistent.
Validating the configuration
Read exactly which provider/constraint is inconsistent:
tofu init 2>&1 | sed -n '1,30p'
Inspect the lock’s current selections against your constraints:
cat .terraform.lock.hcl
grep -nA6 "required_providers" *.tf
Show what OpenTofu believes it requires:
tofu providers
Resolution
Reconcile the lock with the configuration:
tofu init -upgrade
Make the lock portable across every platform your team and CI use, so no checksum is missing:
tofu providers lock \
-platform=linux_amd64 \
-platform=darwin_arm64 \
-platform=linux_arm64
Confirm it is clean and reproducible:
tofu init && tofu providers
If a hand-edit corrupted the lock, delete it and regenerate rather than patching by hand:
rm .terraform.lock.hcl
tofu init
Keeping definitions valid
- Always commit
.terraform.lock.hclso local and CI resolve identical providers. - Run
tofu providers lockwith every platform you deploy from; a single-platform lock breaks in CI. - After changing
required_providers, runtofu init -upgradeand commit the lock in the same change. - Never hand-edit the lock file — regenerate it.
- Review lock diffs in code review; a surprise version bump is worth a second look.
Related configuration errors
- OpenTofu Error: ‘Failed to query available provider packages’ — Cause, Fix, and Troubleshooting Guide
- OpenTofu Error: ‘Module not installed’ — Cause, Fix, and Troubleshooting Guide
- OpenTofu Error: ‘Invalid legacy provider address’ — Cause, Fix, and Troubleshooting Guide
Quick Command Reference
tofu init # enforce the lock (reproduces error)
tofu init -upgrade # update lock to match constraints
tofu providers lock -platform=linux_amd64 -platform=darwin_arm64
cat .terraform.lock.hcl # inspect recorded selections
tofu providers # show provider requirements Fixed it? Get 500 OpenTofu & DevOps AI prompts — free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.
Stuck on this? Start guided troubleshooting
Open an interactive diagnostic session with this error already loaded. Work a step-by-step plan, record what each check returns, land on a root cause, and export a clean incident summary — no account needed to start.
Did this fix your issue?
Solved it a different way?
Share the fix that worked for you — reviewed, then published to help the next engineer.
That looks like it may contain a secret (key, token, password, or connection string). Please remove it — a note with a detected secret can’t be published.
Thanks — that helps. Published notes appear after a quick review.
Trending errors this week
The error guides other engineers are actually reading right now.
- 1mount: wrong fs type, bad option, bad superblock
- 2Docker 'failed to set up container networking': Fix the Bridge and IP Pool
- 3Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block
- 4Docker 'failed to create shim task': How to Fix the containerd Runtime Error
- 5Transport endpoint is not connected
- 6modprobe: FATAL: Module not found
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.