Terraform Provider Version Conflict: Fix in 5 Minutes

Terraform failing with 'no available releases match the given constraints' or two modules requiring incompatible provider versions? Here is exactly how to diagnose and fix provider version conflicts without breaking your state.

Provider version conflicts almost always show up the same way: terraform init fails, or worse, it succeeds with a version neither module author tested against. Here is how to find the real cause and fix it without guessing.

Step 1: Read the Actual Error

bash

terraform init
 
# Error: Failed to query available provider packages
# Could not retrieve the list of available versions for provider
# hashicorp/aws: no available releases match the given constraints
# ">= 5.0.0, < 5.20.0, >= 5.30.0, < 6.0.0"

Terraform is telling you the exact constraint math that fails — < 5.20.0 from one module conflicts with >= 5.30.0 from another. No version satisfies both.

Step 2: Find Which Modules Set Which Constraint

bash

# Search every .tf file for provider version constraints
grep -rn "aws" --include="*.tf" -A 3 | grep -B 3 "version"
 
# Better — check each module's required_providers block directly
find . -name "*.tf" -exec grep -l "required_providers" {} \; | \
  xargs grep -A 5 "required_providers"

hcl

# modules/networking/versions.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0.0, < 5.20.0"    # ← old, pinned by whoever wrote this module
    }
  }
}
 
# modules/eks/versions.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.30.0, < 6.0.0"    # ← newer, needs a feature from 5.30+
    }
  }
}

Step 3: Check What Changed Between the Versions

bash

# See what's different — usually one module needs a new resource/argument
# that only exists in the newer provider version
curl -s https://registry.terraform.io/v1/providers/hashicorp/aws/versions | \
  jq -r '.versions[].version' | sort -V | tail -20

If modules/networking pins < 5.20.0 for no real reason (nobody remembers why), the fix is to widen it. If it pins it because of an actual breaking change, you need to fix that module's code first.

Fix 1: Widen the Older Constraint (Most Common Fix)

hcl

# modules/networking/versions.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0.0, < 6.0.0"    # Widened to include what the other module needs
    }
  }
}

bash

terraform init -upgrade

Widening is safe when the constraint was defensive/arbitrary rather than protecting against a known breaking change. Check the module's CHANGELOG or git blame on that line to be sure.

Fix 2: Pin Everyone to One Exact Version (Most Reliable)

hcl

# Put this in the root module — it overrides child module constraints
# as long as they're compatible ranges, not exact pins
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.45.0"    # Exact version, same everywhere
    }
  }
}

Then update every child module's versions.tf to match or widen to include 5.45.0. This is the fix worth doing once you have more than 2-3 modules — floating ranges across modules is how you end up back here in three months.

Fix 3: Lock File Is Stale After a Manual Edit

bash

# If you edited version constraints and init still fails,
# the .terraform.lock.hcl might be holding an old resolved version
rm .terraform.lock.hcl
terraform init
 
# Or, safer — regenerate without deleting first:
terraform providers lock -platform=linux_amd64 -platform=darwin_amd64

Never delete .terraform.lock.hcl on a shared repo without regenerating and committing it — CI and teammates will resolve different provider versions otherwise, which causes drift that is much harder to debug than the original error.

Fix 4: Different Providers, Same Name (Rare but Nasty)

bash

# Check for a provider alias mismatch — a fork or custom-published
# provider registered under a name that collides
grep -rn "source.*aws" --include="*.tf"
# hashicorp/aws vs some-org/aws — these are DIFFERENT providers

If a module was written against a forked or vendor-specific provider under a similar name, no version bump will fix it — you need to either standardize on one source or add an explicit provider alias mapping in the root module.

Verify the Fix

bash

terraform init -upgrade
terraform providers    # Shows the resolved version tree per module
terraform plan          # Confirms no unexpected resource changes from the version bump

Always run terraform plan after a provider version change even if init succeeds — provider version bumps can change default values or add required arguments that show up as unexpected diffs.

More Terraform troubleshooting? Read our Terraform state lock error fix and Terraform plan unexpected destroy fix.

Terraform Provider Version Conflict: Fix in 5 Minutes

Step 1: Read the Actual Error

Step 2: Find Which Modules Set Which Constraint

Step 3: Check What Changed Between the Versions

Fix 1: Widen the Older Constraint (Most Common Fix)

Fix 2: Pin Everyone to One Exact Version (Most Reliable)

Fix 3: Lock File Is Stale After a Manual Edit

Fix 4: Different Providers, Same Name (Rare but Nasty)

Verify the Fix

Stay ahead of the curve

Related Articles

Terraform Accidentally Destroyed Resources — How to Recover

Terraform Apply Hangs Forever: Fix in 5 Minutes

Terraform Backend S3 Init Failed — Every Cause and Fix (2026)

Comments