Why You Should Commit Your Terraform Lock File
Committing .terraform.lock.hcl ensures your entire team uses the exact same provider versions every time.
What
The .terraform.lock.hcl file records the exact provider versions and cryptographic hashes used by your Terraform configuration. It is automatically generated or updated when you run terraform init. Committing it to version control ensures everyone on your team uses identical provider versions.
Why It Matters
Without a committed lock file, each team member's terraform init may resolve to slightly different provider versions. This leads to inconsistent behavior, hard-to-debug issues, and potential infrastructure drift between environments.
Example
# Initialize your Terraform project (generates .terraform.lock.hcl)
terraform init
# Commit the lock file to version control
git add .terraform.lock.hcl
git commit -m "chore: add terraform lock file"
# When you want to upgrade provider versions
terraform init -upgrade
# Review the changes to the lock file
git diff .terraform.lock.hclCommon Mistake
Adding .terraform.lock.hcl to .gitignore, causing team members to get different provider versions and inconsistent behavior across machines and CI/CD pipelines.
Quick Fix
Remove .terraform.lock.hcl from your .gitignore if it is listed there, run terraform init, and commit the generated lock file. Only the .terraform/ directory should be in .gitignore, never the lock file.
Key Takeaways
- 1.terraform.lock.hcl locks provider versions and hashes
- 2terraform init generates the lock file automatically
- 3Always commit .terraform.lock.hcl to version control
- 4Use terraform init -upgrade to update provider versions
- 5Only .terraform/ directory goes in .gitignore, NOT the lock file
Was this tip helpful?
Help us improve the DevOpsPath daily collection