The breaking change cascade
You update a base Terraform module or Docker image. Three hours later Slack explodes — six teams are broken and nobody knows why. The dependency chain was invisible until it wasn't.
Dependency Intelligence
Know what breaks
before you break it
Riftmap scans your GitLab or GitHub org, maps every cross-repo dependency — Terraform modules, Docker images, CI templates, Python packages — and shows you exactly what breaks when you make a change.
Works with
GitLab GitHub Terraform Docker Python Ansible Helm
The Problem
Sound familiar?
Every team hitting a certain scale runs into these walls. They're not skill problems — they're visibility problems.
The senior engineer leaves
The person who knew why service B depends on module A is gone. That knowledge lived in their head, not in any README. Now every infra change feels like defusing a bomb blindfolded.
The new hire is lost
Week two, they ask: "Which repos consume our shared Terraform modules?" You say "grep around". They spend two days exploring 80 repos and still don't have the full picture.
The version drift
Twelve repos reference your Docker base image. Four use v2.1, three use v2.3, two use v3.0. You discover this during an incident postmortem. Keeping them in sync requires full-time babysitting.
Setup
Three steps. No YAML to maintain.
Riftmap discovers your dependency graph automatically by reading what's already in your repos.
01
Connect
Point Riftmap at your GitLab or GitHub org with a read-only token. No write permissions needed. It runs in your own infrastructure, so your code never leaves your network.
02
Scan
Riftmap clones every repo and parses Terraform sources, Dockerfile FROM statements, CI include/extends directives, and Python requirements. No agents. No instrumentation. Just static analysis.
03
See the blast radius
Click any module, image, or package to instantly see every repo that depends on it — directly or transitively. Know the impact before you merge, not after you deploy.
Capabilities
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 across your entire org. 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. Know before you push.
Artifact consumer tracking
Which repos pull your Docker base image? What version? Riftmap tracks every consumer and the exact tag they use.
Auto-discovered, never declared
No service catalog to fill in, no YAML to write. Dependencies are parsed from the source files that already define them.
Cross-ecosystem
Terraform, Docker, Python, Ansible, Helm, CI templates — one graph that crosses all boundaries. The real world doesn't respect ecosystem silos.
Self-hosted by default
Run Riftmap in your own cluster with Docker Compose or Helm. Your source code never touches our servers. A cloud option is coming for teams that want zero ops.
Alternatives
You've probably tried these
We've been there. Here's why the obvious solutions don't quite fit.
Grepping across repos
Manual search with grep, ag, or GitHub search
Takes hours, gives you a snapshot not a living graph, misses transitive deps, and falls apart once you have 50+ repos.
Backstage
Spotify's developer portal / service catalog
Requires humans to fill in and maintain a catalog YAML. It's only as accurate as whoever last updated it. Stale within weeks.
Renovate / Dependabot
Automated dependency update PRs
Great for keeping deps updated — but tells you nothing about who consumes what. No blast radius. Different problem entirely.
HCP Terraform Explorer
HashiCorp Cloud Platform module explorer
Only works with Terraform, only works with HCP/Terraform Cloud, and only shows module relationships — not the full cross-ecosystem picture.
"Just use a monorepo"
Consolidate everything into one repository
Not feasible for most orgs with existing infra. And a monorepo still doesn't show you blast radius — it just makes grep slightly easier.
Tribal knowledge
Ask the person who's been here the longest
Works until that person leaves. Then you're back to square one — except now you also have six months of undocumented changes.
Riftmap was built specifically for this gap.
See it in actionDeployment
Your infrastructure, your rules
Your source code contains your secrets. We built Riftmap so it never has to leave your network.
Early access
Self-Hosted
Run Riftmap entirely within your own infrastructure. Your repositories are cloned and analysed locally — nothing is sent to external servers.
- Docker Compose & Helm chart included
- Zero code egress — repos stay in your network
- GitLab CE/EE & GitHub Enterprise support
- Read-only token — no write permissions needed
- Air-gapped deployments supported
Coming soon
Cloud-Hosted
For teams that want dependency mapping without the ops overhead. Connect your org, and Riftmap handles the rest in our secure, isolated cloud environment.
- Zero infrastructure to run
- Automatic rescans on schedule
- SOC 2 compliant, isolated per org
- Team collaboration & sharing
- PR comment integration
Early Access
See your own blast radius
Join the early access group. We'll help you get Riftmap running against your org and see your dependency graph for the first time.
You're on the list!
We'll be in touch with next steps. Keep an eye on your inbox.
Something went wrong — please try again or email us directly.
No credit card
|
No sales call
|
Cancel anytime
FAQ
Questions & answers
01 How does Riftmap discover dependencies without me writing any config?
It uses static analysis on the files already in your repos. For Terraform, it reads source = "..." module blocks. For Docker, it reads FROM statements in Dockerfiles. For CI, it reads include: and extends: directives in .gitlab-ci.yml and .github/workflows/ files. For Python, it reads requirements.txt, setup.py, and pyproject.toml. No annotations or decorators required.
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.
03 Is my source code sent to your servers?
In self-hosted mode: never. Riftmap runs entirely inside your infrastructure. Your repos are cloned to a local volume and analysed locally. Nothing is sent externally. In the future cloud-hosted offering, repos will be cloned ephemerally into an isolated per-tenant sandbox and deleted after analysis, but that option does not exist yet.
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 in early access: 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 roles, Helm chart dependencies, and Go modules are on the near-term roadmap.
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 What's the minimum infrastructure required to run Riftmap self-hosted?
A Docker host with at least 2 vCPUs and 4 GB RAM is sufficient for orgs up to ~500 repos. We provide a Docker Compose file and a Helm chart. For production we recommend Kubernetes with persistent storage for the graph database, but a single VM works fine for getting started.
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 What does the early access programme involve?
We work with you directly to install Riftmap against your org and validate that the dependency graph is accurate. You give us feedback on what's missing or broken. In exchange, you get the product for free during early access, and you get to shape the roadmap. We're not looking for hundreds of early access customers — we want a small group we can work with closely.
Have a question that's not here? Email us directly.
We asked the community first
Before writing a line of code, we posted in r/devops and r/terraform to ask whether this was a real problem. 86 comments and 35,000 views later, we had our answer.
The strongest validation signal: Six independent practitioners had already built their own version — nightly clone + grep + SQLite, Python scripts crawling the GitLab API, CI-driven dependency parsers. Each solved part of the problem. None productised it. They converged on the same architecture independently, which means the approach is sound and the market gap is real.