Why teams stop trusting "just use Git" for module distribution.
Git is a perfectly reasonable place to author modules. It is a much shakier place to run a private module distribution workflow once multiple teams, environments, and automation paths depend on it.
The headline problem
Your lock file does not protect Git-sourced modules.
Git refs are not semantic version constraints. Modules can drift, force-pushes can change what consumers receive, and immutability is a social contract, not a technical guarantee.
Git-sourced modules
module "vpc" {
source = "git::github.com/acme/terraform-aws-vpc.git?ref=v3.2"
# Git ref, not a semver contract
# Locking and change control are explicit
}
Semver constraints like `~> 3.2` do not apply.
Force-pushes or retagging can silently change what consumers receive.
Audit, deprecation, and consumer guidance live outside the module workflow.
Registry-sourced modules
module "vpc" {
source = "registry.terramantle.dev/acme/vpc/aws"
version = "~> 3.2"
# Version resolves through the registry protocol
}
Version constraints work with the native registry flow.
Published versions stay immutable.
Consumers get a cleaner release, trust, and migration story.
Quick scan
What changes when you move from repository distribution to registry distribution?
AspectRepositoryRegistry
Version constraintsGit refs onlyNative semver constraints
ImmutabilityConvention-basedRegistry-enforced
Access controlRepo-levelNamespace and token scoped
DeprecationOut-of-band communicationBuilt into the module workflow
CI publishingSecrets and repo pushesOIDC-friendly publish flow
Read it by pain point
Why an Artefact Registry.
Pick the infra-as-code pain your team is feeling today.
You cannot see who depends on your module.
When a module is consumed from Git, the author has no view into upstream or downstream usage. Breaking changes ship without knowing who will be affected, and migrations happen by word of mouth or markdown no one reads.
With Git & S3
There is no authoritative list of who consumes a given module version.
Breaking changes are discovered by consumers, not anticipated by authors.
Migration coordination happens in chat or on trust that teams will upgrade.
With Terramantle
The registry tracks which namespaces and versions depend on a module.
Authors can assess blast radius before publishing a breaking change.
Deprecation notices reach consumers through the toolchain, not a Slack message.
Next step
See the pricing model or tell us what you need to replace.
If the Git-vs-registry pain is already real for your team, the interesting question is whether you want to self-host first or start with a hosted path.