Skip to main content
Riftmap answers one question: if I change repo X, what else breaks? It answers it by reading what your repositories declare — manifests, lockfiles, Dockerfiles, Terraform sources, CI workflow references — and resolving those declarations to other repositories in the same org. That approach is deterministic and has no per-repo configuration, which is the point. It also has a definite edge, and this page is where that edge is written down.

​
What we detect

Riftmap also detects what each repo produces — Docker images, npm packages, Python distributions, Helm charts, Terraform modules — and matches producers to consumers, so an edge can exist even when the two repos never name each other directly.

​
What we do not detect yet

Runtime coupling. A service that calls another service over HTTP declares nothing about it in any manifest. If your repos are named billing-api, zoho-client, orders-client, most of your real architecture is service-to-service HTTP — and Riftmap cannot currently see any of it. This is the single largest gap, and the one most likely to explain a near-empty graph. Contract-level coupling. Shared OpenAPI specs, protobuf definitions and GraphQL schemas describe exactly the dependencies that runtime coupling creates. Parsing them is the planned answer to the gap above. Shared infrastructure. Two services on the same database, queue or bucket are coupled in practice and identical in every manifest. Monorepo-internal imports. Within a single repository, Riftmap maps what that repo depends on — not how its internal packages depend on each other. Vendored and copy-pasted code. Code duplicated rather than depended on leaves no declaration behind.

​
Why your graph might look empty

A scan can be completely correct and still produce very few edges. The usual cause is not a bug and not a misconfiguration:
  • You don’t publish internal packages. If nothing in your org depends on anything else in your org by name, there is no manifest-level edge to find. Orgs that build many standalone services and share nothing through a package registry legitimately have almost no packaging coupling.
  • Your coupling is runtime, not packaging. See above. This is very common for services organisations, and it is our gap, not yours.
  • The scan didn’t see everything. Check the scan on the Scans page: failed_repos > 0 means some repos could not be processed, and a repository-limit banner means some were skipped by your plan.
When a graph is mostly unconnected repositories, Riftmap now says so directly rather than rendering a field of dots without explanation, and hides the unconnected repos by default so the real edges are visible. Nothing is deleted — the count is stated and one click brings them back. A low resolution rate is not in itself a problem. Most declarations in any real repository point at third-party packages (react, fastapi, alpine), and those are supposed to stay unresolved. The only meaningful question is whether an unresolved reference names a repo in your own org.

​
Tell us what we’re missing

If your repositories depend on each other in a way this page doesn’t cover, that is the most useful thing you can send us — it is how coverage gets prioritised. Email hello@riftmap.dev and describe the coupling.