June 2, 2021

Terraform Module Registry – Hierarchical Inheritance

Ryan Fee

Terraform modules are a great way to simplify your Terraform code by writing it once and then reusing the modules in your templates. The module can contain a single resource or multiple resources with the result being a standard way of deploying infrastructure across your cloud ecosystem.

Create the module:

Use the module in your templates:

Creating and using the module is the first step to simplification and standardization, but how scalable is it?

Module Scalability

So you have created your module, you told your developers to use it and management of your Terraform code has become much simpler, but has it?

  • You may assume developers are using the module to standardize, but how can you track or enforce that?
  • If they are using it, do you know they are using the right version to avoid conflicts?
  • Are you certain that if you make an update to the module it won’t impact their existing Terraform deployment?
  • Do they know when new versions are released or when old versions are deprecated?

You could build or develop a way to control the management of the module, but this will potentially require more work for you with peer reviews. Many teams also implement the idea of a monolithic repository which holds all of the modules, which is an easy way to reference them in code, but introduces issues around dependencies, ownership, unwanted changes and more.

If you are using modules across multiple teams these challenges will become very real, very quickly. The more modules you use and developers you have the bigger the problem. Users will always push for more modules and more services, but in the current state it will be hard to keep track of what you have and who is using it.

Module Registry to the Rescue

If these challenges apply to you then you would likely benefit from the Scalr Infrastructure as Code Platform module registry. The registry allows you to:

  • Create a list of approved modules
  • Create versions of the modules to allow users to pin
  • Deprecate old modules
  • Avoid impacting existing deployments through the versioning
Scalr Module Registry

Scalr allows you to store your modules in VCS, tag the module with a version, and then import it into Scalr for your users to view. The person writing the Terraform template simply needs to copy the code block from Scalr and will be aware of what version to use through the README that is imported as well.

A module registry greatly simplifies the management of modules, but what if it could be even easier?

Hierarchical Inheritance Module Registry

Scalr has created a hierarchical inheritance module registry to save the administrator from an operations headache. The last thing you want is for teams to step on each others feet when deploying, in Scalr you can create environments and organizations to give each team or app its own dedicated space to manage their deployments or workspaces. It would be a real pain to have to go into every single environment and/or organization to import the module, which is where the hierarchical inheritance model comes into play:

Scalr Hierarchy

A module registry can be created at each level in the diagram above:

  • Global scope: If created here, all organizations and environments will inherit the module.
  • Organizational scope: All environments within the organization inherit the module.
  • Environment scope: That environment is the only place the module can be used.

Create and maintain the module in one place and share with many organizations, teams, and environments. This allows you to create organizational standards, but also lets your individual teams add more modules at their respective scope if their permissions allow for it, but not change or remove modules from a higher scope. Introducing the hierarchy starts to enforce policy on modules, but can be taken even further with the Open Policy Agent integration.


With the Scalr hierarchical module registry you can easily and safely manage modules going forward. Scalr is the only solution that provides the various levels to reduce the operational overhead, while giving you the following benefits :

Note: While this blog references Terraform, everything mentioned in here also applies to OpenTofu. New to OpenTofu? It is a fork of Terraform 1.5.7 as a result of the license change from MPL to BUSL by HashiCorp. OpenTofu is an open-source alternative to Terraform that is governed by the Linux Foundation. All features available in Terraform 1.5.7 or earlier are also available in OpenTofu. Find out the history of OpenTofu here.

Start using the Terraform platform of the future.

A screenshot of the modules page in the Scalr Platform