I scanned 163 Terraform repos to find out what a shared module change could affect

When you have a few repositories, keeping track of dependencies between them is pretty straightforward.

But what happens when you have 50, 100, or even 200 repositories?

Imagine you're about to update a shared Terraform module. Before merging, you want to know:

• Which repositories are using it?
• Which versions are they using?
• Are there other repositories that depend on those repositories?
• Who might be affected by the change?

GitHub search can help, but manually piecing together all those relationships gets tedious pretty quickly.

I wanted a way to answer those questions without setting up a service or maintaining a separate dependency catalog.

So I built RippleMap, an open-source CLI that automatically maps dependencies across repositories.

Testing it on 163 real Terraform repositories

Instead of just testing it on a few example projects, I ran RippleMap against Cloud Posse's public Terraform module repositories.

The scan covered 163 repositories and identified 467 dependency links.

Two findings stood out:

1. Changing one module could affect 13 repositories.

For example, the terraform-aws-security-group module had 12 directly dependent repositories and one additional indirect dependent in the scan.

Instead of searching through all 163 repositories manually, I could select that module and see the dependency relationships.

2. There were 16 internal modules referenced at different versions.

Some repositories referenced newer module versions, while others were still on older releases.

That's not automatically a problem. Different versions might be intentional. But it's useful information to have when planning upgrades or investigating unexpected behavior.

How RippleMap works

RippleMap scans repositories and reads the configuration files already present in them.

For Terraform, it examines module sources, including registry modules and Git-based references.

It then builds a graph connecting repositories to the components they depend on.

The same approach works with other ecosystems, including:

• Docker and Docker Compose
• GitHub Actions
• Kubernetes and Helm
• npm
• Go and Python dependencies

It can also scan Azure DevOps organizations.

Trying it yourself

You don't need to clone every repository or install a separate server.

With Node.js 22 or newer:

npx ripplemap scan --org cloudposse --match 'terraform-*' --exclude examples --exclude test

This generates a dependency graph in ripplemap.json.

To see which repositories depend on a particular module:

npx ripplemap impact terraform-aws-security-group

To find shared components referenced at different versions:

npx ripplemap drift --internal

And to open the interactive visualization:

npx ripplemap report --open

For larger scans, authenticating with gh auth login helps avoid GitHub's anonymous API rate limits.

What about pull requests?

I also added a GitHub Action that can analyze the files changed in a pull request and comment with the repositories that may be affected.

For example, changing a Terraform module's implementation might affect its consumers, while editing its README shouldn't trigger the same warning.

The goal is to give developers this information before merging instead of making them run manual searches.

Limitations

RippleMap uses static analysis. It reads configuration files, not runtime network traffic.

That means it won't discover every possible service-to-service dependency, and a dependency relationship doesn't necessarily mean a change will break something.

It also can't resolve every dynamically generated reference.

I think being transparent about these limitations is important, particularly for a tool intended to help engineers make decisions.

Try the live demo

If you don't want to install anything, I've published interactive reports using real repository data.

Explore the Cloud Posse dependency graph

You can select modules, inspect dependencies, and explore version drift directly in your browser.

The project is free, open source, and MIT licensed.

GitHub: https://github.com/Zintrivious/ripplemap

npm: https://www.npmjs.com/package/ripplemap

I'd especially appreciate feedback from developers managing multiple repositories. If you try RippleMap on your own projects, I'd love to know where its dependency detection gets things wrong or misses relationships.

Those real-world cases are the most useful feedback I could get.