Can't download latest version random provider

when run terraform init , it will download some provider like below:

Initializing provider plugins...
- Finding hashicorp/http versions matching "<= 2.2.0"...
- Finding latest version of hashicorp/random...
- Finding hashicorp/aws versions matching "3.60.0"...
- Finding hashicorp/template versions matching "~> 2.1"...
- Installing hashicorp/http v2.2.0...
- Installed hashicorp/http v2.2.0 (signed by HashiCorp)
*- Installing hashicorp/random v3.1.2...*
*- Installed hashicorp/random v3.1.2 (unauthenticated)*
- Installing hashicorp/aws v3.60.0...
- Installed hashicorp/aws v3.60.0 (signed by HashiCorp)
- Installing hashicorp/template v2.2.0...
- Installed hashicorp/template v2.2.0 (signed by HashiCorp)

but 3.1.2 is not the latest , now the latest is 3.4.3 , not sure which setting or configuration will impact this ?

even I ran “terraform init -upgrade” or specify random version in file , also don’t work .

when I specify version

terraform {
  backend "s3" {
    encrypt = true
  required_providers {
    random = { 
    source = "" 
    version = "~> 3.4.3" 

, the error like below:
Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/random: no available releases match the given constraints 3.4.3

are you using terraform enterprise or terraform cloud? if not, you should remove the source parameter and try again.

yes. using terraform enterprise and version is 0.14.11. I can install the latest aws provider 4.50.0 version . but only can’t download and install the latest random provider .

$ terraform -version
Terraform v0.14.11
+ provider v4.50.0
+ provider v2.2.0
+ provider v3.1.2
+ provider v2.2.0

are you using cli driven workflow? is your TFE airgapped? if not airgapped, you don’t really need the source parameter for the provider…can you remove that line and try again? if it still persist, I think you should raise a support ticket - this might be a CDN issue.

Hi @bob.j.zhang,

Another thing I notice about the output is that Terraform is reporting that the package is “unauthenticated” instead of “signed by HashiCorp”, which suggests that you are using an unofficial build of this provider instead of the official release.

One way to gather more information would be to set the environment variable TF_LOG=trace and then run terraform init -upgrade again.

Terraform v0.14 is quite old now so I don’t recall exactly what logging it will generate during installation, but I think you should at least find a line somewhere in the output which has a shape like the following:

[TRACE] providercache.Dir.InstallPackage: installing v3.1.2 from ADDRESS

The ADDRESS part above is a placeholder for the value that I think will be most interesting in learning what’s happening on your system. On my system I see it report that it’s installing from, but I suspect that you’ll see it report a different location instead.

If you can share at least this log line – and ideally also the rest of the output, since the other information there might also be helpful – I think that will give a clue as to what we can try next.

1 Like

thanks, fixed. the search default location is my local folder, and it only has 3.1.2 version random there, because of the local “random” folder exists, it can’t search online and only can search local , so can’t install the latest version . thanks again for your help.

Great, thanks for following up!

In case anyone else finds this while searching for a similar problem in the future, what @bob.j.zhang is talking about is Implied Local Mirror Directories.

When the CLI configuration doesn’t include an explicit provider_installation block, Terraform internally generates one automatically. When doing so, Terraform will first search all of the implied local mirror directories described in the docs, and for any provider found there it will generate a filesystem_mirror block for that includes that provider and exclude that provider from the direct installation method which represents installing from the provider’s host registry.

So in this case Terraform was behaving as if the CLI configuration had contained the following:

provider_installation {
  filesystem_mirror {
    path    = "(one of the local mirror directories)"
    include = [""]
  direct {
    exclude = [""]

To avoid this problem, take either one of the following two actions:

  • Remove the hashicorp/random provider from the local filesystem mirror directory, thereby allowing Terraform to default to using the direct method for it.

  • Write an explicit provider_installation block in the CLI configuration which explains to Terraform which non-default behavior you’d like.

    For example, you can optionally configure Terraform to search for a particular provider in both a filesystem mirror and its origin registry, in which case the packages from both sources will be considered together and Terraform will choose the newest available version across both that matches the configured version constraints.