# OpenTofu Registry: how providers and modules get into registry.opentofu.org > The opentofu/registry repository holds the metadata behind registry.opentofu.org and the Go tooling that bumps, validates and publishes it. It is a submission pipeline, not a package manager you install. **opentofu/registry** — Metadata and tooling for the OpenTofu registry - Repository: https://github.com/opentofu/registry - Website: https://search.opentofu.org - Stars: 410 · Forks: 78 - Language: Go - License: Apache-2.0 - Published: 2026-08-22 · Updated: 2026-08-22 · Language: en - Canonical page: https://hysenlabs.com/projects/opentofu-registry ## What opentofu/registry actually is, and who submits to it The repository is the metadata layer for the provider and module registry served at registry.opentofu.org. Two things live side by side here: the data that describes providers, modules and GPG signing keys, and the applications that handle version bumping, validation and API generation for the hosted registry. The top level of the tree reflects that split. Data sits in providers/, modules/ and keys/, while Go source sits in src/. A versions_blacklist.json file sits at the root, and policy documents (POLICY.md, PROCEDURES.md, CONTRIBUTING.md, AI-USAGE-POLICY.md, BLACKLIST_README.md) sit alongside them. The audience is narrow and worth stating plainly. If you maintain a Terraform-compatible provider or a reusable module and you want it discoverable through OpenTofu, this is the intake path. If you are a Go developer interested in how a registry validates third-party metadata and generates its API, src/ is the part you would read. If you are an OpenTofu user who just wants to consume providers, you never touch this repository; you interact with the hosted registry. The README also credits Cloudflare with sponsoring a Business plan to host the registry, which explains why the hosting side is not something you run yourself. ## The submission path runs through GitHub issue forms, not pull requests This is the design decision most likely to surprise a contributor, and the README states it in a callout: submissions must be made through the GitHub issue form UI, and pull requests that add registry data directly will not be processed. The README goes further and rules out creating issues through the gh CLI, the GitHub API or other tooling, on the grounds that the automated validation and processing pipeline depends on the structured data that only the issue form UI provides. Three templates exist, one each for modules, providers and provider signing keys. Each link pre-fills labels and a title prefix, for example Module: or Provider: or Provider Key:. Once submitted, the OpenTofu team reviews the issue and either approves or denies it. So the data flow is: a structured issue form produces machine-readable fields, the pipeline consumes those fields, and a human review gates the outcome. That is a deliberate trade-off. It keeps validation deterministic and cheap, but it means nobody can script a bulk import of fifty providers, and it means a malformed submission fails at intake rather than at review. ## Installing and running the registry tooling from src/ The README documents no install steps for the tooling, no released binaries and no published container image. What it does say is that the repository contains the applications used to manage version bumping, validation and API generation, and the repository layout places the Go source under src/. The README directs contributors to CONTRIBUTING.md before making any contributions, so that file, not this article, is the place to look for the build and test commands. What can be shown from the repository layout is the shape of a local checkout. Clone the repository and the Go sources appear under src/: ```bash git clone https://github.com/opentofu/registry.git cd registry ls src/ ``` The registry data you would be working against lives in sibling directories, so a checkout gives you providers/, modules/ and keys/ next to the source tree: ```bash ls providers modules keys ``` Do not assume a make target, a module path or a binary name. The README does not name any, and inventing one would send you chasing a command that does not exist. For the submission workflow itself, no local build is needed at all: the README's instruction is to open the issue form link for your artifact type, fill in the required fields and submit. That is the first real use of this project for most people, and it happens entirely in the browser. ## Version immutability is the constraint that catches people out The README states that the OpenTofu Registry treats published provider and module versions as immutable and generally does not remove them. A version-removal request issue template exists, but the README frames it as an exception path: you can open it if your situation meets the bar set out in the Version Immutability section of POLICY.md, and the wording makes clear that most situations will not. Read that as a one-way door. A tag you publish to the registry is expected to stay, which is the right property for a dependency graph where other people's configurations pin exact versions. The cost lands on the publisher. If you ship a provider version with a broken schema, a bad signing key association or a mislabelled module, you cannot simply withdraw it and re-release under the same number. Your options are a new version, or an exception request that has to clear a documented policy bar. The blacklist machinery (versions_blacklist.json and BLACKLIST_README.md) is the escape hatch the project keeps for cases where a version has to be blocked rather than deleted, and the existence of a separate README for it suggests the process is not a routine one. This is also the clearest case where opentofu/registry is the wrong tool. If your release process assumes you can retag, amend or yank artifacts freely, the registry's immutability policy will fight you, and no amount of tooling in src/ changes that. ## How this differs from running your own private module source The alternative most teams already have is a private source: a Git repository, an internal artifact store or a hosted private registry that their own infrastructure reads. The difference is not the file format. It is who controls admission and immutability. With a private source, you decide what gets published, when a version disappears, and whether an unreviewed artifact is visible. Nothing is validated against a shared policy, and no third party reviews the submission. That is faster and it is the correct choice for internal modules that should never be public, for providers you build for one organisation, and for artifacts you need to retract on short notice. The trade-off is reach: nothing you publish there is discoverable through registry.opentofu.org, and consumers have to configure your source explicitly. The OpenTofu registry inverts every one of those properties. Admission is a reviewed issue form. Published versions stay published. Validation and API generation are centralised in this repository's pipeline. Reach is the point. If your provider is meant for the general OpenTofu audience, the private route gives you control you do not need and costs you the distribution you do. If it is not meant for that audience, the registry route gives you a review queue and an immutability policy you cannot opt out of. ## Maintenance cost, licence and what the repository does not tell you The repository is not archived, and no last-push date is available, so there is no basis here for a claim about how frequently it changes. Judge activity from the repository itself rather than from this page. For adopters, the ongoing cost is not code maintenance. It is process maintenance: keeping your provider or module metadata correct as you cut releases, keeping signing keys current (the keys/ directory and the provider signing key issue template exist for exactly that), and living with the fact that a mistake is fixed forward, not backward. The repository carries several policy documents, including PROCEDURES.md, POLICY.md, CONTRIBUTING.md and AI-USAGE-POLICY.md, which together signal that operating inside this registry involves reading rules before acting. On licensing: the repository is Apache-2.0, which covers the metadata and tooling here. That licence says nothing about the licence of any provider or module you submit, and it says nothing about the terms of the hosted registry service. Those are separate questions, and the README does not address them. If your provider's licensing or your organisation's redistribution rules are in doubt, that is a question for your own counsel, not something this repository settles. ## Conclusion This repository is for provider and module authors who want their work listed at registry.opentofu.org, and for Go developers working on the validation and API generation pipeline. It is not for end users looking for a CLI to install, and not for anyone who wants to publish a version and quietly replace it later, because the registry treats published versions as immutable. Before submitting, read POLICY.md and PROCEDURES.md, then open the provider or module issue form link from the README and fill in every required field, since the automated pipeline only accepts submissions made through the issue form UI. ## FAQ ### How do I add a provider or module to the OpenTofu Registry? Open the matching issue form from the README: one template for modules, one for providers and one for provider signing keys. Fill in the required fields and submit, then the OpenTofu team reviews the issue and approves or denies it. ### Can I open a pull request to add registry data directly? No. The README states that submissions must be made through the GitHub issue form UI, and that pull requests adding registry data directly will not be processed and will be closed. ### Why can't I submit with the gh CLI or the GitHub API? The README says the automated validation and processing pipeline depends on the structured data that only the issue form UI provides, so issues created through the gh CLI, the GitHub API or other tooling are not processed. ### Can I remove a published provider or module version? The registry treats published versions as immutable and generally does not remove them. A version-removal request issue template exists, but the README says it applies only where the situation meets the bar in the Version Immutability section of POLICY.md. ### What is opentofu/registry licensed under? The repository is licensed under Apache-2.0. That covers the metadata and tooling in this repository; it does not determine the licence of providers or modules submitted to the registry. ## Sources - [Official documentation](https://search.opentofu.org) - [Official README](https://github.com/opentofu/registry#readme) - [Project repository](https://github.com/opentofu/registry) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opentofu-registry