DEV Community: Daniel Westgaard

How to Find Every Consumer of Your Go Module

Daniel Westgaard — Mon, 20 Apr 2026 22:00:00 +0000

You maintain a shared Go module. A breaking API change is coming. Which repos across your org import it — and at which version?

You own github.com/company/platform-lib. Maybe it's your internal observability library that every service imports for structured logging and trace propagation. Maybe it's a shared HTTP middleware package that standardises authentication, rate limiting, and request IDs across all your APIs. Maybe it's a configuration loader that services use to pull settings from your config management system at startup.

It started as a few shared utilities to avoid copy-pasting. Twenty services adopted it. Then more. Some import it directly and call into it heavily. Some pull it in transitively because another shared library depends on it. Some are on the latest version. Some are three majors behind.

Now you need to change it. Maybe you're removing a deprecated function that's been generating noise in the godoc for two years. Maybe you're bumping to v2 because you need to restructure the package API in a backwards-incompatible way. Maybe you're changing the signature of a middleware constructor to accept an options struct instead of positional arguments.

The question is the same one that runs through every post in this series: which repos across the org import this module, and at which version?

The scenario

Here is what Go module consumption looks like in practice. Your platform team publishes a module, and other repos declare it in their go.mod:

// service-a/go.mod
module github.com/company/service-a

go 1.22

require (
    github.com/company/platform-lib v1.8.3
    github.com/company/auth-middleware v2.1.0
)

Some repos import the module directly and use it throughout their code. Others pull it in as an indirect dependency — because a library they depend on imports your module — and Go records it with an // indirect comment:

require (
    github.com/company/platform-lib v1.8.3
    github.com/company/some-other-lib v0.4.1 // indirect
)

Some repos are pinned to a specific release tag. Some reference a pseudo-version pointing to a specific commit:

github.com/company/platform-lib v0.0.0-20260301153042-a1b2c3d4e5f6

Some have overridden the module source entirely with a replace directive — pointing to a local checkout or a patched fork:

replace github.com/company/platform-lib => ../platform-lib

All of these represent consumption of your module. None of them look the same. And right now, they live in different repos, owned by different teams, that you probably can't enumerate off the top of your head.

What existing tools give you (and where they stop)

pkg.go.dev

pkg.go.dev is the official Go package documentation and discovery site. For public modules, it indexes which packages import a given package and shows an importer list. This is the closest existing tool to "who uses this?"

The limitation is sharp: pkg.go.dev only indexes public modules fetched through the public Go module proxy at proxy.golang.org. If your module is hosted on an internal GitLab or GitHub instance, protected by authentication, and routed through a private GOPROXY, it does not appear in pkg.go.dev at all. Every consumer in your org is invisible to it.

For most platform teams managing internal shared libraries, this makes pkg.go.dev entirely useless for the question at hand. Even for public modules, the importer list only covers packages that pkg.go.dev has itself indexed — not a comprehensive count of every organisation that imports the module.

`go mod graph`

The go mod graph command prints the full module dependency graph for the current module — a recursive list of every direct and transitive dependency. It's useful for understanding what a single module pulls in.

But it only works outward from the current module. There is no go mod reverse-graph. You'd have to clone every repo in the org, run go mod graph in each one, collect the output, and invert it yourself — which is exactly the manual trawl the question is trying to avoid. And the moment you finish, the results are stale.

Renovate and Dependabot

Both Renovate and Dependabot support Go modules as a first-class ecosystem. They detect require entries in go.mod and open pull requests when newer versions are published — which means they implicitly know which repos consume which modules.

But they don't expose that knowledge as a queryable view. You cannot ask Renovate or Dependabot "show me every repo in the org that imports platform-lib, and what version each is on." They react to new versions being published. The reverse — who's consuming the current version before you publish a breaking one — is not something they surface.

Both tools also only cover repos where they've been configured. A team that hasn't set up Go module support in their config, or doesn't use either tool at all, is invisible.

GitHub code search

You can search for your module path across all repos in an org:

org:my-org "github.com/company/platform-lib"

This finds go.mod files that contain the module path and gives you a list of repos. For a one-off audit, it's a workable starting point.

The familiar problems apply: results don't include version numbers without opening each file individually, the search index lags behind recent commits, and it doesn't account for replace directives. If a repo has replaced your module with a fork or local path, the require entry still appears — but what's actually being compiled is different. Code search can't tell you that.

Athens (GOPROXY)

Athens is a widely-used open-source Go module proxy that organisations run internally for private modules and caching. It serves module downloads and maintains a local cache.

Athens tracks which modules were fetched and at which version. What it doesn't track is which source repo triggered the download. A build server fetching platform-lib v1.8.3 is recorded as a download event, but not which team's CI pipeline it was, which service repo it was building, or which go.mod declared the dependency. Athens is a supply-chain cache, not a consumption graph.

Why this is harder than it looks

Major version suffixes create distinct module identities. Go's module system treats github.com/company/platform-lib and github.com/company/platform-lib/v2 as completely separate modules. A repo that imports platform-lib/v2 has a different dependency than one that imports platform-lib. Grepping for platform-lib finds both — but a tool that tracks module identities needs to recognise that these are different versions of the same thing, and that consumers may be on any combination of v1, v2, v3.

This also means publishing a new major version doesn't automatically affect v1 consumers. They continue importing the old module path until they explicitly update both the go.mod entry and all import paths in their source code. Understanding who's still on v1 requires knowing who's importing which module path — and treating those as a unified dependency family.

replace directives obscure the real source. A replace directive can substitute your module with a different source — a local path, a fork, or a different module entirely:

replace github.com/company/platform-lib => github.com/company/platform-lib-patched v1.8.3-hotfix

From the outside, the require entry still references github.com/company/platform-lib. A scanner that reads only require entries sees this as a consumer on v1.8.3. But the code being compiled is coming from a patched fork. The apparent consumer is not actually running your module — and a tool that reports it as one gives you a misleading picture of who's affected by a change to the canonical source.

Indirect dependencies inflate the consumer list. Go's go.mod includes both direct and indirect dependencies, with // indirect annotations on the latter. If your module is a transitive dependency — imported by a library that's imported by a service — it appears in that service's go.mod even though the service's code never directly calls into yours.

This matters when reasoning about impact. A service that directly imports your module and calls its functions will break if you change the API. A service that has it only as an indirect dependency may not be affected at all, depending on how much of your interface the intermediate library exposes. Treating all go.mod entries as equivalent overstates the blast radius; ignoring indirect entries understates it.

go.work workspaces cross module boundaries. Go 1.18 introduced workspace mode, where a go.work file at the root of a checkout declares multiple local modules as part of a unified workspace. When workspace mode is active, dependencies between modules in the go.work are resolved locally rather than through go.mod require declarations.

Some consumers of your module may be developing against it in a shared workspace, with no explicit require entry in their go.mod during development. A scanner that only reads go.mod files misses these entirely.

Vendor directories shadow the dependency graph. Repos that vendor their dependencies with go mod vendor keep a copy of all transitive dependencies under vendor/, with canonical version information in vendor/modules.txt. Some repos modify vendored code directly — technically discouraged, but not uncommon in practice. These modifications break the assumption that a version string in go.mod corresponds exactly to the canonical upstream source. A consumer may appear to be on v1.8.3 while actually running a locally modified version of it.

What the full answer requires

To reliably answer "who imports this module," you need a system that:

Scans every repo in the org, parsing go.mod files — without requiring opt-in or registration from each team
Handles all reference forms — tagged versions, pseudo-versions, and replace directives — and records what module source is actually being resolved, not just what appears in require
Tracks all major version suffixes as distinct but related module identities, so you see the full picture across v1, v2, v3
Distinguishes direct from indirect dependencies, so you know which consumers call into your module directly and which pull it in transitively through another library
Follows transitive edges to show second-order consumers: repos that depend on your module through an intermediate shared library
Keeps results current through regular rescans rather than a one-time snapshot

This is one of the specific problems Riftmap is built to solve. It connects to your GitHub or GitLab organisation, scans every repo, and parses go.mod files to extract module dependencies — including all require entries, replace directives, and version strings. It resolves module paths across major version suffixes and builds a cross-repo dependency graph you can query by module.

The result is the same kind of view described throughout this series: before you remove a function, bump a major version, or change a constructor signature, you open the graph, click the module, and see every repo that imports it — their version, whether they're a direct or indirect consumer, and which teams own them. You know who'll break. You know who to notify. You know who's still on v1 and will need a migration path before v2 ships.

No manual go mod graph inversions across dozens of repos. No org-wide code search with manual version lookups. No waiting to see whose CI goes red after you merge.

How is your team solving this today? I'd genuinely like to know — drop a comment or find me at riftmap.dev.

How to Find Every Consumer of Your Helm Chart

Daniel Westgaard — Sat, 18 Apr 2026 22:00:00 +0000

You maintain a shared Helm chart. A breaking change is coming. Which teams across the org are running it — and at which version?

You own a shared Helm chart. Maybe it's a platform-services chart that bundles your observability stack: Prometheus, Alertmanager, and a custom metrics exporter your platform team maintains. Maybe it's an ingress-gateway chart that every product team deploys at the edge of their namespace. Maybe it's a company-wide chart for spinning up a standard service with your logging sidecar, network policies, and PodDisruptionBudget pre-configured.

It started as a convenience. Teams stopped reinventing the same Kubernetes manifests. A dozen clusters adopted it. Then more. Some teams deploy it via ArgoCD. Some use Flux. Some have helm install calls baked into their CI pipelines. Some consume it as a subchart inside their own umbrella chart. Some use a plain Chart.yaml with a dependencies: block and run helm dependency update before deploy.

Now you need to change it. Maybe a value key is being renamed — replicaCount is becoming replicas to align with upstream conventions. Maybe you're dropping support for a Kubernetes API version that was removed in 1.32. Maybe you're restructuring the chart into subcharts to make individual components opt-in rather than all-or-nothing.

The question is the same one it always is: which repos across the org consume this chart, and at which version?

The scenario

Here is what Helm chart consumption looks like in practice. Your platform team publishes a chart to an internal chart repository or OCI registry. Consumers reference it in a few different ways:

As a standalone helm install:

helm install platform-services oci://registry.company.com/helm-charts/platform-services --version 3.2.1 -n monitoring

As a dependency in another chart's Chart.yaml:

# some-service/chart/Chart.yaml
dependencies:
  - name: platform-services
    version: "~3.2.0"
    repository: "https://charts.company.com"
    alias: monitoring

As an ArgoCD Application manifest:

# gitops/apps/some-team/monitoring.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    chart: platform-services
    repoURL: https://charts.company.com
    targetRevision: 3.2.1

As a Flux HelmRelease CRD:

# gitops/releases/monitoring.yaml
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
spec:
  chart:
    spec:
      chart: platform-services
      version: ">=3.0.0 <4.0.0"
      sourceRef:
        kind: HelmRepository
        name: company-charts

All four patterns express the same dependency. None of them look the same in source code. And right now, they probably live in different repos, written by different teams, using different GitOps tooling.

What existing tools give you (and where they stop)

Helm itself

The helm CLI knows about releases deployed to a cluster. helm list -A shows every release across all namespaces in a given cluster, including which chart and version is installed. helm history <release> shows the version history for a specific release.

This is useful once you have access to the cluster. The limitation is that it's cluster-scoped and live-state-only. You can see what's running right now, but it tells you nothing about source repos — which repo contains the values.yaml driving the release, which team owns it, or whether the same chart is deployed to a different cluster you don't have access to. Most companies have at least three clusters (dev, staging, prod), and many have dozens. You'd need access to all of them, and even then you'd have a list of running releases, not a map of source-code consumers.

Artifact Hub and Chart Museums

Artifact Hub is the public index for Helm charts. It tracks download counts and shows chart metadata, but it's a discovery tool for chart users, not a graph of chart consumers. If your chart is published internally — to a private chart repository or an OCI registry — it doesn't appear in Artifact Hub at all. And even for public charts, neither Artifact Hub nor any chart museum stores information about which orgs or repos have installed a particular chart version.

ArgoCD and Flux

If your org has committed fully to GitOps and every Helm release is declared as an ArgoCD Application or a Flux HelmRelease manifest in a Git repo, then in theory all your consumers are visible in those manifests. The problem is "in theory." In practice:

Not every team has migrated to GitOps. Some still run helm upgrade in CI pipelines or from engineer laptops.
The GitOps manifests may live in many different repos — a central gitops repo, per-team repos, per-environment repos — rather than a single queryable location.
ArgoCD's UI shows you the apps it's managing, but querying "show me every app that references chart platform-services" is not a built-in view. You'd need to iterate through the Application CRDs or query the Argo CD API.
Flux doesn't have a central query surface for "which HelmRelease objects across all clusters reference chart X at version Y" — that information is spread across HelmRelease YAML files in whatever repos your GitOps setup uses.

Renovate

Renovate supports Helm chart version bumps as a first-class feature. Configured in a repo, it detects chart references in Chart.yaml dependencies, ArgoCD Application manifests, and Flux HelmRelease CRDs, and opens pull requests when new chart versions are published.

As with Terraform and GitHub Actions: Renovate must know who consumes what in order to open those PRs. But it doesn't expose that knowledge as a queryable view. You can't ask Renovate "which repos reference my chart and at which version?" It reacts after a new version is published. The consumer list before you publish a breaking change is not something it surfaces.

Renovate also only covers repos where it has been configured. A team that hasn't added Helm to their Renovate config — or doesn't use Renovate at all — is invisible.

Grep

Clone every repo. Search for the chart name:

grep -r "platform-services" --include="*.yaml" --include="*.yml" ~/repos/

This finds direct name references in YAML files. It doesn't distinguish between chart references and random YAML comments, doesn't extract version constraints, misses OCI-format references where the chart name is embedded in a registry URL, and ignores any helm install calls in shell scripts or Makefile targets. And as always: the results are stale by the next commit.

Why this is harder than it looks

Reference formats are highly inconsistent. A Helm chart can be referenced via a traditional HTTP chart repository, an OCI registry, or a local path. These look nothing alike:

# Traditional repository (in Chart.yaml dependencies)
repository: "https://charts.company.com"

# OCI registry (in Chart.yaml dependencies, Helm 3.8+)
repository: "oci://registry.company.com/helm-charts"

# OCI in a Flux HelmRepository
spec:
  type: oci
  url: oci://registry.company.com/helm-charts

# Inline OCI reference in a helm CLI call
helm install platform-services oci://registry.company.com/helm-charts/platform-services --version 3.2.1

Resolving all of these back to the same chart identity requires knowing how your registry namespaces charts and how your chart repositories map to OCI paths — out-of-band information that no grep can recover.

Version constraints vary widely. Unlike Docker image FROM statements (which usually pin to a specific tag) or Terraform module ref= pins, Helm consumers regularly use semver constraints:

version: "~3.2.0"      # patch-compatible only: >=3.2.0 <3.3.0
version: "^3.0.0"      # minor-compatible: >=3.0.0 <4.0.0
version: ">=3.0.0 <4"  # explicit range
version: "*"           # any version (dangerous)

A consumer pinned to ^3.0.0 will automatically receive your 3.3.0 release — they don't have to explicitly upgrade. A consumer on ~3.2.0 won't. Understanding who will be affected by a minor version bump versus a major bump requires evaluating constraints, not just comparing version strings.

Umbrella charts create transitive consumers. An umbrella chart is a Helm chart whose primary purpose is to bundle multiple subcharts together. If team-a publishes an umbrella chart team-a-stack that includes your platform-services chart as a dependency, and team-b deploys team-a-stack — then team-b is a transitive consumer of platform-services through team-a-stack. A breaking change to platform-services affects team-b, but a search for platform-services in their repos finds nothing.

GitOps and imperative installs coexist. In most organisations, some teams manage Helm releases declaratively (ArgoCD, Flux) and others do it imperatively (helm install or helm upgrade in CI pipelines, shell scripts, or Makefiles). The declarative installs leave traces in Git repos as YAML manifests. The imperative installs may leave no trace in source code at all — just a live release visible in helm list. A complete consumer map needs to combine both sources.

Chart aliases break name matching. A Chart.yaml dependency can declare an alias, which changes the name used to refer to the subchart in values overrides:

dependencies:
  - name: platform-services
    version: "~3.2.0"
    repository: "https://charts.company.com"
    alias: monitoring   # the chart is installed as "monitoring", not "platform-services"

A naive search for platform-services in values files will find nothing, because the values are nested under monitoring:. Tools that rely on name matching alone miss aliased consumers entirely.

What the full answer requires

To reliably answer "who consumes this chart," you need a system that:

Scans every repo in the org, including GitOps repos, service repos, and platform repos — without requiring registration or manual catalog entries
Parses all reference formats — Chart.yaml dependencies, ArgoCD Application manifests, Flux HelmRelease CRDs, and helm install calls in CI configs and shell scripts
Resolves OCI and HTTP registry references back to a canonical chart identity, so consumers using different registry URL formats for the same chart are recognised as the same dependency
Evaluates version constraints rather than just matching exact version strings, so you know which consumers are within range of your next release
Follows umbrella chart transitive dependencies, so second-order consumers are visible, not just direct chart references
Keeps results current through regular rescans, not a one-time manual trawl

This is one of the specific problems Riftmap is built to solve. It connects to your GitHub or GitLab organisation, scans every repo, and extracts chart references from Chart.yaml dependency blocks, ArgoCD Application and ApplicationSet manifests, Flux HelmRelease CRDs, and helm calls in CI configs. It resolves OCI and HTTP registry URLs to a unified chart identity and builds a cross-repo dependency graph you can query by chart name and version.

The result is the same kind of view described in the earlier posts in this series: before you rename a value key or drop a Kubernetes API version, you open the graph, click the chart, and see every consumer — their version constraint, the repo that owns the deployment declaration, and which constraint ranges include your next release. You know who'll automatically receive the change, who's pinned to an older range, and who you need to contact before shipping.

No cluster access required. No cross-org Slack ping. No grep marathon across forty repos.

How is your team solving this today? I'd genuinely like to know — drop a comment or find me at riftmap.dev.

How to Find Every Consumer of Your Reusable GitHub Actions Workflow

Daniel Westgaard — Fri, 17 Apr 2026 06:38:52 +0000

You maintain a shared GitHub Actions workflow. You need to rename an input, drop a step, or change a required secret. Which repos across your org call it? Here's why the answer is harder than it should be.

You maintain a reusable GitHub Actions workflow. Maybe it's deploy-to-eks.yml in your platform team's .github repo, or a ci-lint-test.yml that standardises how every service in the org runs its CI pipeline. It started as a way to stop every team from copy-pasting the same 80-line workflow file. It worked. Twenty repos adopted it. Then forty. Then you lost count.

Now you need to change it. Maybe you're replacing a deprecated action (actions/setup-node@v4 is being forced to Node 24 and you need to bump to v6). Maybe you're renaming an input from node-version to runtime-version because the workflow now supports Bun and Deno too. Maybe you're removing a step that uploaded artifacts to a bucket that no longer exists.

The question is the same one that comes up for every shared infrastructure artifact: which repos across our org call this workflow, and at which ref?

The scenario

Here's what a typical reusable workflow consumption looks like. Your platform team publishes a workflow in a central repository, and other repos call it:

# In some-service/.github/workflows/ci.yml
jobs:
  test:
    uses: my-org/platform-workflows/.github/workflows/ci-lint-test.yml@v2.1.0
    with:
      node-version: "20"
    secrets: inherit

Some repos pin to a tag. Some pin to a branch like main. Some pin to a full commit SHA for supply-chain security. Some don't pin at all and reference @main, which means they're calling whatever version is on HEAD right now.

You need to find all of them, understand which version each one uses, and figure out which will break when you rename that input. Right now, most teams do this by searching in GitHub, asking in Slack, or just pushing the change and waiting for workflows to fail. None of these are a real answer.

What existing tools give you (and where they stop)

GitHub code search

GitHub's code search is the most natural place to look. You can search across all repos in an org:

org:my-org "uses: my-org/platform-workflows/.github/workflows/ci-lint-test.yml"

This works for finding direct string matches. For a one-off audit, it's often good enough. But it has real limitations:

It doesn't extract the ref. You can see that a repo calls the workflow, but the @v2.1.0 or @main part requires manually opening each result and reading the YAML.
Results are point-in-time. If you're planning a breaking change, you need to know who's calling the workflow now — not when the search index was last updated.
The search index can lag. GitHub's code search is eventually consistent. Repos that were recently updated might not show current results immediately.
It doesn't handle indirection. If a repo has a "wrapper" workflow that calls your reusable workflow, and other workflows call the wrapper, GitHub code search only finds the direct callers.

Dependabot

Dependabot supports GitHub Actions as a first-class ecosystem. In a repo's dependabot.yml, you can configure it to watch for action version updates:

updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot will then open pull requests when actions referenced in the repo's workflows have new versions available. This includes reusable workflows referenced with uses:.

The same pattern as Renovate for Terraform: Dependabot implicitly knows who consumes what, because it's configured per-repo. But it doesn't expose this as a queryable view. You can't ask Dependabot "which repos in my org call platform-workflows/ci-lint-test.yml?" It's a version updater, not a dependency mapper.

There's an additional limitation: Dependabot only monitors repos where it's been explicitly enabled. If a team hasn't added github-actions to their dependabot.yml — or doesn't have a dependabot.yml at all — their workflow dependencies are invisible.

Renovate

Renovate also supports GitHub Actions workflows, including reusable workflow references. It can detect uses: directives in workflow files and open PRs when new versions are available.

Renovate has a slight edge over Dependabot here: it can be configured org-wide via a shared preset, so you don't need every repo to opt in individually. But the core limitation is identical — it's a dependency updater, not a dependency mapper. It reacts when a new version exists. It doesn't give you the blast radius before you publish the change.

GitHub API

The GitHub API lets you list workflows and workflow runs across repositories. You can enumerate all repos in an org, fetch their workflow files, and parse the YAML yourself.

This is essentially building a custom scanner. The API gives you the raw data, but assembling it into an answer requires:

Paginating through every repo in the org
Fetching the contents of every .github/workflows/*.yml file
Parsing YAML to extract uses: directives
Filtering for your specific reusable workflow
Extracting the ref from each reference
Handling rate limits (the GitHub API is aggressive about rate limiting for large orgs)

Teams that go this route end up building a script, running it periodically, and storing the results somewhere. It works. It's also a project you now have to maintain, and the results are stale between runs.

Grep

Clone everything, grep for the workflow reference:

grep -r "platform-workflows/.github/workflows/ci-lint-test.yml" --include="*.yml" ~/repos/

Same trade-offs as always: works once, stale immediately, doesn't extract versions, doesn't catch transitive calls, and at 100+ repos it's slow enough that nobody does it proactively.

Why this is harder than it looks

Reusable workflow references look simpler than Terraform module sources or Docker image references — there's really only one syntax. But the complexity is in what surrounds that syntax.

Ref types vary widely. The @ref portion of a workflow call can be a tag, a branch, or a full SHA:

# Tag — the common case
uses: my-org/platform-workflows/.github/workflows/deploy.yml@v2.1.0

# Branch — consuming HEAD, inherently unstable
uses: my-org/platform-workflows/.github/workflows/deploy.yml@main

# SHA — supply-chain hardened, but opaque
uses: my-org/platform-workflows/.github/workflows/deploy.yml@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

A tag tells you the version. A branch tells you almost nothing — the consumer is on whatever commit main happened to point to when they last ran. A SHA is precise but requires resolving the commit to a tag or branch to understand which version the consumer is actually using. Answering "who's still on v1.x?" requires understanding all three forms.

Reusable workflows vs. composite actions. GitHub Actions has two mechanisms for sharing CI logic: reusable workflows (called with uses: at the job level) and composite actions (called with uses: at the step level). They look similar in YAML but behave differently:

# Reusable workflow — job level
jobs:
  deploy:
    uses: my-org/platform-workflows/.github/workflows/deploy.yml@v2

# Composite action — step level
jobs:
  build:
    steps:
      - uses: my-org/platform-actions/setup-toolchain@v3

Both are dependencies on shared code in other repos. Both break when the interface changes. A consumer tracking system needs to find both, because platform teams often maintain a mix of reusable workflows and composite actions — and the same "who's using this?" question applies to both.

The .github repository. GitHub has a special convention: a repo named .github in an org can contain workflow templates that appear in every repo's "Actions" tab. If your platform team publishes starter workflows through the .github repo, those templates get copied (not referenced) into consuming repos. Once copied, they're no longer linked to the source — there's no uses: directive pointing back, just a disconnected copy that may or may not have been modified since.

This means some of your "consumers" are invisible. They took the template, modified it, and now maintain their own fork. You can't find them by searching for uses: directives because there aren't any.

Inputs and secrets are the breaking surface. Unlike Terraform modules, where the interface is defined by variables and outputs with explicit types, reusable workflow inputs are loosely typed. A workflow declares its inputs:

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
    secrets:
      DEPLOY_KEY:
        required: true

If you rename node-version to runtime-version, every caller that passes node-version will silently fail — the input just won't be received, and the workflow will use its default or break downstream. There's no compile-time error. The failure shows up at runtime, in the middle of a CI run, and the error message often doesn't clearly point to the renamed input.

Workflow call chains. Reusable workflows can call other reusable workflows, up to ten levels deep and fifty total workflow calls per run (GitHub increased these limits in late 2025). If workflow A calls workflow B, which calls workflow C, and you change C's interface, both A and B are affected — but only B directly references C. Finding A requires resolving the full call chain.

What the full answer requires

To reliably answer "who consumes this reusable workflow," you need a system that:

Scans every repo in the org, parsing all .github/workflows/*.yml files — not just repos that have opted into Dependabot or Renovate
Extracts uses: directives at both the job level (reusable workflows) and step level (composite actions), because platform teams typically maintain both
Resolves ref types — tags, branches, and SHAs — to a normalised version, so you can answer "who's still on v1.x?" regardless of how the ref was specified
Follows workflow call chains so you see transitive consumers, not just direct callers
Keeps the graph current through regular rescans, not one-off audits
Makes the result queryable: "show me every consumer of ci-lint-test.yml, grouped by ref, with the team that owns each calling repo"

This is one of the specific problems Riftmap is built to solve. It scans a GitHub (or GitLab) org, parses every workflow file in every repo, extracts all uses: directives — including reusable workflow calls, composite action references, and standard action pins — and builds a cross-repo dependency graph that you can query by artifact.

The result: before you rename that input or remove that step, you open the graph, click the workflow, and see exactly which repos call it and which ref each one pins to. You know who'll break. You know who to notify. You know who's pinned to main and will see the change immediately versus who's on a tagged release and has time to migrate.

No org-wide grep. No stale GitHub code search. No "let's push it and see whose CI goes red."

How is your team solving this today? I'd genuinely like to know — drop a comment or find me at riftmap.dev.

How to Find Every Consumer of Your Terraform Module

Daniel Westgaard — Wed, 15 Apr 2026 09:30:27 +0000

You maintain a shared Terraform module. You need to make a breaking change. Which repos across your org actually source it — and at which version? Here's why the answer is harder than it should be.

You maintain an internal Terraform module. Maybe it's terraform-aws-vpc or modules/rds-cluster or a shared networking baseline that half the org builds on top of. It started as a convenience — one team wrote a good VPC module, others adopted it, and now it's load-bearing infrastructure for dozens of repos.

Then you need to change it. Maybe you're upgrading the AWS provider from v4 to v5 and the module interface needs to change. Maybe you're deprecating a variable that seemed like a good idea eighteen months ago. Maybe you're fixing a security misconfiguration and the fix requires consumers to pass a new required variable.

The question is simple: which repos across our org source this module, and at which version?

If you can't answer this, you're deploying blind. You either make the change and wait for terraform plan failures to trickle in across teams, or you don't make the change at all and let the tech debt compound. Neither option is good.

The scenario

Here's what this typically looks like. Your platform team publishes a module, and repos across the org consume it:

module "vpc" {
  source = "git::https://gitlab.company.com/infra/terraform-aws-vpc.git?ref=v2.3.0"

  cidr_block = "10.0.0.0/16"
  environment = var.environment
}

Some repos pin to a specific Git tag. Some pin to a branch. Some point at main with no ref at all, which means they're consuming whatever happens to be at HEAD when they next run terraform init. Some source the module from your internal Terraform registry instead of Git. Some use a relative path because the module lives in a monorepo alongside the consuming root module.

You need to find all of them, understand which version each one uses, and figure out which teams to notify before you push the breaking change. Right now, most teams do this by grepping, searching the Terraform registry UI, or asking in Slack. None of these give you a complete answer.

What existing tools give you (and where they stop)

Several tools address pieces of the Terraform module consumer problem. Each one is useful in its own context. None of them answer the full question.

HCP Terraform (Terraform Cloud) Module Registry

If you use HCP Terraform or Terraform Enterprise, the private module registry tracks which workspaces consume a published module. The registry UI shows a module's versions, usage statistics, and which workspaces reference it.

This works within the HCP Terraform ecosystem. The limitation is scope: it only sees modules published to its registry and consumed by its workspaces. If a team sources the module directly via a Git URL — which is extremely common, especially in orgs that adopted Terraform before the private registry existed — that consumption is invisible. If some repos use HCP Terraform and others use a different backend (local state, S3, Spacelift, env0, Atlantis), you're seeing a partial picture. It's also worth noting that the HCP Terraform free tier was discontinued in March 2026, so this option now requires a paid plan.

Spacelift / Scalr / env0

Spacelift has the most advanced module consumer tracking of the orchestration platforms. Its module registry tracks which stacks consume each module version, and trigger policies can automatically kick off runs on consumer stacks when a new module version is published. Scalr offers a modules report that shows which modules and versions are used across all workspaces, including which workspaces are running outdated versions. env0 has similar workspace-level dependency awareness.

These are genuinely useful capabilities — if all your Terraform runs flow through a single platform. The limitation is the same for all of them: they only see what's inside their own ecosystem. If your org uses Spacelift for production infrastructure but engineers run terraform plan locally for development, or if one team uses Atlantis while another uses GitHub Actions with raw terraform commands, no single orchestrator has the full picture. And none of them see the module source references in the code — they see module consumption at the workspace execution level, which is a different layer.

`terraform providers` and `terraform graph`

Terraform's built-in terraform graph command outputs a DOT-format dependency graph for a single root module. terraform providers lists the providers required by a configuration and its modules.

These commands work per-configuration, not per-org. They answer "what does this root module depend on?" They don't answer "which root modules across my org depend on that shared module?" You'd need to clone every repo, run the command in every Terraform root, and aggregate the results — which is essentially building a custom scanner.

Grep / GitHub code search

The most common approach. Clone everything (or use GitHub's code search), and search for the module source URL:

grep -r "terraform-aws-vpc" --include="*.tf" ~/repos/

This finds direct string matches. It works for a one-off audit. But it breaks down in several ways that matter:

It doesn't resolve registry sources. source = "app.terraform.io/company/vpc/aws" and source = "git::https://gitlab.company.com/infra/terraform-aws-vpc.git" might reference the same module — grep treats them as unrelated strings.
It doesn't extract versions. You can see that a repo references the module, but parsing out ?ref=v2.3.0 or the version = "~> 2.0" constraint from a registry source requires additional work per match.
The results are stale immediately. The search reflects the state of whatever you cloned. By tomorrow, three repos might have changed their module references.
At 100+ repos, it takes long enough that nobody does it proactively. It becomes an incident response activity, not a planning tool.

Renovate

Renovate understands Terraform module sources and can open pull requests when a new version is available. It parses source and version attributes in .tf files and supports Git refs, registry modules, and GitHub releases.

Like with Docker images, Renovate implicitly knows who consumes what — it's configured per-repo and has parsed the module sources. But it doesn't expose this as a queryable view. You can't ask Renovate "which repos in my org source terraform-aws-vpc?" It's a dependency updater, not a dependency mapper. It reacts after a new version exists. It doesn't give you the blast radius before you publish the new version.

Why this is harder than it looks

Terraform module sourcing is more complex than most people realise, because the same module can be referenced through at least five different source types — and each one looks completely different in the HCL.

Git sources are the most common for internal modules:

module "vpc" {
  source = "git::https://gitlab.company.com/infra/terraform-aws-vpc.git?ref=v2.3.0"
}

The URL might use HTTPS or SSH. The ref might be a tag, a branch, or a commit SHA. Some teams use the git:: prefix, others rely on Terraform's URL inference. The same module can appear as:

source = "git::https://gitlab.company.com/infra/terraform-aws-vpc.git?ref=v2.3.0"
source = "git@gitlab.company.com:infra/terraform-aws-vpc.git?ref=v2.3.0"
source = "gitlab.company.com/infra/terraform-aws-vpc?ref=v2.3.0"

These all point at the same module. A grep for one form misses the others.

Registry sources use a completely different syntax:

module "vpc" {
  source  = "app.terraform.io/company/vpc/aws"
  version = "~> 2.0"
}

This references the same underlying module, but through the registry. The version constraint is in a separate attribute, not in the source URL. Matching this to the Git-sourced references requires knowing that the registry module company/vpc/aws maps to the Git repo infra/terraform-aws-vpc.

Local paths appear when modules live alongside root configurations:

module "vpc" {
  source = "../../modules/vpc"
}

This is a dependency on an internal module, but there's no URL to grep for. The relationship is purely structural — you need to resolve the relative path within the repo's directory tree.

GitHub/GitLab shorthand sources add another variant:

module "vpc" {
  source = "github.com/company/terraform-aws-vpc?ref=v2.3.0"
}

Terraform interprets this as a Git clone from GitHub, but the syntax differs from both the explicit git:: form and the registry form.

Subdirectory references complicate things further:

module "vpc_endpoints" {
  source = "git::https://gitlab.company.com/infra/terraform-aws-vpc.git//modules/endpoints?ref=v2.3.0"
}

The // separator means "clone this repo, then use the modules/endpoints subdirectory." This is a dependency on the same repo but a different module path within it. A consumer tracking system needs to handle both the repo-level relationship and the subpath.

Then there's the transitive problem. Module A sources module B, which sources module C. If you change module C, both B and A are affected — but A never mentions C anywhere in its code. Understanding the full blast radius requires resolving the entire chain, not just direct consumers.

None of the tools in the previous section handle all of these source types and resolve them to a unified view. This is why teams keep falling back to grep and tribal knowledge — and why both keep failing at scale.

What the full answer requires

To reliably answer "who consumes this Terraform module," you need a system that:

Scans every repo in the org, not just those registered in a specific orchestration platform
Parses all five source types — Git URLs (HTTPS and SSH), registry sources, local paths, GitHub/GitLab shorthand, and subdirectory references — and normalises them to a single identity per module
Extracts version constraints from both ?ref= parameters in Git sources and version attributes in registry sources
Resolves transitive dependencies so you can see not just direct consumers but the full downstream blast radius
Keeps the graph current through scheduled or event-triggered rescans, not one-off audits
Makes the result queryable: "show me every consumer of terraform-aws-vpc, grouped by version, with the team that owns each consuming repo"

This is one of the specific problems Riftmap is built to solve. It scans a GitLab or GitHub org, parses every .tf file across every repo, resolves all five module source types to a unified dependency graph, and lets you click on any module to see every consumer — direct and transitive — with the version each one pins to.

The result: before you push the breaking change, you open the graph, click the module, and see exactly which repos and teams are affected. You know who to notify. You know who's still on v1.x and who's already on v2.x. You know which repos pin to main and will break immediately versus which pin to a tag and have time to migrate.

No grepping. No Slack polling. No "let's just push it and see who complains."

How is your team solving this today? I'd genuinely like to know — drop a comment or find me at riftmap.dev.

How to Find Every Consumer of Your Docker Base

Daniel Westgaard — Mon, 13 Apr 2026 19:16:20 +0000

You maintain a shared base image. A CVE drops. Which repos are affected? Here's why the answer is harder than it should be.

You maintain an internal Docker base image. Maybe it's platform/node-base or company/python-runtime. A dozen repos use it. Or thirty. Or you're not sure how many, because nobody's counted since the last team reorganisation.

Then a critical CVE hits the base OS layer, and you need to push a patched version. The question that matters is simple: which repos across our org pull this image, and at which version?

This should be easy to answer. It isn't.

The scenario

Here's what this looks like in practice. Your platform team builds and publishes registry.company.com/platform/base-image. Across the org, Dockerfiles reference it:

FROM registry.company.com/platform/base-image:v2.1

Some repos pin to a specific tag. Some use latest. Some have ARG-parameterized FROM statements where the tag is injected at build time. Some reference the image not in a Dockerfile but in a docker-compose.yml or a CI pipeline config.

You need to find all of them, check which version each one uses, and coordinate the update. Right now, most teams do this by grepping, asking on Slack, or checking CI logs. None of these give you a complete, current answer.

What existing tools give you (and where they stop)

Several tools address parts of the Docker base image problem. Each one is useful. None of them answer the full question.

Docker Scout

Docker Scout analyzes a built image and tells you what base image it uses, whether that base is outdated, and what vulnerabilities it contains. docker scout recommendations will suggest updated base images with fewer CVEs.

This is valuable, but it works per-image, not per-org. It answers "what base image does this image use?" It doesn't answer "which of my 200 repos use this base image?" You'd need to run Scout against every image in your registry and correlate the results back to source repos — which is a project in itself.

Renovate

Renovate detects FROM statements in Dockerfiles and can open pull requests when a newer tag is available. It implicitly knows who consumes what, because it's configured per-repo and parses the Dockerfiles.

But Renovate doesn't expose this as a queryable view. You can't ask Renovate "show me every repo that references platform/base-image." It reacts when a new version appears. It doesn't give you the pre-release blast radius: before you push the patched image, which repos and teams will need to update?

Backstage / Roadie Tech Insights

Roadie (a managed Backstage provider) has a Tech Insights feature that can parse Dockerfiles via regex, extract base image versions, and create scorecards tracking migration progress. This is the closest existing solution to the consumer-tracking problem.

The limitation is that it requires Backstage to be set up with catalog-info.yaml per repo. You're tracking Docker base images through a service catalog that depends on manual registration. If a repo isn't in the catalog, its Dockerfile is invisible.

Container registries

Your registry (Docker Hub, Harbor, ACR, ECR) knows which images have been pulled and how often. Some provide pull statistics by tag. But pull logs don't tell you which source repo initiated the pull. A CI pipeline pulling base-image:v2.1 shows up as a pull event, not as "repo frontend-api depends on this image via its Dockerfile on line 3."

Grep

The fallback everyone uses. Clone all the repos, run grep -r "platform/base-image", assemble the results. It works once. The results are stale immediately. It misses parameterized FROM statements, compose files, and CI configs. And at a hundred repos, it takes long enough that nobody does it proactively.

Why this is harder than it looks

The core difficulty is that Docker base image dependencies live in multiple places and multiple formats.

Dockerfiles are the obvious source, but FROM statements can use ARG substitution:

ARG BASE_TAG=v2.1
FROM registry.company.com/platform/base-image:${BASE_TAG}

A simple grep for the image name finds this. A simple grep for the version doesn't, because the version is in a variable.

Docker Compose files reference images differently:

services:
  api:
    image: registry.company.com/platform/base-image:v2.1

This is a dependency on the same image, declared in a completely different file format.

CI pipeline configs often pull images directly:

build:
  image: registry.company.com/platform/base-image:v2.1
  script:
    - make build

A GitLab CI image: directive or a GitHub Actions container: field is another consumption point for the same base image, and it's in yet another file.

Then there's the producer-side problem. Knowing which repos consume the image is half the story. You also need to know which repo builds it. That's usually a CI pipeline with docker build and docker push commands, not something declared in a manifest. Connecting the consumer graph to the producer requires cross-referencing multiple file types within and across repos.

No single tool today connects all of these surfaces into one view.

What the full answer requires

To reliably answer "who consumes this base image," you need a system that:

Scans every repo in the org, not just the ones registered in a catalog
Parses Dockerfiles, Compose files, and CI configs, because the same image can be referenced in all three
Handles variable substitution in FROM statements by resolving ARG defaults
Detects which repos produce which images by scanning CI configs for build and push commands
Keeps the results current through scheduled or event-triggered rescans
Makes the graph queryable: "show me every consumer of platform/base-image, grouped by version"

This is one of the specific problems I'm building Riftmap to solve. It scans a GitLab or GitHub org, parses Dockerfiles (including multi-stage builds, ARG defaults, and Compose files), detects which repos produce which images via CI config analysis, and builds a cross-repo dependency graph you can query by artifact.

The result: when that CVE drops, you click on the base image in the graph and immediately see every repo that depends on it, which version each one uses, and who owns them. No grepping. No Slack archaeology. No stale spreadsheet from last quarter.

How is your team solving this today? I'd genuinely like to know — drop a comment or find me at riftmap.dev.

DEV Community: Daniel Westgaard

How to Find Every Consumer of Your Go Module

The scenario

What existing tools give you (and where they stop)

pkg.go.dev

go mod graph

Renovate and Dependabot

GitHub code search

Athens (GOPROXY)

Why this is harder than it looks

What the full answer requires

How to Find Every Consumer of Your Helm Chart

The scenario

What existing tools give you (and where they stop)

Helm itself

Artifact Hub and Chart Museums

ArgoCD and Flux

Renovate

Grep

Why this is harder than it looks

What the full answer requires

How to Find Every Consumer of Your Reusable GitHub Actions Workflow

The scenario

What existing tools give you (and where they stop)

GitHub code search

Dependabot

Renovate

GitHub API

Grep

Why this is harder than it looks

What the full answer requires

How to Find Every Consumer of Your Terraform Module

The scenario

What existing tools give you (and where they stop)

HCP Terraform (Terraform Cloud) Module Registry

Spacelift / Scalr / env0

terraform providers and terraform graph

Grep / GitHub code search

Renovate

Why this is harder than it looks

What the full answer requires

How to Find Every Consumer of Your Docker Base

The scenario

What existing tools give you (and where they stop)

Docker Scout

Renovate

Backstage / Roadie Tech Insights

Container registries

Grep

Why this is harder than it looks

What the full answer requires

`go mod graph`

`terraform providers` and `terraform graph`