Pin Terraform and Provider Versions in Stack Configuration
You can now pin Terraform and provider versions directly in your stack configuration. Atmos generates terraform_override.tf.json files with required_version and required_providers blocks, giving you centralized control over infrastructure versioning.
What Changed
Previously, pinning Terraform and provider versions required modifying component source code or maintaining separate override files. Now you can declare versions in your stack YAML:
components:
terraform:
vpc:
metadata:
component: vpc
vars:
name: main-vpc
terraform:
required_version: ">= 1.10.1"
required_providers:
aws:
source: "hashicorp/aws"
version: "~> 5.0"
random:
source: "hashicorp/random"
version: ">= 3.0"
How It Works
When you run atmos terraform generate required-providers, Atmos creates a terraform_override.tf.json file in your component directory:
{
"terraform": {
"required_version": ">= 1.10.1",
"required_providers": {
"aws": {
"source": "hashicorp/aws",
"version": "~> 5.0"
},
"random": {
"source": "hashicorp/random",
"version": ">= 3.0"
}
}
}
}
This override file merges with your component's existing Terraform configuration, allowing you to pin versions without modifying component source code.
Stack Inheritance
Version constraints follow Atmos's standard inheritance model. Define base versions in a catalog and override per-environment:
# stacks/catalog/terraform.yaml
terraform:
required_version: ">= 1.9.0"
required_providers:
aws:
source: "hashicorp/aws"
version: "~> 5.0"
# stacks/deploy/prod.yaml
import:
- catalog/terraform
terraform:
required_version: ">= 1.10.1" # Override for prod
CLI Usage
Generate the override file for a specific component and stack:
atmos terraform generate required-providers vpc --stack dev-us-east-1
Or specify a custom output path:
atmos terraform generate required-providers vpc --stack dev-us-east-1 \
--file /custom/path/terraform_override.tf.json
Why This Matters
- Centralized version management - Control versions across all components from stack configuration
- Environment-specific versions - Pin stricter versions in production while allowing flexibility in development
- No component modification - Override files work without changing component source code
- Inheritance support - Define base versions in catalogs and override where needed
