OpenTofu – Registry UI

OpenTofu recently announced the release of its beta registry UI. This release is an important milestone that will accelerate enterprise adoption, offering a streamlined approach to understanding and implementing infrastructure as code with OpenTofu.

Registries are fundamental when guiding engineers on what they can build. They are a one-stop shop for every detail of the resources that can be created without relying on the documentation offered by the cloud providers or the tools in which these resources are created. Some registries have no UI, and even though they are very useful, it is hard to take advantage of them.

For me, a registry UI is fundamental for making engineers’ lives easier. I always go to an IaC tool’s documentation to understand how a particular resource works, and I encourage all engineers to do the same. The OpenTofu Registry UI makes this easy for those wanting to understand OpenTofu and how to best leverage it. 

By regularly checking a registry’s documentation, you not only understand how to use different resources but also how to implement best practices, which reduces the likelihood of misconfigurations or errors in your code.

Multiple RFCs were submitted for the registry. You can read the community proposals and discussions related to the registry:

• https://github.com/opentofu/opentofu/issues/258
• https://github.com/opentofu/opentofu/issues/741
• https://github.com/opentofu/opentofu/issues/791 

After multiple discussions around the registry, OpenTofu decided on a homebrew-style registry that contains all metadata in GitHub. This registry is hosted on CloudFlare R2 and is highly available (100% uptime). 

The module registry currently hosts around 4k providers and 30k modules, and any OpenTofu user can take advantage of them.

The release of the registry UI is an important step to accelerate OpenTofu enterprise adoption. It provides a single UI for the community to increase productivity and allow engineers to improve their abilities to leverage OpenTofu. With the registry UI, the community can now focus on what matters — building effective OpenTofu automations.

The DevOps ecosystem includes many tools and products, and it is unrealistic to expect to know them from cover to cover. Let’s suppose you are building a multicloud automation that leverages AWS, Microsoft Azure, and Google Cloud using OpenTofu. You can’t possibly be 100% proficient in everything that is happening in all three providers, as there are so many services available.

Switching from one cloud documentation to the other is cumbersome and frustrating. However, this process becomes more manageable when you have a central place to consolidate all the information you need, allowing you to seamlessly transition between your providers. This is the power of the new OpenTofu registry.

Having a registry is useful, but having a UI takes it to the next level. Before the registry UI, engineers were required to consult other documentation sources for building OpenTofu automation, which could have made the process cumbersome, especially for those who are not that familiar with how OpenTofu works.

This is no longer the case because the new registry gives you information about most of the available providers and modules. However, not all documentation is available because OpenTofu doesn’t scrape the provider/module documentation if the author’s license doesn’t allow it.

Having a registry UI is not only more convenient, but it also offers engineers a centralized hub where they can learn the best practices for using resources and discover ways to make their code more effective. With the UI, they can quickly access documentation, examples, and guidance, thus streamlining the development process and reducing the learning curve.

You can do the following with the registry UI:

• Discover providers and modules
• Read the documentation for providers

• Read the documentation for modules, including examples and submodules

It’s important to understand how to use the documentation too, so let’s explore it:

Provider documentation

On the provider documentation page, you will see the following:

• Overview – What the provider does, how to use it, and in the near future: download statistics
• Documentation – Redirects to different examples on how to use the provider and the accepted values when configuring it
• How to use the provider – Example of how to use the provider
• Resource and Datasource pages:
  • Example Usage – Shows examples of how to use the resource
  • Schema — Shows all the parameters that can be configured for a resource. Some parameters are mandatory and others are optional (these parameters will be signaled with an Optional placed between brackets).
  • Import — Shows how you can import that particular resource type (available only for resources)
• Function and Guide pages – Show how to use specific functions and different how-to guides

Module documentation

Other details are available on the module documentation page:

• Module versions – Easily see and select different versions of the module.
• Provision instructions – Learn how to use the module.
• Examples – See a list of examples that call the module.
• Submodules – Learn how to use the available submodules.
• Module details
  • Readme – Understand what the module does and how to use it.
  • Inputs – See the inputs the module takes.
  • Outputs – See the outputs defined at the module level.
  • Dependencies – See the dependencies defined at the module level (could be providers, or other modules)
  • Resources – Find a list of resources the module might create.

Alongside this Registry UI, OpenTofu also developed an API:

• This API is currently hosted at api.opentofu.org, but this is subject to change.
• This allows tool authors to fetch documentation for providers and modules using OpenTofu’s OpenAPI spec.
• The UI is based on this API too, so no private APIs are created.

OpenTofu cares about the community and wants to give everyone a chance to improve the ecosystem. Everything is developed in the open, and the system is impartial, so your voice matters — don’t be afraid to open issues or provide solutions for the ones that are already open. 

Publishing new providers or modules to the registry

Publishing a new provider or module couldn’t be simpler — you just need to submit an issue based on one of the templates:

• Submitting a new Module

• Submitting a new Provider

• Submitting a new Provider Signing Key

Contributing to the registry codebase

Because OpenTofu is open-source, all contributions are encouraged. To contribute to the registry’s codebase, y look into the Registry UI repository and go through the contribution guide.

The OpenTofu registry portal will be a central element of the OpenTofu community — one place that brings the ecosystem together. We have come a long way, and there is more ahead. The completed registry — API and web UI — is a significant milestone that will accelerate adoption both in the community and in enterprises.

OpenTofu takes a community-first approach to developing new features and improving existing ones, and all contributions are encouraged.