riftmap · live

Know what breaks
before you break it.

Riftmap reads your GitLab or GitHub org and draws the one graph your architecture actually runs on. Query anything from your agents. Click anything in the UI. See the blast radius before you ship.

Or wire it into your agent Read-only token Code never persists Ephemeral by design
free for 15 repos ~90s first scan scope · read_api
Built in Norway by a solo founder
reads what's already there
GitLab GitHub Terraform Docker Kubernetes Helm Ansible Python Go npm
Agent demo · 0:15 · loop

Watch an agent answer “what breaks if I ship this?”

See the full walkthrough

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.

01 / ai-generated change

AI ships code 10× faster.
It doesn't know what already exists.

AI accelerates output; it doesn't map what already exists — and three repos referencing the interface it just changed are now silently broken.

compounds every sprint + 312 lines · − 47 lines · 0 edges checked
↳ the same problem, the other direction
Your agents need the graph too. Without it, they reconstruct it on every invocation — at 30× the token cost of a single lookup.
02 / base-image update

You update a base image.
Three hours later, Slack explodes.

appears at ~50 repos base-image ───▶ 17 consumers ───▶ 41 transitive
03 / knowledge loss

The senior who knew why
service B depends on module A just left.

symptom grep -r, ag, gh search auth-gateway ??? payment-engine ??? risk-engine
04 / version drift

Twelve repos reference your base image.
Four are on v2.1, three on v2.3, two on v3.0.

drift v2.1 · v2.3 · v3.0 ● ● ● ● ● ● ● ● ● · 9/12 out of sync
↳ the fix
is not another service catalog.

Stop reconstructing the graph in your head.
Read it from the source.

capabilities / 07

What Riftmap sees that you can't.

A complete lens on your infrastructure's interconnections — across every ecosystem your team actually uses.

01

Visual dependency graph

Interactive graph of every cross-repo relationship — pan, zoom, filter by ecosystem or team.

↳ edges · all ecosystems
312 edges
02

Blast radius analysis

Select any artifact and see every consumer, direct and transitive — colour-coded by impact severity.

↳ severity
HIGH · 6
MED · 11
LOW · 24
03

Artifact consumer tracking

Which repos pull your Docker base image, and on what tag? Every consumer, every version, tracked.

↳ base-go
v2.1 ████ · 4
v2.3 ███ · 3
v3.0 ██ · 2
04

Auto-discovered, never declared

No service catalog, no YAML to maintain — dependencies are parsed from the source files that already define them.

↳ parses
Dockerfile · FROM
*.tf · module
.gitlab-ci.yml · include
05

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.

↳ 12 ecosystems
06

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.

↳ endpoints
repositories/lookup
repositories/{id}/context
repositories/{id}/impact
# "What breaks if I ship this?"
$ 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 }
07

Zero ops, secure by design

Managed cloud — nothing to deploy. Only a read-only token; your code is never stored permanently.

↳ access
scope · read_api
write · denied
retention · ephemeral
Riftmap artifacts view for github.com/prometheus/client_model: 23 total consumers across multiple ecosystems, with a per-consumer table showing repository, path, status (21 ok, 2 cracked), and last-scan timestamp
alternatives / 07

You've probably tried these. Here's where they break.

01
Grepping across repos
grep · ag · gh search
Manual search across the org

Snapshot not a living graph, misses transitive deps, falls apart past 50 repos.

wrong tool
02
Backstage
Spotify · service catalog
Developer portal / YAML catalog

A YAML catalog only as accurate as whoever last updated it. Stale within weeks.

too heavy
03
Renovate / Dependabot
automated update PRs
Keeps dependencies up-to-date

Keeps deps updated — tells you nothing about who consumes what. No blast radius.

partial only
04
HCP Terraform Explorer
HashiCorp Cloud Platform
Module explorer · Terraform-only

Terraform-only, HCP-only, and only module relationships — not the full cross-ecosystem picture.

partial only
05
"Just use a monorepo"
consolidate everything
One repository to rule them all

Not feasible for orgs with existing infra. And a monorepo still doesn't show blast radius.

not a solution
06
Tribal knowledge
ask the longest-tenured engineer
The person who knows

Works until they leave. Six months of undocumented changes later, you're back to square one.

not a solution
07
Bundle every repo into the agent's workspace
"virtual monorepo" · workspace pattern
Let the coding agent grep across N cloned repos

Genuinely 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 it
industry signal / 06

The thesis isn't ours alone.

Meta and Mabl shipped public engineering posts in April 2026 arguing the same point. Amazon shipped an incident report using the exact phrase. Cross-repo dependency intelligence is becoming runtime infrastructure for AI coding agents.

Meta · engineering blog · April 6, 2026

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.

↳ ~30× efficiency on the most common planning question
4 repos · 3 languages · 4,100+ files · 50+ specialised agents
Mabl · engineering blog · April 8, 2026
Geoff Cooney, Mabl Engineering

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%.

↳ 39% of commits AI-assisted by Feb 2026 (60% in infra repos)
25 engineers · 100+ repos · 200+ PRs and 40+ releases per month
Amazon · internal memo (FT-reported) · March 2026

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."

↳ 13-hour AWS recovery · phrase entered mainstream tech press
 
↳ by the numbers
23.5%
incidents per PR, up since AI adoption Cortex 2026
~30%
change failure rate increase Cortex 2026
1.7×
defect rate of AI-generated code vs human code CodeRabbit
~90%
of engineering orgs use AI coding tools Cortex 2026 · DORA 2025
30×
fewer tokens: graph lookup vs file exploration for “what depends on X” — the architectural delta Meta 2026

Three organisations. One conclusion. Riftmap is the productised version.

validation / 07

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.

↳ the strongest signal

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.

01
nightly clone + grep + sqlite

Build it overnight, query it in the morning.

Worked until ~80 repos. Grep across that volume gets expensive.

02
python crawler + GitLab API

Custom crawler against the GitLab API, persisted to a database.

Maintenance burden grew faster than the rest of the platform team.

03
CI-driven dependency parser

Parsing in CI, surfacing relationships per pipeline run.

Reasonable signal per repo. No transitive coverage across the org.

04
in-house graph · neo4j

Closest to a real solution. A small team, half a quarter of work.

Worked once built. Nobody had time to keep it current.

05
TOML registry + manager agent

Solo founder pattern. A registry plus a manager agent in the loop.

Holds together for one operator. Doesn't survive a team of ten.

06
850-line hand-maintained coordination graph

A 25-engineer testing company, 79 repos, registry maintained by hand.

Effective at scale. Expensive enough that automating it is the next obvious move.

practitioner conversation · private · May 2026

"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."

Senior engineer at a Norwegian DevOps consultancy, on evaluating developer portals
↳ from the person building this

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
↳ from the r/devops thread (86 comments, 35K views)

"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."

r/devops

"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."

r/devops

"It's either build-your-own graph, lean on pinning to slow the blast radius, or accept the chaos."

r/devops
deployment / 08

Ship in minutes. Not in a quarter.

Managed cloud today; self-hosted on the roadmap for teams whose code can't leave the network.

available now
01

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
Get started free
planned
02

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
Contact us about self-hosted
pricing / 09

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.

no credit card · read-only GitLab / GitHub token · setup under 5 minutes
faq / 13

Questions, answered.

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.

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

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.

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

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.