Terraform Module Registry – Hierarchical Inheritance

Editor's note (July 2025): Scalr's module registry was redesigned to a namespace-based model. All namespaces are now created at the account scope and can be shared with the entire account or a select set of environments; the legacy "account scope vs environment scope" split described below no longer applies. The historical framing is preserved here for context; for current behavior see the Scalr private module registry docs.

Terraform modules are a great way to simplify your Terraform code: you write it once and then reuse the modules in your templates. A module can hold a single resource or many, and the result is a standard way to deploy infrastructure across your cloud ecosystem.

Create the module:

https://github.com/terraform-aws-modules/terraform-aws-vpc

Use the module in your templates:

https://github.com/terraform-aws-modules/terraform-aws-vpc

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 your own way to manage the module, but that adds work for you in peer reviews. Many teams instead keep a single monolithic repository that holds every module. It's easy to reference in code, but it brings its own problems around dependencies, ownership, and changes nobody asked for.

These challenges get real fast once modules are shared across teams. The more modules you have and the more developers using them, the bigger the problem. Users will keep asking for more modules and more services, and without a system it's hard to track what you have and who depends on it.

Module Registry to the Rescue

If any of these sound like your situation, the Scalr Infrastructure as Code Platform module registry will probably help. The registry lets you:

• 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

With Scalr you store your modules in VCS, tag each one with a version, and then import it into Scalr for your users to see. Whoever writes the Terraform template just copies the code block from Scalr, and they'll know which version to use from the README that gets imported too.

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

Hierarchical Inheritance Module Registry

Scalr built a hierarchical inheritance module registry to spare the administrator that operations headache. You don't want teams stepping on each other when they deploy, so Scalr lets you create environments that give each team or app its own space for deployments and workspaces. Importing the same module into every single environment by hand would be a chore. The hierarchical inheritance model exists to avoid that:

Scalr Hierarchy

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

• Account scope: If created here, all environments will 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 teams and environments. That gives you account-wide standards, and it still lets individual teams add their own modules at their scope if their permissions allow it. They can't change or remove modules from a higher scope. The hierarchy starts to enforce policy on modules, and you can take it further with the Open Policy Agent integration.

Summary

With the Scalr hierarchical module registry you can manage modules safely from here on. Few platforms give you these levels of scoping to cut the operational overhead. Most, like HCP Terraform and env0, scope the private registry to the whole organization. You also get:

• List of approved modules
• Versioning of the modules to allow users to pin
• Deprecation of old modules
• Avoiding accidentally impacting existing deployments
• Restricting module usage to only those in your registry using OPA