You update a base image.
Three hours later, Slack explodes.
Six teams break and nobody knows why — the dependency chain was invisible until it wasn't.
Riftmap reads your GitLab or GitHub org and draws the one graph your architecture actually runs on. Click anything. See the blast radius before you ship.
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.
Six teams break and nobody knows why — the dependency chain was invisible until it wasn't.
That knowledge lived in their head, not any README — and now every infra change feels like defusing a bomb blindfolded.
You find out during the postmortem — the answer to "who's still on the old one?" lives in twelve different terminals.
AI accelerates output; it doesn't map what already exists — and three repos referencing the interface it just changed are now silently broken.
A complete lens on your infrastructure's interconnections — across every ecosystem your team actually uses.
Interactive graph of every cross-repo relationship — pan, zoom, filter by ecosystem or team.
Select any artifact and see every consumer, direct and transitive — colour-coded by impact severity.
Which repos pull your Docker base image, and on what tag? Every consumer, every version, tracked.
No service catalog, no YAML to maintain — dependencies are parsed from the source files that already define them.
One graph across Terraform, Docker, Python, Go, npm, Ansible, Helm, Kubernetes, Kustomize, ArgoCD, and CI templates — the real world doesn't respect ecosystem silos.
Managed cloud — nothing to deploy. Only a read-only token; your code is never stored permanently.
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.
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 solutionI 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.
Each of them 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.
"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."
Managed cloud today; self-hosted on the roadmap for teams whose code can't leave the network.
Managed by us — no infrastructure to stand up.
For regulated teams. Same engine, deployed inside your infra — nothing phones home.
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.
The things teams ask before rolling Riftmap out across their org. If something's missing, email us directly.
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.
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
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
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.
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.
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.
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.
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.
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.
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.