Top 10 Most Popular Terraform Providers [2026]

The Numbers Don't Lie: Provider Download Statistics

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? Not Azure or Google Cloud - it's the humble Random provider, which overtook Null in 2026.

Top 10 Providers 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.)

What's striking here? The utility providers (Null, Random, Local, Archive, TLS) collectively rival the major cloud providers in usage. Every serious Terraform deployment uses them. These same providers are distributed through both registries and behave identically whether you run Terraform or OpenTofu. That portability is not academic: on Scalr's own platform, OpenTofu now drives the majority of activity — roughly 63% of runs and 72% of newly created workspaces in the 90 days to June 2026 — even though Terraform and OpenTofu are used by a similar number of accounts. A provider has to work the same on both engines. See our OpenTofu vs Terraform comparison for where the two engines actually differ.

Real-World Provider Patterns

Let me show you what actual provider configurations look like in production environments. Here's 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?

The Hidden Complexity of Multi-Provider Management

Here's where things get messy. Most enterprises run several providers across their infrastructure — typically one or more clouds plus a set of utilities. The scale of the problem shows up 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 distance between those two numbers is operational — managing providers, versions, and state across a growing estate. Each provider has its own:

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

Take this real scenario we see constantly:

# Team A's configuration
provider "aws" {
  region = var.primary_region
  
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}
 
provider "aws" {
  alias  = "secondary"
  region = var.secondary_region
  
  assume_role {
    role_arn = "arn:aws:iam::987654321098:role/TerraformRole"
  }
}
 
# Meanwhile, Team B needs different authentication
provider "aws" {
  region = "us-east-1"
  
  # Using instance profile instead
  # But wait, this conflicts with Team A's approach
}

Without centralized provider management, you're looking at configuration drift, security vulnerabilities from outdated providers, and the dreaded "works on my machine" syndrome.

Provider Version Chaos: A Growing Challenge

The AWS provider v6.0 beta dropped in April 2025. Great new features, but also breaking changes that affect S3 bucket configurations, IAM policies, and RDS instances. Here's what a migration looks like:

# Old (v5.x)
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"  # Deprecated in v6.0
  
  versioning {  # Changed structure
    enabled = true
  }
}
 
# New (v6.x)
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.

Enterprise Adoption Patterns

Terraform's reach is broad — 17.8% of all developers (18.7% of professional developers) reported working with it in the past year (Stack Overflow Developer Survey 2025) — and infrastructure tooling is a serious enterprise spend: in its last reported quarter before the IBM acquisition, HashiCorp counted 946 customers paying $100,000 or more a year across its products (Q3 FY2025, ended October 31, 2024). At that scale, provider management becomes a job of its own, and a few patterns recur across larger Terraform estates:

Financial Services:

• Strict version pinning for compliance
• Multi-region deployments requiring provider aliases
• Quarterly security audits of provider versions

Technology Companies:

• Rapid adoption of new providers
• Mix of official and community providers
• Complex provider inheritance patterns
• Need for provider cost allocation

Here's what proper provider configuration looks like at scale:

# 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"
    }
  }
}

Summary and Key Takeaways

The Terraform provider ecosystem in 2026 tells a clear story:

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 complexity shifts from writing resources to managing providers. Those AWS v6.0 breaking changes? They're affecting thousands of organizations right now. The Kubernetes provider framework migration? 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.

The most successful Terraform implementations in 2026 aren't just picking the right providers - they're building processes and selecting tools that can handle provider complexity at scale. Because in the end, your infrastructure is only as stable as your provider management strategy.

Honorable Mentions: Providers 11-20

Beyond the top 10, these providers round out the most widely used in the Terraform ecosystem:

11. Time - Official - Utility - 345M Installs

Helps with time-based resources.

Interesting stat: Not ranked in 2021.

12. Vault - Official - Hashicorp Platform - 321M Installs

The Vault provider allows Terraform to read from, write to, and configure HashiCorp Vault.

Interesting stat: Dropped from #11 with 12.1M installs in 2021.

13. TLS - Official - Utility - 315M Installs

Provides utilities for working with Transport Layer Security keys and certificates. It provides resources that allow private keys, certificates and certificate requests to be created as part of a Terraform deployment.

Interesting stat: Stayed at #13 with 9.5M installs in 2021.

14. Archive - Official - Utility - 311M Installs

The Archive provider generates an archive from content, a file, or directory of files.

Interesting stat: Dropped from #6 with 25.2M installs in 2021.

15. Helm - Official - Cloud Automation - 238M Installs

Manage installed Charts in your Kubernetes cluster, in the same way Helm does, through Terraform.

Interesting stat: Dropped from #12 with 9.7M installs in 2021.

16. Azure Active Directory - Security & Authentication - Public Cloud - 209M Installs

Configure infrastructure in Azure Active Directory using the Azure Resource Manager APIs.

Interesting stat: Dropped from #14 with 7.5M installs in 2021.

17. Datadog - Official - Datadog Platform - 187M

Configure and automate Datadog resources to automate monitoring and logging through the API.

Interesting stat: Not ranked in 2021.

18. HTTP - Official - Utility - 113M Installs

The HTTP provider is a utility provider for interacting with generic HTTP servers as part of a Terraform configuration.

Interesting stat: Dropped from #15 with 3.8M installs in 2021.

19. Github - Official - Github Platform - 112M

Use the GitHub provider to interact with the GitHub API to create repositories, manage users, and more.

Interesting stat: Not ranked in 2021.

20. Cloudflare - Official - Cloudflare Platform - 102M

Use this provider to interact with Cloudflare to create records, page rules, and much more.

Interesting stat: Not ranked in 2021.

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.