In most pipelines, yes: terraform init -lockfile=readonly suppresses changes to the lock file while still checking checksums against what is already recorded. A pipeline then fails on drift in provider selections instead of quietly rewriting them.
What the flag does
The Terraform CLI documents -lockfile=readonly as a mode that suppresses lock file changes but verifies checksums against the information already recorded. It conflicts with -upgrade, which makes sense, because an upgrade is a change by definition.
Without it, init in CI may add a new provider entry or extra checksums and carry on. The job passes, the lock file on the runner differs from the one in the repository, and nobody reviews the change.
A pipeline pattern
terraform init -lockfile=readonly
terraform validate
terraform plan -out=tfplan
If a configuration needs a provider that is not yet in the lock file, init fails. That is the signal for a developer to run init locally, review the lock file diff and commit it.
What this protects and what it does not
| Protects against | Does not protect against |
|---|---|
| Silent provider version changes on the runner | A provider you approved that later turns out to be flawed |
| New provider entries appearing without review | Remote module versions, which the lock file does not track |
| Surprise checksum additions | Secrets in state or plan files |
Remember that the lock file tracks provider dependencies only. For remote modules, Terraform selects the newest version meeting your constraint unless you use an exact version.
Who updates the lock file then
Give the update a home. A scheduled job or a developer runs terraform init -upgrade on a branch, reviews the diff, and opens a pull request. Reviewers check the version bump and release notes. After merge, the readonly pipeline picks up the new lock file.
Checklist
- Commit
.terraform.lock.hcl. - Use
-lockfile=readonlyin CI init. - Pre-populate platforms with
terraform providers lockif CI and laptops differ. - Pin remote module versions exactly or with a tight constraint.
- Review every lock file diff.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a pull request is held until checks pass, then picture the lock file diff as one of those checks.
Quick check
Will readonly mode block a first terraform init on a new project?
It can, if the lock file has no record yet for a provider, because it will not write one. Create the lock file locally first.
Does readonly mode skip checksum verification?
No. It still verifies packages against checksums already recorded.
Is readonly mode the same as -upgrade=false?
No. They are different controls. Readonly is about whether the file may change.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
