Terraform Version Constraint Helper
Evaluate Terraform pessimistic (~>) operators, test candidate versions, and build required_providers blocks.
Test a Specific Candidate Version
Parsed Clauses & Exact Semantics
Preset Version Acceptance Matrix
| Candidate Version | Status |
|---|---|
| 4.67.0 | REJECTED (FAIL) |
| 5.0.0 | ACCEPTED (PASS) |
| 5.30.0 | ACCEPTED (PASS) |
| 5.90.0 | ACCEPTED (PASS) |
| 6.0.0 | REJECTED (FAIL) |
Generated required_providers HCL Block
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}Do it offline:$
How to use it
- Enter or select a Terraform version constraint expression (e.g. '~> 5.0' or '>= 3.100, < 4.0.0').
- Select a popular provider preset (AWS, AzureRM, Google Cloud, Kubernetes, Helm, Cloudflare) or specify a custom source.
- Input candidate semantic version strings (e.g. 5.12.0) to instantly test whether Terraform init would accept or reject them.
- Inspect the rule breakdown to understand the difference between minor-level (~> 1.2) and patch-level (~> 1.2.3) pessimistic constraints.
- Optionally set a root module terraform CLI version constraint (e.g. '>= 1.5.0').
- Copy the generated required_providers HCL block directly into your versions.tf configuration.
Evaluate and test Terraform version constraint expressions including pessimistic operators (~>), ranges (>=, <), and exclusions (!=). Simulate whether candidate provider versions match, inspect parsed clause semantics, and generate production-ready required_providers HCL blocks.
How it works
Terraform uses semantic version constraints within the required_providers block to select acceptable plugin versions from the registry during terraform init.
The pessimistic constraint operator (~>) allows the rightmost non-zero version component to increment. Specifying '~> 5.0' allows versions from 5.0.0 up to, but not including, 6.0.0. Specifying '~> 5.0.1' allows versions from 5.0.1 up to, but not including, 5.1.0.
Compound constraints use commas to represent logical AND. All individual constraint clauses must evaluate to true for a provider version to be eligible.
Terraform locks the exact resolved provider versions into the .terraform.lock.hcl dependency lock file to guarantee reproducible plan and apply runs across team machines.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
What is the difference between ~> 1.2 and ~> 1.2.0 in Terraform?
The number of version components specifies the pessimistic boundary. '~> 1.2' specifies two components (major and minor), meaning only the minor version can increase: it allows any version >= 1.2.0 and < 2.0.0. In contrast, '~> 1.2.0' specifies three components (major, minor, and patch), meaning only the patch version can increase: it allows any version >= 1.2.0 and < 1.3.0.
Should reusable Terraform modules use exact version pinning (=)?
No. Reusable modules should use flexible lower-bound pessimistic constraints (like '~> 5.0' or '>= 5.0, < 6.0'). If a reusable module pins an exact version like '= 5.12.0', any root configuration consuming that module alongside other modules requiring '= 5.13.0' will suffer unresolvable provider version conflicts during terraform init.
How does the .terraform.lock.hcl file interact with version constraints?
Version constraints in your code define the acceptable range of versions, while '.terraform.lock.hcl' records the single exact version selected during the first 'terraform init' along with cryptographic checksum hashes. Subsequent 'terraform init' commands on other machines will honor the locked version unless you explicitly run 'terraform init -upgrade'.