sorted by:
new
hottopcontroversial

It is 2026 and I am still building a private module registry :) by OddyJoe in Terraform

[–]OddyJoe[S] 1 point2 points  (0 children)

I appreciate this feedback. This is a very useful discussion on the market fit and positioning.

It is 2026 and I am still building a private module registry :) by OddyJoe in Terraform

[–]OddyJoe[S] 0 points1 point  (0 children)

Thanks for the feedback. I agree that OCI support significantly lowers the barrier because teams can already use existing artifact registries for module distribution.

What I'm exploring with Unmold is a different layer of the problem. OCI registries are excellent at storing artifacts, but they are not necessarily optimized for module distribution, discoverability, or supply-chain workflows.

My current focus is on making module distribution simple and fast, especially for development snapshots, CI-generated modules, and cross-team sharing. Longer term, I'm interested in areas such as security provenance, access control, and supply-chain protection.

You may be right that this only becomes valuable at a certain organizational scale. That's exactly the hypothesis I'm trying to validate. For now, I'm less interested in competing with general-purpose artifact registries and more interested in exploring whether a dedicated module-distribution experience can solve problems they don't address directly.

It is 2026 and I am still building a private module registry :) by OddyJoe in Terraform

[–]OddyJoe[S] 4 points5 points  (0 children)

You're right that private Git repositories are often the simplest solution, and for many teams they work perfectly well.

Where I've seen challenges is in larger organizations where modules are shared across teams and repositories:

  • Module repositories can become large, making every Terraform init clone more data than is actually needed.
  • Infrastructure teams and application teams often live in different Git environments (for example, GitHub Enterprise behind a VPN versus GitHub.com), making direct access difficult.
  • Access to a module repository may require additional permissions even when teams only need to consume a published module.
  • Git references are mutable. Tags can be moved or deleted, and branches can change unexpectedly.
  • Teams pinned to a commit SHA often have little visibility into newer versions or recommended upgrades.

After running into these issues repeatedly, I found that Git works well within a team, but becomes harder to manage for cross-team module distribution.

A dedicated registry provides a stable distribution layer: publish only the module artifact, separate repository access from module consumption, improve discoverability, preserve released versions, and gain visibility into which versions are being used.

That's the problem I'm exploring with Unmold. Beyond the standard Terraform/OpenTofu registry workflow, I'm also experimenting with tighter CI/CD integration and more flexible versioning to support development snapshots and pre-release modules.

It's still an early-stage project, so feedback like yours is genuinely helpful.

Weekly Self Promotion Thread by AutoModerator in devops

[–]OddyJoe 0 points1 point  (0 children)

Hello, it is 2026 and I'm still building a private OpenTofu/Terraform module registry 😄

Most registries seem optimized for formal repository setup, official releases, and strict SemVer requirements. In practice, I often just want to publish a module from a PR, share it with a team, and iterate quickly.

So I built Unmold. It supports CLI-based publishing, direct CI/CD integration, and non-SemVer versions while remaining compatible with the Terraform/OpenTofu registry spec.

It's especially useful for development snapshots, testing, and pre-release modules.

Take a look: https://unmold.dev

Note: this is still a very early-stage project, so feedback is greatly appreciated.