What would make you choose a private Terraform module registry over Git-tag-based module sourcing, or vice versa?

Git-tag sourcing is simpler to set up (no additional infrastructure — just tag releases in the existing repo) and works fine for a small number of modules with a small number of consumers, but lacks the discoverability, version-listing UI, and dependency-graph visibility a registry provides. A private registry is worth the additional setup once you have enough modules and consumers that discoverability (can teams find what modules exist at all) and structured versioning/dependency visibility genuinely matter — typically once module count and consumer count both grow past what a small team can just keep track of informally.

Git-tag sourcing (source = "git::https://github.com/org/repo.git?ref=v1.2.0") requires no additional infrastructure beyond the Git repository itself and disciplined tagging — genuinely simple to set up and understand, and perfectly workable for a small number of modules with a small, well-informed set of consumers who already know the modules exist and roughly where to find them. Its limitations show up at scale: there's no centralized place to browse "what modules exist and what do they do," no structured version-listing UI (someone has to know to check the repo's tags/releases directly), and no built-in dependency-graph visibility showing which consumers depend on which module versions.

A private module registry (Terraform Cloud/Enterprise's private registry, or a self-hosted equivalent) adds a layer of infrastructure specifically to address those gaps: a searchable catalog of available modules with descriptions, a structured version history UI, and often visibility into which workspaces/consumers are using which module versions — genuinely valuable once an organization has enough modules that "does a module for this already exist" becomes a real, recurring question, and enough consumers that understanding the blast radius of a module change (who's actually using which version) matters for planning safe changes.

The practical decision point: for a small number of modules with well-known, well-communicated consumers (a handful of teams who already know what modules exist because the organization is small enough for that knowledge to spread informally), Git-tag sourcing's simplicity is the right trade-off — the registry's added discoverability and visibility don't yet solve a real pain point. Once module count or consumer count grows enough that "what modules exist" and "who's using what version" become genuine, recurring friction — new teams reinventing a module that already exists because they didn't know to look, or a breaking change's actual blast radius being unclear — the registry's additional infrastructure investment starts paying for itself.

• Git-tag sourcing is simpler with no additional infrastructure, appropriate for a small number of modules with well-informed consumers.
• A private registry adds discoverability (a searchable catalog) and version/dependency visibility, worth the setup once module and consumer count grow enough for those gaps to cause real friction.
• The decision point is roughly when "does this module already exist" or "who's using which version" become recurring, real organizational pain points, not a fixed module-count threshold.
• Both approaches use the same underlying semantic versioning discipline — the registry adds visibility and discoverability infrastructure on top, not a different versioning model.

• Terraform: Module Sources
• Terraform: Private Module Registry