Terraform dev_overrides: why it should never reach CI or production

Keep dev_overrides to personal machines used for provider development. Terraform documents that the block disables version and checksum verification for the overridden provider and forces Terraform to load the plugin from a local directory. On a CI runner or shared host, that removes a safeguard you depend on.

What the setting does

Terraform normally verifies version selections and checksums for providers. The documentation explains this helps ensure all operations use the intended provider version, and that authors can upgrade in a controlled way.

Those rules get in the way when you develop a provider, because a development build may have no version number and no published checksums. So the CLI configuration supports a dev_overrides block inside provider_installation. It overrides all other installation methods, so it must appear first. The documentation example maps a provider address to a directory on disk.

Where it lives

The block goes in the Terraform CLI configuration file, not in your project. That is easy to forget. A developer's home directory configuration can quietly change behavior for every project they run. The same applies to a configuration file on a CI image, or a path set through the TF_CLI_CONFIG_FILE environment variable.

Two consequences:

• Your repository can look perfectly pinned and locked while a machine uses a local binary instead.
• A plan run on one laptop may not match a plan in CI, for reasons that never show in the code.

Why this matters for supply chain

The lock file and checksums are your evidence that the provider you run is the one you reviewed. Overriding them means you are trusting a directory. If that directory is writable by other users or other processes, a swapped binary will run with your cloud credentials.

Also be careful when copying configuration. People paste a working CLI file from a colleague, from a ticket, or from a build script, and take the override along with it.

A safe workflow for provider developers

1. Use a dedicated machine or container for provider development, with no production credentials.
2. Keep the override in a separate CLI configuration file, and point to it only when needed using the environment variable.
3. Never bake that file into a shared image.
4. Use throwaway cloud accounts for testing.
5. Remove the override as soon as the work is done, and run an init with a clean configuration.

Guardrails for everyone else

1. Add a CI step that reads the effective CLI configuration and fails if dev_overrides is present.
2. Build runner images from a reviewed definition, not by hand.
3. Run a provider mirror or direct installs with the lock file checked in. See what does the Terraform lock file protect.
4. Log the provider versions used in each run next to the plan, so differences show up.
5. Limit write access to directories on runners that hold plugins.

The Terraform documentation also notes that with development overrides in effect, init still tries to select a published version of the provider and record it in the lock file, but other commands use the local build. So a lock file entry does not prove which binary ran.

Where a scanner fits

An override lives outside the repository, so scanning code alone will not catch it. Treat runner images and build hosts as assets. Safeguard's asset discovery and policy gates can support that discipline, and its SBOM generation covers what your pipelines build. Free scan: gold.safeguard.sh/scan.

Quick check

Sources

• Create a Terraform CLI configuration file, HashiCorp

Last reviewed: 19 October 2026.