| --- | |
| description: A module is a container for multiple resources that are used together. | |
| --- | |
| # Publishing Modules | |
| If you've built a module that you intend to be reused, we recommend | |
| [publishing the module](https://github.com/opentofu/registry/issues/new/choose) on the | |
| [Public OpenTofu Registry](https://registry.opentofu.org). This will version | |
| your module, generate documentation, and more. | |
| Published modules can be easily consumed by OpenTofu, and users can | |
| [constrain module versions](../../../language/modules/syntax.mdx#version) | |
| for safe and predictable updates. The following example shows how a caller | |
| might use a module from the Module Registry: | |
| ```hcl | |
| module "consul" { | |
| source = "hashicorp/consul/aws" | |
| } | |
| ``` | |
| If you do not wish to publish your modules in the public registry, you can | |
| instead use a [private registry](../../../internals/module-registry-protocol.mdx) to get | |
| the same benefits. | |
| We welcome contributions of modules from our community members, partners, and customers. Our ecosystem is made | |
| richer by each new module created or an existing one updated, as they reflect the wide range of experience and | |
| technical requirements of the community that uses them. Our cloud provider partners often seek to develop specific | |
| modules for popular or challenging use cases on their platform and utilize them as valuable learning experiences to | |
| empathize with their users. Similarly, our community module developers incorporate a variety of opinions and use cases | |
| from the broader OpenTofu community. Both types of modules have their place in the registry, accessible to | |
| practitioners who can decide which modules best fit their requirements. | |
| ## Distribution via other sources | |
| Although the registry is the native mechanism for distributing re-usable | |
| modules, OpenTofu can also install modules from | |
| [various other sources](../../../language/modules/sources.mdx). The alternative sources | |
| do not support the first-class versioning mechanism, but some sources have | |
| their own mechanisms for selecting particular VCS commits, etc. | |
| We recommend that modules distributed via other protocols still use the | |
| [standard module structure](../../../language/modules/develop/structure.mdx) so that they can | |
| be used in a similar way as a registry module or be published on the registry | |
| at a later time. | |
| ## OpenTofu registry module submission requirements | |
| To be able to submit a module to the [OpenTofu registry](https://search.opentofu.org/), the following are the | |
| requirements that need to be met: | |
| * The module must be hosted in a public GitHub repository. | |
| * The module must be structured as described in [Building blocks of a module](./index.mdx#building-blocks-of-a-module). | |
| * The module repository needs to follow the `terraform-<NAME>-<TARGETSYSTEM>` naming convention. | |
| * `<NAME>` represents the platform on which the module acts. E.g.: `aws`. | |
| * `<TARGETSYSTEM>` represents the type of infrastructure on the platform on which the module acts. This can be a multi-token string separated by hyphens (`-`). E.g.: `secret-manager`. | |
| * Some examples of names: `terraform-aws-secret-manager`, `terraform-azurerm-avm-ptn-network-private-link-private-dns-zones`. | |
| * Each version of the module should be a [`git tag`](https://git-scm.com/book/en/v2/Git-Basics-Tagging) whose name follows the [semantic versioning scheme](https://semver.org/). | |
| ## Submitting the module to the OpenTofu registry | |
| A module can be added to the OpenTofu registry by simply creating an issue by using the provided | |
| [module template](https://github.com/opentofu/registry/issues/new?template=module.yml) and following the instructions | |
| provided by it. |