init --upgrade cooldown period for new dependencies

[acdha]

Terraform Version

n/a

Use Cases

This would match the emerging consensus in the industry that upgrading to very recent releases poses an increasing risk of supply-chain attacks. Having a cooldown / minimum age period would give the community time to detect such attacks. Terraform is a tempting target since it is typically run with high-privilege credentials.

Attempted Solutions

n/a

Proposal

Add an option (via the usual CLI / config file / environmental variables) to set a minimum age to consider when evaluating module versions (e.g. “Do not install anything released in the last 7 days”). When running terraform init --upgrade the solver can ignore versions which were published after the cutoff date.

To allow high-priority updates or safe sources, it would be useful to implement an exclude mechanism either by disabling this feature for a single provider or module such as a trusted internal publisher or to define the logic such that it only applies when attempting to upgrade the pinned versions but never prevents a newer version when explicitly pinned in the provider / module version (e.g. version = "1.2.3" does not have the check applied but version = "~> 1.2" would treat yesterday's 1.2.3 as if it was never published and use last week's 1.2.2).

References

• https://docs.astral.sh/uv/concepts/resolution/#dependency-cooldowns
• https://pnpm.io/settings#minimumreleaseage
• https://docs.npmjs.com/cli/v11/commands/npm-update#min-release-age
• Minimum age for dependencies rust-lang/cargo#15973
• https://docs.renovatebot.com/key-concepts/minimum-release-age/

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[alsyia]

Hi,

Same use case here. Following recent supply chain attacks (Axios, LiteLLM, Trivy, etc), we're re-examining the configuration of all of our dependency management tools and checking whether they support a cooldown period for new releases.

We'd really like such a feature!

[DanielMSchmidt]

The tool I use to configure my dev tools, mise has a --before option that allows users to specify a date or time duration and only installs the version before this point in time. Something like this would be nice so users can specify the cooldown period themselves. I saw you linked a couple of tools already after writing this, leaving this here as further evidence :)

[NyanKiyoshi]

Add an option (via the usual CLI / config file / environmental variables) to set a minimum age to consider when evaluating module versions (e.g. “Do not install anything released in the last 7 days”). When running terraform init --upgrade the solver can ignore versions which were published after the cutoff date.

Some ideas: ideally, this should be a configuration file which allows users to ensure anyone (humans, CI/CDs, scripts) using terraform will never forget to provide the -before flag (or whichever the name of the flag would be).

For example, this could be set in Terraform files, like so:

terraform {
  required_version = "~> 1.14.0"
  min_release_age = "21 days" # <--- NEW

  required_providers {
    ...
  }
}

Another important option we should consider adding is the ability to override the cooldown on a per provider-basis, e.g.:

terraform {
  required_version = "~> 1.14.0"

  required_providers {
    aws = { # https://registry.terraform.io/providers/hashicorp/aws
      source  = "aws"
      version = ">=5.97.0"
      min_release_age = "2026-04-10T13:31:30Z" # <-- NEW (either absolute or relative date)
    }
  }
}

This is handy for urgent bug fixes. Note: absolute date range in this example is preferable (as it would riskier to put something like min_release_age = "1h" rather than putting 2026-04-10T13:31:30Z). This example is inspired by uv's exclude-newer-package

===

When it comes to this idea, I don't see any situations where having a command line flag would be useful (do share if anyone has sees a use-case for having both a config and a flag)

[dbanck]

That's a good point. A new configuration attribute would offer more control when dealing with multiple providers.

We could also consider combining this with the new constant variables to allow greater flexibility when defining values.

terraform {
  required_version = "~> 1.14.0"

  required_providers {
    aws = {
      source          = "aws"
      version         = ">= 5.97.0"
      min_release_age = local.fixed_release_date
    }
    google = {
      source          = "hashicorp/google"
      version         = ">= 7.27.0"
      min_release_age = local.fixed_release_date
    }
    google-beta = {
      source          = "hashicorp/google-beta"
      min_release_age = var.release_age
    }
  }
}

locals {
  fixed_release_date = "2026-04-10T13:31:30Z"
}

variable "release_age" {
  type    = string
  const   = true
  default = "1w"
}

That would let you use the same value for different providers without hardcoding it in multiple places. Enabling const variables would also allow users to supply a value via the CLI.

terraform init -var release_age="2h" 

[acdha]

When it comes to this idea, I don't see any situations where having a command line flag would be useful (do share if anyone has sees a use-case for having both a config and a flag)

The thought I had came down to how this would interact with lock files: i.e. does it simply cause --upgrade not to consider newer versions or does it actively prevent a newer version specified in a lock file from being used? In the former case, it would make sense to have a default like min_release_age = "P7d" with the ability to do something like terraform init --upgrade --allow-latest-provider-version=aws (assuming there was some very important update to install right now) so it would update the lock file and then future init calls would used the locked version even though it contains something which wouldn't have been selected otherwise.

For environmental variables and global configuration files (e.g. ~/.terraformrc), I was thinking that the primary use-case would be people who work with many projects of varying levels of DevOps maturity – for example, you could set TF_MIN_RELEASE_AGE=P7D for managed developer workstations and on things like GitLab instance-level variables so even projects which don't explicitly configure it would pick up a sane value. That would again work with the previous scenario if that mechanism doesn't conflict with a lock file since the default could be a 1 week cooldown but someone has the option of overriding that in the few cases where some hotly-awaited change has just been released.

[jbardin]

Something we need to consider; there is currently no time associated with a release.
A release only has a version, and Terraform has no way to know how old that version is. The version resolution is dependent on what the Terraform registry returns, and timestamps are not currently tracked in that information. So I think to start, the registry would have to ingest the timestamps from release tags on GitHub, and we would have to add a new registry API protocol which includes that information.

[acdha]

Oh, very good point. That was an issue for Python tools, too, since PyPI’d old “simple” format didn’t include timestamps and it turns out that most third-party registries hadn’t implemented the current JSON format which does.

[dangbert]

Hi I noticed the docs on terraform registry show the publish dates for all versions of a given provider. For example:

• https://registry.terraform.io/providers/hashicorp/google/latest (click the versions dropdown)

Inspecting the network requests I see the data comes back as json from this endpoint with a published-at field:

• https://registry.terraform.io/v2/providers/hashicorp/google?include=categories,moved-to,potential-fork-of,provider-versions,top-modules&include=categories%2Cmoved-to%2Cpotential-fork-of%2Cprovider-versions%2Ctop-modules&name=google&namespace=hashicorp

would this help for checking the age of a given release?