mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-03-23 22:00:35 -04:00
64 lines
3.5 KiB
Plaintext
64 lines
3.5 KiB
Plaintext
---
|
|
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.
|