How to fix Version constraints inside provider configuration blocks are deprecated in Terraform

TerraformINTERMEDIATEMEDIUMUpdated Dec 30, 2025· 147 views

Terraform 0.13+ deprecated specifying provider versions in the provider block. Move version constraints to the required_providers block in your terraform configuration to fix this warning.

Quick fix

Fixes Version constraints inside provider configuration blocks are deprecated

provider "aws" {
  version = "~> 5.0"
  region  = "us-east-1"
}
  1. Identify provider blocks with version arguments
  2. Add or update the required_providers block
  3. Remove version argument from provider block
  4. Run terraform init to regenerate lock file
terraform — error
provider "aws" {
  version = "~> 5.0"
  region  = "us-east-1"
}
Version constraints inside provider configuration blocks are deprecated

What this error means

This warning appears when you specify a provider version constraint using the `version` argument inside a provider configuration block. Terraform 0.13 introduced the `required_providers` block as the proper way to declare provider version constraints, and starting in Terraform 0.14, the old method was marked for deprecation. This change aligns with Terraform's dependency management system and enables the generation of `.terraform.lock.hcl` files for reproducible deployments.

Typical symptoms

  • Terraform init displays a deprecation warning about provider version constraints
  • Warning mentions the version argument inside the provider block
  • CI/CD pipelines flag warnings when running Terraform 0.14+
  • Linting tools report deprecation in your configuration

Common causes

  1. Using the `version` argument directly in the provider block (old Terraform 0.12 pattern)
  2. Migrating from Terraform 0.12 without updating provider configuration syntax
  3. Copy-pasting provider blocks from older code examples or documentation
  4. Not updating to the required_providers block introduced in Terraform 0.13

How to fix "Version constraints inside provider configuration blocks are deprecated"

1Identify provider blocks with version arguments

Search your Terraform configuration for provider blocks that include a version argument. Here's the deprecated pattern:

hcl
provider "aws" {
  version = "~> 5.0"
  region  = "us-east-1"
}
2Add or update the required_providers block

In your root module's terraform block, add the required_providers section with the provider source and version constraint:

hcl
terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
3Remove version argument from provider block

Delete the version argument from all provider blocks. Keep only the provider-specific configuration:

hcl
provider "aws" {
  region = "us-east-1"
}
4Run terraform init to regenerate lock file

Execute terraform init in your working directory. This will:
- Download providers matching your version constraints
- Generate or update .terraform.lock.hcl with pinned versions
- Validate your configuration syntax

bash
terraform init
5Verify the warning is resolved

Run terraform plan or terraform validate to confirm the deprecation warning no longer appears:

bash
terraform validate
# Expected output: Success! The configuration is valid.
6Handle multiple providers

If your configuration uses multiple providers, add them all to the required_providers block:

hcl
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}
7Commit the lock file

Add .terraform.lock.hcl to your version control system. This ensures all team members and CI/CD pipelines use the same provider versions:

bash
git add .terraform.lock.hcl
git commit -m "Update provider version constraints"

Advanced notes

Dependency Lock File: Terraform 1.1+ automatically generates .terraform.lock.hcl when you run terraform init. This file pins the exact provider versions used, ensuring reproducible deployments across your team and CI/CD systems. Always commit this file to version control.

Version Constraint Operators: Use >= for minimum versions in reusable modules, ~> for patch updates (e.g., ~> 5.0 allows 5.0 to 5.999), and = for exact versions in production.

Provider Source Addresses: The source argument specifies the provider's registry location. HashiCorp providers use hashicorp/provider-name, while community providers use namespace/provider-name. You can also use private registry addresses.

Terraform Block: The required_providers block must be inside the terraform block at the root module level. Child modules inherit these requirements from the root module.

Frequently asked questions

What does "Version constraints inside provider configuration blocks are deprecate" mean?
This warning appears when you specify a provider version constraint using the version argument inside a provider configuration block. 14, the old method was marked for deprecation. hcl files for reproducible deployments.
How do I fix "Version constraints inside provider configuration blocks are deprecate"?
Terraform 0.13+ deprecated specifying provider versions in the provider block. Move version constraints to the required_providers block in your terraform configuration to fix this warning.
What causes "Version constraints inside provider configuration blocks are deprecate"?
Using the version argument directly in the provider block (old Terraform 0.12 pattern) Migrating from Terraform 0.12 without updating provider configuration syntax Copy-pasting provider blocks from older code examples or documentation
Is the "Version constraints inside provider configuration blocks are deprecate" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading