The OpenTofu registry, providers & modules

Where OpenTofu resolves code from.

Intermediate12 min · lesson 6 of 12

OpenTofu resolves providers and modules through its own registry at registry.opentofu.org. Architecturally it differs from Terraform’s: the OpenTofu registry is a community project backed by a public GitHub repository of provider/module metadata, which mirrors the same upstream providers you already use. Functionally, source = "hashicorp/aws" resolves to the same AWS provider — just fetched through the OpenTofu registry.

main.tofu

terraform {
  required_providers {
    aws    = { source = "hashicorp/aws",    version = "~> 5.0" }
    random = { source = "hashicorp/random", version = "~> 3.6" }
  }
}
# "hashicorp/aws" => registry.opentofu.org/hashicorp/aws

Modules and explicit sources

Modules work identically — a module block with a source pointing at the registry, a Git URL, or a local path. You can also pin a provider to a fully-qualified source (registry.opentofu.org/... or a private mirror) when you need to be explicit about where code comes from. In air-gapped or high-assurance environments, run a network mirror so init pulls providers from infrastructure you control.

terminal

# vendor providers into a local mirror for offline / audited installs
$ tofu providers mirror ./vendor
$ tofu init --plugin-dir=./vendor    # init strictly from the mirror

Be explicit about provider sources in high-assurance setups

Because the default registry host differs from Terraform’s, teams with allowlists or supply-chain requirements should pin fully-qualified sources and/or run a plugin mirror, then verify provider checksums via the .terraform.lock.hcl lock file. Commit that lock file — it pins the exact provider versions and hashes init will accept.

Migrating from TerraformRemote state & backends