Top 10 Most Popular Terraform Providers [2026]

What Do Terraform Provider Download Numbers Show?

As of June 2026, the Terraform Registry hosts thousands of providers, but downloads concentrate heavily at the top.

AWS has crossed 6.5 billion cumulative downloads, more than the next two providers combined, and the pace is accelerating: HashiCorp marked five billion AWS-provider downloads in November 2025, noting it "took eight years to reach the first billion downloads, and just two more to reach five." That single provider now spans 1,564 resources and 630 data sources. The second most downloaded provider is not Azure or Google Cloud. It's the Random provider, which overtook Null in 2026.

Which Terraform Providers Rank in the Top 10 by Usage?

Here's where things stand based on registry download data (June 2026) and GitHub metrics:

(Ranking excludes the archived template provider, the google-beta variant, and the time utility, which sit between these by raw downloads.)

The utility providers (Null, Random, Local, Archive, TLS) together rival the big cloud providers in usage, because nearly every configuration pulls in at least one of them. All of them ship through both registries and behave identically on Terraform and OpenTofu; see our OpenTofu vs Terraform comparison for where the two engines do differ.

What Does a Real-World Multi-Provider Configuration Look Like?

Here's what real provider configurations look like in production. This is a typical multi-cloud setup:

terraform {
  required_version = ">= 1.5.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.23"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.11"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.5"
    }
    null = {
      source  = "hashicorp/null"
      version = "~> 3.2"
    }
  }
}

Looks simple enough. But wait until you have 50+ repositories, each with slightly different provider versions. One team updates to AWS v6.0 for a new feature, breaking another team's legacy resources. Sound familiar?

Why Does Managing Multiple Providers Get So Complicated?

Here's where things get messy. Most enterprises run several providers across their infrastructure, usually one or more clouds plus a set of utilities. You can see the scale of the problem in adoption surveys: 89% of teams have adopted infrastructure as code, but only 6% report full coverage (Firefly's 2025 State of IaC survey). Most of the gap between those two numbers is operational work: managing providers, versions, and state across a growing estate. Each provider has its own:

• Release cycle
• Breaking changes
• Authentication requirements
• State management quirks

Here's the collision we see most often. A shared module declares that it needs an aws.secondary provider and assumes it authenticates the way its authors' team does:

# Team A: root configuration passes a role-assuming provider into the module
provider "aws" {
  alias  = "secondary"
  region = var.secondary_region
 
  assume_role {
    role_arn = "arn:aws:iam::987654321098:role/TerraformRole"
  }
}
 
# Team B: same module, same alias, but the runner's instance profile is the identity
provider "aws" {
  alias  = "secondary"
  region = "us-east-1"
}

Both configurations are valid HCL. The module's resources now get created by two different principals with two different permission sets, and the failure shows up as an AccessDenied on Team B's apply that Team A can't reproduce.

Without centralized provider management, provider versions drift between teams, outdated providers carry known vulnerabilities, and a config that runs on one machine fails on another.

How Do Provider Breaking Changes Cause Version Chaos?

Provider breaking changes are a recurring tax, and the AWS provider's long-running aws_s3_bucket refactor is the canonical example. Starting in v4.0 (February 2022), HashiCorp split the monolithic bucket resource apart, moving inline arguments like acl and versioning into dedicated resources such as aws_s3_bucket_acl and aws_s3_bucket_versioning. Those inline arguments were deprecated then and remain deprecated today. They were not removed, just discouraged in favor of the standalone resources. Here's what that migration looks like:

# Old (v3.x style, deprecated since v4.0)
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"  # Deprecated in v4.0; use aws_s3_bucket_acl
  
  versioning {  # v3-style inline block; use aws_s3_bucket_versioning
    enabled = true
  }
}
 
# New (v4.x+): separate resources
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
}
 
resource "aws_s3_bucket_acl" "example" {
  bucket = aws_s3_bucket.example.id
  acl    = "private"
}
 
resource "aws_s3_bucket_versioning" "example" {
  bucket = aws_s3_bucket.example.id
  
  versioning_configuration {
    status = "Enabled"
  }
}

Multiply this by hundreds of resources across dozens of workspaces. Without proper tooling to manage these migrations, teams either get stuck on old versions (security risk) or face massive refactoring efforts.

How Do Enterprises Manage Providers at Scale?

Past a few dozen workspaces, provider management stops being a line in a README and becomes someone's job. The pattern that recurs in larger estates is a single providers.tf that every workspace inherits: exact versions rather than ranges, configuration_aliases for each region, and default_tags carrying the cost-center tag finance keeps asking for. Here's what that file usually looks like:

# providers.tf - Centrally managed
terraform {
  required_version = ">= 1.5.0, < 2.0.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.47.0"  # Exact version for stability
      
      configuration_aliases = [
        aws.us_east_1,
        aws.us_west_2,
        aws.eu_west_1
      ]
    }
    
    datadog = {
      source  = "DataDog/datadog"
      version = "3.38.0"
    }
  }
}
 
# Provider configurations with proper tagging
provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
  
  default_tags {
    tags = {
      ManagedBy   = "Terraform"
      Environment = var.environment
      CostCenter  = var.cost_center
      Provider    = "aws.us_east_1"
    }
  }
}

Which Providers Rank 11 Through 20?

The list below comes from an earlier registry pull than the June 2026 table above, so the download counts are lower than today's and three of its entries (TLS, Archive, Datadog) have since climbed into the top 10. The order is the useful part.

Who Dropped out of the Top 20?

The following providers have dropped off the top 20 list since 2021:

• DNS (previously #16)
• HashiCorp Consul (previously #17)
• VMware (previously #18)
• HashiCorp Terraform Cloud (previously #19)
• Oracle Cloud (previously #20)

Bonus: Scalr

The Scalr Terraform provider can be used to manage the components within Scalr. This will allow you to automate the creation of workspaces, variables, VCS providers and much more. Scalr charges per run, so automating workspace creation through the provider adds no per-seat cost.

What Does the 2026 Provider Data Add Up To?

A few patterns hold across the 2026 download data:

1. AWS dominates with 6.5B+ downloads, but most deployments also pull in several of the utility providers above. Random, Null, Local, TLS, and Archive all rank in the top 10
2. Utility providers are essential. Null and Random are in nearly every configuration
3. Version management is the hidden challenge. Breaking changes in major providers cause significant operational overhead
4. Multi-cloud is common. Organizations run an average of 2.4 public cloud providers (Flexera, 2025 State of the Cloud Report), so multi-provider configurations are the norm
5. Provider sprawl is real. Large estates accumulate dozens of provider configurations across workspaces

As organizations scale their Terraform usage, the hard part shifts from writing resources to managing providers. The AWS provider breaking changes (the years-long aws_s3_bucket refactor, plus v6.0's region overhaul and OpsWorks removal) are hitting thousands of organizations right now. The Kubernetes provider framework migration is another wave of updates.

This is exactly why platforms that centralize provider management, enforce version policies, and provide migration assistance have become essential for enterprise Terraform users. Managing providers manually worked fine when we had 10 resources and 2 providers. At 10,000 resources and 15 providers, that's a different game entirely.

Picking the right providers is the easy part. The harder work in 2026 is selecting tools that can handle provider complexity at scale and building the processes around them.