Know what breaks
before you break it.
Change a shared base image, Terraform module, or Helm chart — and know exactly which repos break, before you ship. Riftmap parses the infrastructure dependencies no other tool can see, straight from your GitLab or GitHub org: the ones that used to live only in your senior engineer's head. No catalog to maintain.
Read-only token Code never persists Ephemeral by design Built in Norway by a solo founderCode-symbol tools stop at the language boundary. Riftmap is the only graph that parses your infrastructure.
Every engineering org
hits the same wall.
Somewhere around fifty repositories, the mental model breaks. The senior engineer who held the graph in their head takes a week off, and suddenly a one-line change in a base image lights up Slack for three hours.
You update a base image.
The senior who knew why
service B depends on module A just left.
Twelve repos reference your base image.
Four are on v2.1, three on v2.3, two on v3.0.
And AI just moved the wall closer.
AI ships code 10× faster — and none of it checks a single cross-repo edge before merging. The blast radius problem you were going to hit at 100 repos, you now hit at 50. That cross-repo reach has a name: the AI agent blast radius.
Your agents need the graph too. Without it, they reconstruct it on every invocation — at 30× the token cost of a single lookup.
is not another service catalog.
Stop reconstructing the graph in your head.
Read it from the source.
What Riftmap sees that you can't.
A complete lens on your infrastructure's interconnections — across every ecosystem your team actually uses.
Visual dependency graph
Interactive graph of every cross-repo relationship — pan, zoom, filter by ecosystem or team.
Blast radius analysis
Select any artifact and see every consumer, direct and transitive — colour-coded by impact severity.
Artifact consumer tracking
Which repos pull your Docker base image, and on what tag? Every consumer, every version, tracked.
Auto-discovered, never declared
No service catalog, no YAML to maintain — dependencies are parsed from the source files that already define them.
Cross-ecosystem
One graph across Terraform, Docker, Python, Go, npm, Ansible, Helm, Kubernetes, Kustomize, ArgoCD, and CI templates — the real world doesn't respect ecosystem silos.
Agent-ready API
The same graph, served as JSON. Three endpoints — /lookup, /context, /impact — let Claude Code, Cursor, or any coding agent query the blast radius before they ship. MCP server and CLI on the roadmap.
$ curl api.riftmap.dev/api/v1/repositories/{id}/impact \
-H "X-API-Key: $RIFTMAP_KEY"
{ "affected": [
{ "repo": "acme/platform-prod", "depth": 1 },
{ "repo": "acme/monitoring", "depth": 2 }
], "total_affected": 7 } Zero ops, secure by design
Managed cloud — nothing to deploy. Only a read-only token; your code is never stored permanently.
Watch an agent answer “what breaks if I ship this?”
The same graph your platform team reads in the UI, queried as a tool call. If your org runs coding agents, this is what they've been missing.
You've probably tried these. Here's where they break.
Snapshot not a living graph, misses transitive deps, falls apart past 50 repos.
wrong toolA YAML catalog only as accurate as whoever last updated it. Stale within weeks. Full comparison
too heavyKeeps deps updated — tells you nothing about who consumes what. No blast radius.
partial onlyTerraform-only, HCP-only, and only module relationships — not the full cross-ecosystem picture.
partial onlyNot feasible for orgs with existing infra. And a monorepo still doesn't show blast radius.
not a solutionWorks until they leave. Six months of undocumented changes later, you're back to square one.
not a solutionGenuinely good up to ~50 repos. Past that, maintenance drifts and the agent re-discovers the graph on every invocation. The dependency graph is the substrate underneath — what the workspace pattern grows into.
until you outgrow itCode-symbol graphs built from AST parsing — they map functions and imports inside your code. None parse infrastructure: no Terraform, Helm, Docker, or CI edges, and most are single-repo or DIY-scaled and pip-installed per developer.
code onlyThe thesis isn't ours alone.
Amazon's incident memo put "high blast radius" into the mainstream tech press. Meta and Mabl shipped engineering posts the same spring, arguing from the agent side of the same problem. Three organisations, three angles, one conclusion: past a certain repo count, nobody can answer "what depends on this?" — and the cost of not knowing now shows up in incident reports.
Amazon's SVP of eCommerce Services attributed a pattern of production incidents partly to AI coding tools, in an internal memo whose pulled phrase was "high blast radius."
After shipping Cross Repo Base — an 850-line coordination graph across 79 repositories — context drift dropped from around 40% of agent failures to under 5%.
A cross-repo dependency lookup turned the question "what depends on X" from a multi-file exploration around 6,000 tokens into a single graph lookup around 200 tokens.
Three organisations. One conclusion. Riftmap is the productised version.
I asked the community first. The signal was loud.
I posted in r/devops and r/terraform to test whether this was a real problem. 86 comments and 35,000 views later, the strongest signal wasn't a complaint.
Six independent engineers had already built their own.
Each converged on the same architecture — parse the source files, build a graph, query the blast radius — without coordinating. Each solved part of the problem for their own team. None of them productised it.
Build it overnight, query it in the morning.
Worked until ~80 repos. Grep across that volume gets expensive.
Custom crawler against the GitLab API, persisted to a database.
Maintenance burden grew faster than the rest of the platform team.
Parsing in CI, surfacing relationships per pipeline run.
Reasonable signal per repo. No transitive coverage across the org.
Closest to a real solution. A small team, half a quarter of work.
Worked once built. Nobody had time to keep it current.
Solo founder pattern. A registry plus a manager agent in the loop.
Holds together for one operator. Doesn't survive a team of ten.
A 25-engineer testing company, 79 repos, registry maintained by hand.
Effective at scale. Expensive enough that automating it is the next obvious move.
"I've looked at Backstage in projects before. In practice, setting it up and keeping it maintained is bigger than what you get back in many cases."
I'm Daniel, a software and DevOps engineer based in Norway, operating under Westgaard Technologies. Riftmap is what happens when the pattern above gets finished instead of abandoned — and the person you'll talk to when you have a question.
More about why I'm building this"What helped most was auto-generating a dependency map from Terraform sources, Dockerfiles, and shared CI includes. Once we had that, impact analysis got much easier — it stopped living in senior engineers' heads."
"The dependencies outside of Terraform is exactly where it gets unmanageable — pipeline scripts, triggers, Helm charts, Ansible roles, all referencing each other across repos with no single place to see the full picture."
"It's either build-your-own graph, lean on pinning to slow the blast radius, or accept the chaos."
Ship in minutes. Not in a quarter.
Managed cloud today; self-hosted on the roadmap for teams whose code can't leave the network.
Cloud-Hosted
Managed by us — no infrastructure to stand up.
- + Zero infrastructure to run
- + Read-only token — no write permissions needed
- + On-demand and scheduled scans
- + Team collaboration & sharing
- + Isolated per workspace
Self-Hosted
For regulated teams. Same engine, deployed inside your infra — nothing phones home.
- + Docker Compose & Helm chart
- + Zero code egress — repos stay in your network
- + GitLab CE/EE & GitHub Enterprise support
- + Air-gapped deployments supported
- — Not yet GA — contact for timeline
Start free. Pay when it's load-bearing.
Free for personal use and small teams. One simple tier for growing orgs, and custom plans when scale or self-hosting enters the conversation. No seat taxes, no per-repo surprises.
Questions, answered.
The things teams ask before rolling Riftmap out across their org. If something's missing, email us directly.
01 How does Riftmap discover dependencies without me writing any config?
It uses static analysis on the files already in your repos — Terraform source blocks, Dockerfile FROM lines, go.mod requires, and nine more ecosystems. No annotations, no catalog YAML to maintain. The harder part is what comes after parsing: Riftmap resolves each reference against your Git orgs, public registries, and internal Terraform registries, stitches direct and transitive edges across ecosystems (e.g. a repo → Terraform module → Docker image → the repos that run it), and keeps the graph current through incremental rescans rather than a one-shot snapshot. See the ecosystems question below for the full list of parsers.
02 Does Riftmap need write access to my repos?
No. Riftmap only needs a read-only personal access token (GitLab) or a fine-grained token with Contents: Read permission (GitHub). It will never create commits, open issues, or modify anything in your repos. More on our security model
03 Is my source code stored on your servers?
Riftmap clones your repositories to perform analysis, but code is not stored permanently. Analysis runs in an isolated per-workspace environment. Only the extracted dependency metadata (file paths, module names, version strings) is persisted — not your source code. Riftmap only requires a read-only token and never modifies anything in your repositories. More on our security model
04 How long does the initial scan take?
Typically 2–10 minutes for orgs with up to 300 repos, depending on repo size and network speed. After the initial scan, incremental rescans run in the background and complete in seconds for most orgs. You can trigger a manual rescan at any time.
05 What ecosystems does Riftmap support today?
Currently supported (12 ecosystems): Terraform module sources, Dockerfile FROM statements (including multi-stage builds), GitLab CI includes and extends references, GitHub Actions workflow calls, Python requirements (requirements.txt, setup.py, pyproject.toml), Ansible role dependencies, Helm chart dependencies (Chart.yaml), Go modules (go.mod), npm packages (package.json), Kubernetes manifests, Kustomize overlays (kustomization.yaml), and ArgoCD Application/ApplicationSet manifests. More ecosystems are added based on user feedback.
06 Can it handle private registries and internal Terraform modules?
Yes. Riftmap parses module source strings and resolves them against your GitLab/GitHub org, your internal Terraform registry, and public registries (registry.terraform.io). For Docker, it handles private registries — just point Riftmap at your registry hostname and it will match FROM statements accordingly.
07 How is this different from Backstage?
Backstage is a developer portal where humans fill in a catalog YAML and keep it updated. It's only as accurate as the last person who edited it. Riftmap discovers the dependency graph by reading the actual source files, so it's always current. You don't maintain anything — it's self-updating.
08 Do I need to set up any infrastructure?
No. Riftmap is a managed cloud service — just sign up at app.riftmap.dev, connect your GitLab or GitHub org with a read-only token, and you are ready to go. We handle all the infrastructure. A self-hosted option for teams that need on-premises deployment is planned for the future.
09 Can it detect transitive dependencies, not just direct ones?
Yes — the graph is fully transitive. If repo A uses Terraform module M, and module M uses Docker image D, Riftmap will show that updating D has a transitive impact on repo A, even though A never mentions D directly. The blast radius view always shows all levels of the cascade.
10 Can AI coding agents query Riftmap directly?
Yes. Riftmap exposes an HTTP API designed to be called by coding agents during planning. Three endpoints cover the common questions — `/repositories/lookup` to resolve a clone URL to a Riftmap repo ID, `/repositories/{id}/context` to hydrate dependencies and dependents in one round-trip, and `/repositories/{id}/impact` for transitive blast radius. Each response carries freshness fields (`last_scanned_at`, `last_commit_sha`) so the agent can tell when the graph is stale. Full schema at `app.riftmap.dev/openapi.json`. See the agent integration docs
11 Does Riftmap replace my coding agent's context window?
No. Riftmap is the substrate the agent calls into during planning. The agent keeps its context window for code reasoning; Riftmap answers the cross-repo questions ("who depends on this?", "what's the blast radius of changing this artifact?") that no agent can answer from inside a single repo's clone. Same graph the UI shows, served as JSON.
12 Is there an MCP server?
Not yet — the HTTP API is available today and is the recommended path. An MCP server and a CLI are next on the roadmap. Track status and timing on the agents roadmap
13 How do I get started?
Sign up for free at app.riftmap.dev. The free tier gives you up to 15 repositories, full dependency graph and impact analysis, and all 12 ecosystem parsers — no credit card required. When your org outgrows the free tier, you can upgrade to Team or Business for more repos, seats, and advanced features like scheduled scans.