Every week, the Terraform Registry generates one of the best leading indicators we have for where cloud infrastructure is heading. Not where vendors say it's heading, not where analysts predict it will go, but where hundreds of thousands of engineers are pointing their terraform init right now. Downloads-this-week is a real-time vote. And when you line that number up against a second, less-discussed column, the date each provider's latest version was published, a more interesting picture emerges: not just what platform teams are using, but how well-maintained the tools underneath their infrastructure actually are.
There's a third thing this data makes visible, and it's the one platform leaders should care about most: every one of these providers represents infrastructure that, if it's properly codified, can be rebuilt, not just deployed once and left to drift. Your Terraform state and git history aren't just documentation of what you built. Taken together, they're the closest thing most organizations have to a disaster recovery plan. The problem is that almost no one treats them that way, and the same download and freshness data that shows what's popular also shows, provider by provider, where that recovery plan is solid and where it's rotting away.
We pulled the top 20 providers on the registry, ranked by downloads in the past week, and looked at both dimensions together: adoption and freshness. Here's what stood out, and why it matters if you're the one accountable for what happens when a provider breaks, drifts, or falls behind.
The cloud is still, overwhelmingly, three companies and one orchestration layer
The concentration at the top of the list is stark. hashicorp/aws alone pulled roughly 40.8 million downloads in a single week, more than the next three providers combined, and about a third of all downloads across the entire top 20. Add google, azurerm, and kubernetes, and the top four providers account for nearly 63% of weekly download volume across the list.
This isn't a surprise, but it's a useful gut-check. For all the conversation about multi-cloud strategy, platform engineering, and "best of breed" tooling, the overwhelming majority of Terraform-managed infrastructure still flows through four foundational providers. Everything else in the top 20, from Cloudflare to Databricks to GitHub, is, in download terms, an order of magnitude smaller, including oracle/oci, which rounds out the top 20 at #20 and is a reminder that "multi-cloud" in practice usually means one or two dominant providers plus a long tail of smaller footprints, not four or five clouds sharing the load evenly. If you're building governance, policy, or cost-control processes and you haven't started with airtight coverage of AWS, Google Cloud, Azure, and Kubernetes, you're optimizing the tail before you've secured the head.
Release cadence doesn't track with usage, and that's worth noticing
Version count is where the story gets more interesting. hashicorp/aws has shipped 497 versions and is still publishing weekly. hashicorp/google and azurerm aren't far behind, at 416 and 399 versions respectively. These are providers evolving in near-real time with the cloud APIs they wrap.
Compare that to hashicorp/kubernetes: the fourth most-downloaded provider on the registry, with 9.5 million downloads this week, and only 94 versions total, a fraction of AWS's iteration rate despite serving a massive, active user base. That's not a red flag on its own; Kubernetes' API surface is more stable by design, and a slower cadence can reflect maturity rather than neglect. But it's a reminder that download volume tells you how relied upon a provider is, not how frequently it changes. Platform teams should be tracking both, because a heavily-used provider that changes rarely can lull teams into under-monitoring it, right up until it doesn't.
The freshness picture: tighter than expected, but that's not the whole story
This is the column most teams don't look at closely enough. As of this week, "published" dates across the top 20 span from 2 days old to 45 days old, inside the same list of the most-adopted tools in the ecosystem.
At the fresh end, grafana/grafana and gitlabhq/gitlab (both published July 17) and Azure/azapi (July 16) are shipping essentially in lockstep with the current date, suggesting active, well-resourced maintenance. Most of the list clusters within the last two weeks.
At the older end, hashicorp/helm last published a new version on June 4, 45 days before this snapshot. hashicorp/azuread (June 18, 31 days) and hashicorp/vault (June 26, 23 days) aren't far behind. None of that is alarming on its own: a six-week gap for an official HashiCorp provider is a normal release cadence, not neglect.
The reassuring read here is that the providers organizations rely on most heavily also tend to be the ones that get maintained most consistently. That's a fair takeaway from this particular top 20. But it also points to where the real freshness risk actually lives: not in the handful of providers popular enough to make this list, but in the long tail underneath it, the dozens or hundreds of lower-traffic providers and modules a typical org's Terraform estate depends on that don't get anywhere near this level of attention. Popularity is a rough proxy for maintenance quality precisely because it isn't universal. For any team treating infrastructure as code as a system of record, not just a deployment script, provider freshness across the entire dependency tree, not just the popular parts, belongs on the same dashboard as vulnerability scans and policy compliance. Most teams simply don't have that visibility today.
IaC has quietly outgrown "cloud infrastructure," and so has your recovery surface
One more trend worth flagging: who's climbing into the top 20 at all. Alongside the hyperscalers and HashiCorp's own catalog, the list includes confluentinc/confluent (#5, ahead of several official providers), DataDog/datadog (#10), databricks/databricks (#14), grafana/grafana (#16), gitlabhq/gitlab (#17), and PagerDuty/pagerduty (#18). None of these are core cloud providers. They're streaming infrastructure, observability tooling, data platforms, CI/CD, and, in PagerDuty's case, incident response itself, all now significant enough to be codified and provisioned via Terraform at scale. It's a small irony worth sitting with: the tool teams use to manage incidents is now something they provision as code, which means it's also something that needs its own recovery plan if it ever goes down at the wrong moment.
That matters for reasons beyond adoption trivia. "Infrastructure as code" started as a way to describe cloud accounts: VPCs, compute, storage. This data shows it's become the way organizations describe everything operationally critical, the observability stack that tells you when something's broken, the data platform the business runs on, the developer environments engineers work in every day. If any one of those systems goes down (a region outage, a botched change, a ransomware event), the question isn't just "do we have a backup of the data." It's "do we have a codified, deployable definition of the system itself that we can stand back up somewhere else, fast."
That's the part most teams get wrong. They treat their Terraform state and git history as documentation, when it's actually closer to a disaster recovery plan they haven't tested. Every provider on this list that your organization uses represents a piece of infrastructure that either can, or can't, be rebuilt from code in a clean account or region if the worst happens. The wider IaC's footprint gets, beyond cloud, into every layer of the stack, the more that question applies to more of what your business depends on.
What this means if you're accountable for the infrastructure underneath
Put these threads together and a few conclusions hold up.
Cloud infrastructure management is still concentrated at the top, so governance and policy investment should be too, but the long tail is growing fast enough that it can't be an afterthought anymore. Download volume is a reasonable proxy for "how much this provider matters to your stack," but it says nothing about how current, how tested, or how actively maintained that provider is right now. You have to look at both numbers together, because a provider going stale is a provider whose recovery path is quietly getting less reliable. And as IaC's reach expands beyond core cloud into observability, data, and dev tooling, "resilience" can no longer mean just cloud infrastructure. It has to mean everything your teams have codified.
That's the distinction Firefly is built around: data backup is not service continuity.
Gartner made the same call when it created the CAIRS (Cloud Application Infrastructure Recovery Solutions) category and named Firefly a leader, because knowing your data is backed up somewhere tells you nothing about how fast you can bring a running system back online. Firefly's DR Agent continuously discovers and snapshots your entire environment (multi-cloud, Kubernetes, identities, networks, and the dependencies between them) and codifies it into deployment-ready IaC. When an outage or cyber incident hits, that codified state isn't a document sitting in a repo. It's an immutable, versioned copy of your infrastructure Firefly can redeploy into a clean region or account in minutes, not days. And because Firefly continuously exposes which assets are protected versus unprotected, you don't have to wait for an outage to find out where your recovery plan has gaps.
The Terraform Registry data above is really a proxy for a much bigger question: as more of what your business runs on, cloud and beyond, gets defined as code, is that code actually a recovery plan, or just a record of intentions? See how Firefly turns your infrastructure-as-code into a tested, automated path to recovery.
.svg)