IaC Bazaar

Provider freshness

A module pins the provider versions it will accept. Providers keep shipping majors. This page is the gap between the two, for every Terraform module in the catalogue, measured against the registry rather than asserted.

96
accept the newest release available today
83
held below a newer provider major
23
providers checked, 0 unreadable

Snapshot taken 2026-09-01. Re-measured by pnpm freshness, which reads the registry directly.

What “held below” means, and what it does not

It does not mean the module is broken. A module pinned below a new major applies exactly as it always did, against the last provider release it allows. Nothing degrades on its own.

What it means is that the ceiling is now doing something. Until someone raises it and re-validates against the new major, the module stays on the older one, and any fix or resource that landed in the new major is out of reach. That is a deliberate state, not a neglected one: raising a ceiling without re-running the checks would be asserting compatibility nobody verified.

A provider we could not read is reported as unreadable rather than counted as current. An absent answer is not good news, and this page will not round it into one.

By provider

ProviderModulesHeld belowNewest we acceptNewest released
hashicorp/google37377.46.08.1.0
hashicorp/azurerm36364.81.05.3.0
linode/linode993.14.14.4.0
hashicorp/google-beta117.46.08.1.0
hashicorp/aws390currentcurrent
oracle/oci180currentcurrent
akamai/akamai80currentcurrent
cloudflare/cloudflare30currentcurrent
digitalocean/digitalocean30currentcurrent
hetznercloud/hcloud30currentcurrent
scaleway/scaleway30currentcurrent
hashicorp/random20currentcurrent
civo/civo20currentcurrent
exoscale/exoscale20currentcurrent
IBM-Cloud/ibm20currentcurrent
ovh/ovh20currentcurrent
UpCloudLtd/upcloud20currentcurrent
vultr/vultr20currentcurrent
aliyun/alicloud10currentcurrent
hashicorp/archive10currentcurrent
microsoft/azuredevops10currentcurrent
hashicorp/azuread10currentcurrent
hashicorp/vault10currentcurrent

Why we publish this

Because the alternative is that you find out yourself, later, after buying. A catalogue that sells verification and then hides where its own code is behind is selling a claim it will not let you check. Every number above comes from files in the modules and from the public registry, so you can reproduce it without us.

It also sets an expectation we can be held to. A ceiling that stays put for a long time after a major ships is a real signal about maintenance, and it should be visible on the seller's own site rather than discovered in a diff.

Related

What our verification does not prove covers the same idea for evidence rather than versions: a test that passed in June was true in June. The module reference lists every module with the evidence it carries.