Infrastructure as Code
Using Terraform Data Sources Effectively
Learn how to use Terraform data sources to query existing resources, look up AMIs, reference remote state, and build dynamic configurations. Complete.
5 min read
Cloud Computing
Terraform Version Constraints Guide
Master Terraform version constraints for Terraform core and providers. Covers operators, lock files, required_version, required_providers, and upgrade...
LLuca Berton2 min read
Quick Answer
#Pin Terraform core with required_version and providers with required_providers version constraints. Use ~> (pessimistic) for most cases — it allows patch/minor updates while blocking breaking changes. Always commit .terraform.lock.hcl.
Terraform Core Version
#terraform {
required_version = ">= 1.5.0, < 2.0.0"
}This ensures anyone running this config has Terraform 1.5+ but not 2.x. If someone runs an incompatible version:
Error: Unsupported Terraform Core version
This configuration does not support Terraform version 1.3.9.Provider Version Constraints
#terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.40" # >= 5.40.0, < 6.0.0
}
azurerm = {
source = "hashicorp/azurerm"
version = ">= 3.80, < 4.0"
}
google = {
source = "hashicorp/google"
version = "~> 5.20.0" # >= 5.20.0, < 5.21.0 (patch only)
}
}
}Version Constraint Operators
#| Operator | Meaning | Example | Allows |
|---|---|---|---|
= 5.40.0 | Exact version | Only 5.40.0 | 5.40.0 |
!= 5.40.0 | Exclude version | Any except 5.40.0 | All but 5.40.0 |
> 5.40 | Greater than | 5.41+ | 5.41.0, 6.0.0, etc. |
>= 5.40 | Greater than or equal | 5.40+ | 5.40.0, 5.41.0, etc. |
< 6.0 | Less than | Below 6.0 | 5.99.99, etc. |
<= 5.40 | Less than or equal | 5.40 and below | 5.40.0, 5.39.0, etc. |
~> 5.40 | Pessimistic (recommended) | >= 5.40.0, < 6.0.0 | 5.40.x, 5.41.x, 5.99.x |
~> 5.40.0 | Pessimistic (patch) | >= 5.40.0, < 5.41.0 | 5.40.0, 5.40.1, 5.40.99 |
The Lock File (.terraform.lock.hcl)
## Created by terraform init
# Records EXACT versions + hashes used
terraform init # Creates lock file
terraform init -upgrade # Upgrades within constraints# .terraform.lock.hcl (auto-generated — don't edit manually)
provider "registry.terraform.io/hashicorp/aws" {
version = "5.40.0"
constraints = "~> 5.40"
hashes = [
"h1:abc123...",
]
}Always commit .terraform.lock.hcl to git — it ensures everyone uses the exact same provider version.
Root Module vs Child Module Constraints
## Root module — pin tightly
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.40" # Narrow range
}
}
}
# Child module — use loose minimum
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = ">= 5.0" # Wide range — let root module decide
}
}
}Upgrade Strategy
#Step 1: Check Current Versions
#terraform version
terraform providersStep 2: Update Constraints
## Bump the constraint
aws = {
source = "hashicorp/aws"
version = "~> 5.50" # Was ~> 5.40
}Step 3: Upgrade
#terraform init -upgrade
terraform plan # Review changes — new provider versions may change behaviorStep 4: Test
#terraform plan # Check for unexpected changes
terraform apply # Apply in non-production firstCommon Issues
#| Problem | Solution |
|---|---|
| "No matching version" | Broaden constraints or check registry |
| "Inconsistent dependency lock file" | Run terraform init -upgrade |
| Provider version conflict between modules | Use compatible ranges |
| Wrong Terraform core version | Install correct version with tfenv |
Best Practices
#- Use
~>for most constraints — allows safe updates, blocks breaking changes - Pin tightly in root modules — you control the exact versions
- Pin loosely in shared modules — let consumers choose
- Commit the lock file — reproducible builds across machines
- Upgrade one provider at a time — isolate changes
- Test upgrades in non-production first — providers can change behavior
Hands-On Courses
#Related Articles
#- Terraform Required Providers Block
- Fix Provider Version Conflict
- How to Upgrade Terraform
- Terraform Glossary
Conclusion
#Version constraints protect your infrastructure from unexpected breaking changes. Use ~> for providers, >= for modules, and always commit the lock file. Upgrade deliberately — one provider at a time, in non-production first.
#Terraform#HashiCorp#DevOps#Infrastructure as Code#version constraints
Related articles
Cloud Computing
Terraform count and for_each: Create Multiple Resources with Examples
Learn how to use Terraform count and for_each to create multiple resources. Side-by-side comparison, practical examples, conditional creation
5 min read
Cloud Computing
Terraform Lifecycle Rules: prevent_destroy, create_before_destroy, ignore_changes
Complete guide to Terraform lifecycle rules. Learn prevent_destroy, create_before_destroy, ignore_changes
5 min read
Cloud Computing
Managing Multiple AWS Accounts with Terraform
Master multi-account AWS management with Terraform. Learn provider aliases, cross-account IAM roles, AWS Organizations integration, and production-ready.
5 min read