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.
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
| Provider | Modules | Held below | Newest we accept | Newest released |
|---|---|---|---|---|
| hashicorp/google | 37 | 37 | 7.46.0 | 8.1.0 |
| hashicorp/azurerm | 36 | 36 | 4.81.0 | 5.3.0 |
| linode/linode | 9 | 9 | 3.14.1 | 4.4.0 |
| hashicorp/google-beta | 1 | 1 | 7.46.0 | 8.1.0 |
| hashicorp/aws | 39 | 0 | current | current |
| oracle/oci | 18 | 0 | current | current |
| akamai/akamai | 8 | 0 | current | current |
| cloudflare/cloudflare | 3 | 0 | current | current |
| digitalocean/digitalocean | 3 | 0 | current | current |
| hetznercloud/hcloud | 3 | 0 | current | current |
| scaleway/scaleway | 3 | 0 | current | current |
| hashicorp/random | 2 | 0 | current | current |
| civo/civo | 2 | 0 | current | current |
| exoscale/exoscale | 2 | 0 | current | current |
| IBM-Cloud/ibm | 2 | 0 | current | current |
| ovh/ovh | 2 | 0 | current | current |
| UpCloudLtd/upcloud | 2 | 0 | current | current |
| vultr/vultr | 2 | 0 | current | current |
| aliyun/alicloud | 1 | 0 | current | current |
| hashicorp/archive | 1 | 0 | current | current |
| microsoft/azuredevops | 1 | 0 | current | current |
| hashicorp/azuread | 1 | 0 | current | current |
| hashicorp/vault | 1 | 0 | current | current |
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.