tfupdate provider: Bump Provider Version Constraints
tfupdate provider rewrites the version constraint for a named provider across every Terraform file in a tree.
Editing required_providers by hand across dozens of modules is error-prone. tfupdate finds and rewrites the constraint everywhere in one command, which suits an automated dependency-bump PR.
What it does
tfupdate provider <name> -v <version> updates the version constraint for that provider in required_providers blocks. With -r it recurses through subdirectories. It edits files in place; pair it with a terraform init -upgrade to refresh the lockfile afterward.
Common usage
# set the aws provider constraint everywhere under .
tfupdate provider aws -v "~> 5.40" -r .
# google provider in one module
tfupdate provider google -v "5.20.0" ./modules/gke
# then refresh the lockfile
terraform init -upgradeOptions
| Flag | What it does |
|---|---|
| provider <name> | Which provider constraint to rewrite |
| -v <version> | The new version or constraint, e.g. "~> 5.40" |
| -r <dir> | Recurse into subdirectories |
| --ignore-path <glob> | Skip files matching the pattern |
| tfupdate release latest <source> | Look up the newest release to feed -v |
In CI
A scheduled job can run tfupdate release latest to find the newest provider version, tfupdate provider ... -r . to apply it, terraform init -upgrade to update .terraform.lock.hcl, then open a PR. Always regenerate the lockfile in the same change, or terraform init fails later on the mismatched constraint.
Common errors in CI
tfupdate editing nothing usually means the provider name does not match the one in required_providers, or there is no -r so it only looked at one directory. A later "Failed to query available provider packages ... no available releases match" means the constraint is too strict or the version does not exist. A lockfile mismatch after the bump means you skipped terraform init -upgrade.