TrademarkTrademark
Features
Documentation

Top 10 Most Popular Terraform Providers [2026]

The 10 most popular Terraform providers ranked by registry download data (June 2026), why they matter, and how to choose the right ones for your stack.
Sebastian StadilMarch 4, 2026Updated June 11, 2026
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. 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:

Rank Provider Downloads GitHub Stars Primary Use Case Version Stability
1 AWS 6.5B+ 10.3k Cloud Infrastructure Breaking changes in v6.0
2 Random 2.7B+ N/A Secure Value Generation Stable
3 Null 2.1B+ N/A Workflow Orchestration Stable
4 Google 2.0B+ 2.5k Cloud Infrastructure Frequent updates
5 Azure 1.6B+ 4.7k Cloud Infrastructure Major v4.0 migration
6 Kubernetes 1.4B+ 1.6k Container Orchestration Framework migration
7 Local 1.0B+ N/A File Operations Stable
8 TLS 838M+ N/A Certificate Management Stable
9 Archive 694M+ N/A File Compression Stable
10 Datadog 451M+ 404 Monitoring Integration Active development

(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 — 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. The average enterprise uses 8-12 providers across their infrastructure. 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

The data shows 934 enterprise customers spending $100K+ annually on Terraform tooling. Why? Because at scale, provider management becomes a full-time job. Consider these patterns:

Financial Services (18% of enterprise users):

  • Average of 15 providers per organization
  • Strict version pinning for compliance
  • Multi-region deployments requiring provider aliases
  • Quarterly security audits of provider versions

Technology Companies (31% of enterprise users):

  • Rapid adoption of new providers (averaging 2 new providers/quarter)
  • 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 every deployment needs 5-10 providers minimum
  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 the norm - 90% of enterprises use 3+ cloud providers
  5. Provider sprawl is real - Average enterprise manages 50+ provider configurations

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.

About the author
Sebastian StadilCEO at Scalr
Sebastian Stadil is the CEO of Scalr with 15+ years of DevOps experience. He started with AWS in 2004 and advised early Microsoft Azure and Google Cloud.