This error occurs when Terraform cannot find a provider version that satisfies all version constraints in your configuration and modules. Conflicting constraints between modules or outdated local plugins typically cause this issue.
This error happens during terraform init when Terraform evaluates version constraints for providers and modules. Terraform requires that all version constraints be satisfied simultaneously—if module A requires provider version >=6.0.0 and module B requires <6.0.0, no version exists that satisfies both, causing this error. The error message often displays the conflicting constraints, such as "no available releases match the given constraints 5.99.1, 6.0.0" or "~> 2.12.1, 2.25.2", showing the impossible requirement set.
First, understand what constraints are being applied. Run:
terraform providersThis shows all provider dependencies and their required versions across your configuration and all modules. Look for the provider that has conflicting constraints.
An outdated ~/.terraform.d/plugins directory can cause version resolution failures. Move it temporarily to rule this out:
mv ~/.terraform.d/plugins ~/.terraform.d/plugins.oldThen retry terraform init. If this works, the issue was cached plugins. Keep the plugins.old directory removed or clean it out.
Look at the error message—it shows which constraints conflict. Find the modules that are imposing these constraints. Check:
1. Your root module's required_providers block
2. Each module call in your configuration (grep -r "required_providers" in modules/)
3. The modules/ directory for sub-module constraints
The terraform providers command output shows which module is requiring which version.
Once you identify conflicting modules, pin their versions to ones that are compatible with your provider requirements.
For example, if your root config requires aws ~> 5.0 but a new module requires aws >= 6.0, pin the module to an earlier version:
module "networking" {
source = "terraform-aws-modules/vpc/aws"
version = "5.1.0" # Pin to a version compatible with your provider
# ... config
}Then run terraform init -upgrade to re-evaluate constraints.
Alternatively, relax your provider version constraints to allow the versions required by modules. For example, change from ~> 5.0 to >= 5.0, < 7.0.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = ">= 5.0, < 7.0" # Allows more flexibility
}
}
}Run terraform init -upgrade after making changes:
terraform init -upgradeOnce init succeeds, ensure your .terraform.lock.hcl file is committed to version control. This file locks all provider versions, preventing different team members from experiencing different constraint resolution results.
git add .terraform.lock.hcl
git commit -m "Lock provider versions"Always commit this file so the entire team uses identical versions.
Understanding version constraints is crucial for Terraform projects with dependencies. The pessimistic constraint operator (~>) is useful but can create inflexible requirements. For example, ~> 5.14 allows 5.14.x and 5.15.x but not 6.0.0, which can cause compatibility issues if dependencies need major versions.
When working with modules from the Terraform Registry, always check their provider version requirements before using them. Use terraform providers to visualize the full dependency tree. For large infrastructure projects with many modules, consider using version ranges that provide flexibility while maintaining stability: >= X.Y.0, < (X+1).0.0.
Error: Error installing helm release: cannot re-use a name that is still in use
How to fix "release name in use" error in Terraform with Helm
Error: Error creating GKE Cluster: BadRequest
BadRequest error creating GKE cluster in Terraform
Error: External program failed to produce valid JSON
External program failed to produce valid JSON
Error: Unsupported argument in child module call
How to fix "Unsupported argument in child module call" in Terraform
Error: network is unreachable
How to fix "network is unreachable" in Terraform