The Terraform Registry sits in the background of almost every Terraform project. Engineers declare providers, call modules, and run terraform init without thinking about where the code comes from. The registry is assumed to be there. Once a project cannot find a provider plugin, the workflow stops. Understanding how the public distribution platform works, how private registries extend it, and how publishing decisions compound over time changes how teams structure modules, manage providers, and govern infrastructure as code at scale.
What the Terraform Registry Is
The Terraform Registry is an interactive resource for discovering a wide selection of integrations, configuration packages, and security rules for use with Terraform. The Registry includes solutions developed by HashiCorp, third-party vendors, and the Terraform community. The stated goal with the Registry is to provide plugins to manage any infrastructure API, pre-made modules to quickly configure common infrastructure components, and examples of how to write quality Terraform code.
The Terraform Registry is integrated directly into Terraform so you can directly specify providers and modules. Anyone can publish and consume providers, modules, and policies on the public Terraform Registry. To publish private modules within your organization, you can use a private registry or reference repositories and other sources directly.
The registry is described as a comprehensive repository of all providers, modules, policies, and run tasks designed to simplify Terraform workflows. HashiCorp maintains the registry with contributions from third-party vendors and the community, making building and scaling infrastructure easier.
The Terraform Registry is the official distribution platform for Terraform providers, modules, and policy libraries, hosted at registry.terraform.io and maintained by HashiCorp. Providers let Terraform communicate with external APIs; modules are reusable infrastructure templates; policy libraries contain shared governance rules for Sentinel and OPA. All three artifact types are available on the public registry at no cost.
What the Terraform Registry contains is not a single thing. The public registry gives you access to thousands of provider plugins and reusable configuration templates. The private registry, whether hosted by HCP Terraform, env zero, GitLab, or a self-hosted solution, gives your organization control over what gets used and by whom. Knowing the difference, and when each applies, is foundational to running Terraform at anything beyond a solo project.
Public Registry Discovery and Navigation
The Registry has a number of different categories for modules, providers, and policies to help with navigating the large number of available options. Select a provider or module card to learn more, filter results to a specific tier, or use the search field at the top of the Registry. Search supports keyboard navigation.
The providers, modules, and policies available on the Terraform Registry are maintained either directly by HashiCorp, by trusted HashiCorp partners, or members of the Terraform community. Refer to Provider Tiers and Namespaces for details. To create issues and contributions in GitHub, click the Report an issue link on the provider, module, or policy library's details page.
If you are having trouble publishing new content to the Terraform Registry, refer to the Publishing FAQ for answers to some of the most commonly-encountered problems. If you have general questions or issues about using the Terraform Registry, you may submit a request.
How Terraform Init Uses the Registry
When you run terraform init on a new project, something happens in the background: Terraform contacts registry.terraform.io, locates the providers you declared, and downloads them. Most engineers accept this as background infrastructure and move on. But the registry is doing real work, and understanding how it functions changes how you structure modules, manage providers, and govern IaC as your team scales.
Terraform is built using a modular approach. When Terraform is installed for the first time on any system, the core responsible for running all the core commands offered by Terraform is installed. However, this does not mean that any config created to provision infrastructure on any cloud provider platform will work.
The existence of the Terraform registry is always assumed. Unlike the remote backends and VCS repositories, configuring the registry in our project, unless the registry is private, involves no manual steps, but the projects cannot run without the registry.
A minimal init flow looks like this:
hcl
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
Running terraform init resolves the source against the registry and downloads the provider plugin.
Providers, Modules, and Policy Libraries
Artifact types are distinct.
| Artifact | Role | Example from Reference |
|---|---|---|
| Provider | Plugin that gives Terraform access to an external API | AWS, Azure, Google Cloud, Datadog, and so on |
| Module | Reusable infrastructure template | configuration packages, reusable configuration templates |
| Policy Library | Shared governance rules | security rules, Sentinel and OPA policies |
A provider is a plugin that gives Terraform access to an external API: AWS, Azure, Google Cloud, Datadog, and so on.
A module is reusable infrastructure. This can be customized to your needs, by modifying the input variables, and you can also fork the repository and bring changes to the module to fully customize its behavior.
Policy libraries contain shared governance rules for Sentinel and OPA.
Publishing to the Public Registry
Individuals interested in publishing can use a GitHub account to sign in to the Terraform Registry. Click the Sign-in button, and follow the login prompts to authorize the use of your GitHub account and sign in. Refer to the specific instructions for publishing modules, providers, and policy libraries.
If you are an HCP Terraform user and want to publish and manage modules or providers in the public registry, you can connect a GitHub account to an HCP Terraform organization, letting members collectively manage that account’s public registry artifacts. Refer to Namespaces for more information.
Publish to the Terraform registry covers how to publish Terraform providers, modules, and policies to the public Terraform registry.
Private Registry and Organizational Control
What is a Terraform private registry?
The Terraform private registry allows you to publish private resources that won’t be publicly accessible. Some products have a built-in private registry, such as Spacelift and Terraform Cloud, and the most common use case for these registries is to host modules and providers.
In the same way organizations protect their proprietary code; they will also do it for their proprietary modules and providers, but irrespective of the reasons you’d need to use a private registry, you can establish a secure and efficient workflow by doing so.
The entire discussion around accessing the provider plugins, modules, Sentinel policies, and run tasks has assumed until now that these resources are available publicly on the Terraform registry. They must be public to use them to successfully develop a Terraform configuration. Otherwise, if access to the respective provider plugin is lost, the workflow cannot progress.
However, organizations often need to protect the proprietary providers, modules, and policies from public access. HCP Terraform enables the private publishing of resources, so organizations can control which teams can access these resources internally.
Using the privately published modules differs slightly from using public modules in a configuration.
The Terraform registry is well integrated with HCP Terraform. Apart from the publicly available provider plugins and modules, it is also possible to publish proprietary modules privately. Terraform Enterprise takes privacy to the next level of self-hosting the HCP Terraform on-premise.
Authentication is handled at the platform level, so individual workspaces don't carry provider credentials separately.
Both registries work with Terraform and OpenTofu workspaces in the same organization. If you're running a mixed Terraform and OpenTofu environment during an evaluation or gradual migration, you don't maintain separate registries for each runtime.
Managing modules and providers across a growing team, versioning, CI testing, access control, multi-runtime support accumulates overhead quietly until it becomes a real engineering cost. A private registry handles the distribution and governance layer, so your team focuses on writing good modules rather than maintaining the infrastructure that hosts them.
In the case of using providers outside of Spacelift, you will either need to log in interactively if you want to use them on your machine, or you can use an API key for your automations.
Registry API and Interoperability
The core of the communication between various entities, like the Terraform host, cloud, registry, etc., is based on the Registry API. Any installation capable of understanding the registry API can communicate with other Terraform hosts bi-directionally. This is an important point that requires understanding, especially in the case of Enterprise installation.
Given the plugin-oriented design, the Terraform registry is an integral part of any Terraform workflow. In this post, we have explored its importance and examined various types of available resources.
Decision Compounding
The decisions you make about the registry early, which modules to trust, how to version what you publish, whether to run your own private one, tend to compound. This covers the practical side of all three.
April 2026. Refreshed to cover Terraform 1.15, release candidate, OpenTofu registry differences, private registry options, and CI/CD automation patterns.
Conclusion
The Terraform Registry is not optional infrastructure. It is the distribution backbone that makes Terraform’s modular approach practical. The public registry at registry.terraform.io provides a searchable catalog of providers, modules, and policy libraries maintained by HashiCorp, partners, and the community, and is integrated directly into terraform init. Publishing to it requires a GitHub account and follows namespaces and provider tiers.
Private registries extend that model inside organizations. Products such as HCP Terraform, Terraform Cloud, Spacelift, env zero, and GitLab provide private publishing so proprietary providers, modules, and policies remain inaccessible to the public. Authentication is handled at the platform level, and the same registry can serve both Terraform and OpenTofu workspaces.
Because the registry is assumed present, the cost of ignoring it appears later: uncontrolled module versions, sprawl of copies, and governance gaps. Early choices about trust, versioning, and private hosting compound. Understanding the registry as an active distribution and governance layer rather than background plumbing is what allows teams to scale Terraform reliably.