Public private module with no provider

Hi community,

Is it possible (or rather, is there a best practice) to publish private modules in the terraform cloud private registries that don’t utilize a provider?

As an example, I have a module that manages the naming conventions within my org. This basically does a lot of string mangling inside the module’s local variables and exports a bunch of them in the module outputs.

Wondering what the best way to publish such a module would be?

The docs call for naming my repo terraform-<PROVIDER>-<NAME> but provider seems redundant in this case…


Hi @issacg,

The “provider” portion of the name is conventionally the name of the provider of the main remote system the module works with, but of course there are several situations where it’s not possible to follow that convention exactly:

  • If a module exists to create a bridge between two remote systems, such as creating an VPN connection between two different vendor VPC implementations.
  • If a module contains only local logic and doesn’t interact with any remote systems at all, as seems to be true in your case.

The good news is that there is no enforcement of the string you choose for “provider”, and it’s there primarily to help distinguish similarly-named modules targeting different providers, such as the modules in the terraformdns namespace.

You can actually see in that terraformdns set a module that has the same “problem” you’ve encountered: terraformdns/dns-zonefile/template actually has no resources in it at all and instead does all its work with Terraform language expressions.

My sense is that there is an even less formal convention in the public registry to use a pseudo-provider name like template (e.g. if a module consists mainly of string template operations) or cidr (e.g. if a module consists mainly of calls to cidrsubnet and cidrhost functions), where the chosen “provider name” is often the name a real provider whose scope of functionality is related to what the module does even if it isn’t actually using that provider directly.

In your private registry you have even more latitude to choose a convention that makes sense for you and your organization. For your situation where the module is mainly just home to a set of shared values that are used in many places, I might choose a pseudo-provider name like “any” or “generic” or similar, to try to communicate that this module is potentially applicable to configurations that target any remote system.

1 Like