GitLab Orbit is an excellent symbol-and-SDLC graph. It is also the clearest illustration yet of the one layer that kind of graph cannot reach: the infrastructure dependencies running between your repositories.
Somewhere in the GitLab Orbit launch on 10 June is a line about, in GitLab's phrasing, "map vulnerability blast radius in minutes". I have written some version of that line more times than I can count. When a public DevSecOps company ships a graph and reaches for the exact words your product is built on, the responsible thing is to go and read everything they actually shipped before saying a word about it. So I spent two days in the docs, the data model, the source repository, and the customer write-up at the centre of the launch.
Here is what I found. "Blast radius" is two questions wearing one phrase, and Orbit answers the other one. Ask "what breaks if I change this" at the symbol layer and you get one graph. Ask it at the infrastructure layer and you get a completely different one. Orbit builds the first. It builds it well. It is not the graph that tells a platform team what a base image bump is about to take down.
What GitLab actually shipped
I want to be generous about this, because Orbit deserves it, and because what Orbit is good at and what Riftmap is for barely overlap.
Orbit indexes your code and your software lifecycle into one property graph and lets you query it with a Cypher-like language, over MCP, over REST, or from the GitLab CLI. It ships in two shapes. Orbit Local is a single-binary CLI that builds a code-only graph from a repository on your machine. Orbit Remote is the hosted version that spans a top-level GitLab.com group, and it is the one the launch is really about. It is in public beta for GitLab.com Premium and Ultimate. On the code side it parses around a dozen general-purpose programming languages and reads out definitions and cross-file references. On the lifecycle side it ingests the objects GitLab already stores: merge requests, pipelines, jobs, deployments, vulnerabilities, ownership. The docs lay all of this out plainly.
The launch leans hard on one customer, and it is a good choice. Compare the Market ran a careful test of four context strategies for an internal AI code reviewer, across 79 real merge requests with expert-annotated ground truth. The graph-grounded reviewer beat retrieval-augmented generation on inline-comment coverage, roughly 0.70 against 0.58, and the genuinely surprising finding was that RAG did worse than passing the model no context at all. That is well-run engineering and an interesting result, and you can read the whole write-up rather than the press-release version of it. If you run agents over a large GitLab codebase and you want them to stop burning a third of their token budget crawling files to work out what calls what, Orbit is a real answer to a real problem.
So let me be clear about what Orbit does that Riftmap does not attempt. Questions like where a function lives, who calls it, what a method signature touches, which pipeline ran a job, who owns a service. Across a GitLab group, Orbit answers all of that from first-party data, and Riftmap never set out to. If that is your question, use Orbit.
The word doing two jobs
Here is the conflation the whole launch quietly sits on, and it is not GitLab's invention. The industry talks about "the dependency graph of your system" as if it were one thing. It is two.
There is the symbol-and-SDLC graph. Its nodes are directories, files, the classes and functions defined in them, the symbols they import, and alongside those the merge requests, pipelines, deployments and vulnerabilities the platform tracks. Its edges are calls, imports, inheritance, and the lifecycle relationships between objects. This is the graph Orbit builds, and it is the graph that answers "who calls this function" and "which services does this CVE touch".
Then there is the artifact graph. Its nodes are the things your infrastructure is actually made of and shares between repositories. A base image. A Terraform module. A Helm chart. A reusable CI template. Its edges are the references that bind those things together across repos: a Dockerfile FROM line, a Terraform source block, a terraform_remote_state lookup, a Helm chart dependencies entry or a value reference, a GitLab CI include:project. Different nodes, different edges, a different parser surface entirely.
You do not have to take my word for which of those graphs Orbit is. Take the word of the customer GitLab chose to showcase. Compare the Market describe what they integrated as "a symbol graph", and every query they demonstrate is a code query: where is this function called, what inherits from this interface, what does changing this method signature affect. The node legend in their own diagram is directory, file, definition, imported symbol. That is the symbol layer, described precisely, by the customer in the launch. Nobody is hiding the ball here. Orbit is a symbol graph with the lifecycle bolted alongside it.
So Orbit answers blast radius at the symbol layer, change this signature and here are the callers, and at the SDLC layer, this CVE sits in these components owned by these teams. Both are real. Neither is the layer where a platform team's worst change lives.
Where the edges actually live for platform teams
Picture the change that actually keeps a platform team up at night. You bump a shared base image. Or you take a common Terraform module from v3 to v4 and tighten a variable along the way. Or you edit the values block on an umbrella Helm chart that nine services inherit from. The thing that breaks is not in the repository you are editing. It is three repos away, in a service owned by a team that has never read your module's changelog. And the edge that connects you to it was never a function call. It is a source block pinned to a tag. It was never in the code for a symbol graph to find. It only ever existed in the manifest.
This is the layer Orbit does not reach, and it is worth being precise about why, because it is not an oversight they will patch on Tuesday. Orbit's supported-language list is published, and it is general-purpose programming languages, the Pythons and Gos and TypeScripts. There is no HCL parser in it. No Dockerfile parser. No parser for chart manifests. The data model follows from that. It has first-class nodes for functions, files, merge requests, pipelines and vulnerabilities. It has no node for "this base image, consumed by these eleven repositories", because nothing in the indexing pipeline ever parsed a FROM line and resolved it across the group.
This is not laziness, it is a genuinely different problem. Building a symbol graph means running a Tree-sitter parse over source and reading out the definitions and references. That is well understood, and GitLab has done it properly. Building an artifact graph means parsing HCL to follow module source URLs, reading Dockerfiles to resolve base images back to the repositories that publish them, walking Helm value inheritance and chart dependencies, expanding CI include across projects, and then reconciling all of it across repositories that were never designed to know about each other. It is a different parser surface and a different resolution problem. It is, more or less, the entire thing Riftmap is, and it is the same line I have drawn before between symbol graphs and artifact graphs and shown in practice when finding every consumer of a GitLab CI template. Orbit being excellent does not move that line. If anything, it makes the line easier to see.
Even on its own turf, the graph stops at the platform boundary
Set the layer question aside for a moment and there is still a wall, and it is structural rather than a matter of pricing. Orbit Remote is GitLab.com only. The lifecycle side streams out of GitLab by change-data-capture into a managed graph, and the code side is served over GitLab's own internal API. There is nowhere in that design for a repository GitLab does not host. Orbit Local exists, but it is a code-only graph of a single repository on your machine, not a picture of your organisation.
The trouble is that the organisations who feel cross-repo pain most acutely, the 50 to 300 repo polyrepo shops, are rarely tidy single-platform estates. They are GitHub with a bit of GitLab. Or GitHub with a self-managed GitLab for the regulated workloads. Or three acquisitions sitting on three different platforms with no intention of consolidating this year. The dependency that actually bites in that world is the one running from a GitHub application repository onto a base image published from a GitLab repository, and that is precisely the edge a GitLab-only graph cannot draw. Reading the edges from source, and reading them across GitHub and GitLab and Bitbucket alike, is not a feature you bolt onto a platform-native graph afterwards. It is a different starting point.
Two graphs, not a fight
I have come round to thinking Orbit is less a competitor than a very large, very well-funded proof that this category is real. For the symbol-and-SDLC layer, inside a GitLab shop, it is a good graph, and I would point people at it. The artifact layer is a different graph that answers a different question. Not "who calls this function" but "what breaks if I change this base image". The two do not compete. They stack.
And the useful part is that both are MCP servers. An agent reviewing an infrastructure change wants the symbol graph for the code in front of it and the artifact graph for the consequences it cannot see. Claude Code can call both in the same review. Orbit for the function being edited. Riftmap for the eleven repositories downstream of the image that function's service is built on. This was always the shape of it. The agent is a consumer of the graph underneath, and the only interesting question was ever which graph. The launch just made the answer sharper.
So here is where two days of reading actually landed me. The biggest player in the space shipped a dependency graph, reached for the words blast radius, and proved with a real customer that a structured graph beats letting a model guess. And it still does not parse a single FROM line. The layer where your worst change lives, the infrastructure your repositories quietly share but no symbol graph can see, is still unmapped. Parsed, not inferred. Auto-discovered, never declared. Read across every platform you actually run on, not just the one that happens to host the graph. Those turn out to be different gifts. Only one of them tells you what you are about to break.
A few questions, answered directly
Does GitLab Orbit map infrastructure dependencies across repositories (Terraform, Helm, Docker)?
No. Orbit indexes source code in general-purpose programming languages and the SDLC objects GitLab already stores. Its published language list contains no HCL parser, no Dockerfile parser, and no parser for chart manifests, so it does not resolve a Terraform source block, a Dockerfile FROM line, or a Helm value reference into a cross-repo edge. It maps blast radius at the code-symbol and lifecycle layers, not at the infrastructure artifact layer.
Does GitLab Orbit work across GitHub, or only GitLab?
Only GitLab, and the limit is architectural rather than a question of pricing tier. Orbit Remote builds its graph from GitLab data streamed through GitLab's own internal services, so there is nowhere in the design for a repository GitLab does not host. Orbit Local can graph a single repository on your machine, but it is code-only and does not span an organisation. If your estate is GitHub, mixed, or self-managed, Orbit Remote cannot draw the edges between your repos.
What is the difference between a symbol graph and an artifact dependency graph?
A symbol graph indexes the things inside your code: files, the functions and classes defined in them, and the calls and imports between them. It answers "who calls this function". An artifact dependency graph indexes the things your repositories share at the infrastructure layer: base images, Terraform modules, Helm charts, CI templates, and the references that bind them across repos. It answers "what breaks if I change this base image". They are different graphs, built by different parsers, and blast radius on an infrastructure change needs the second one.
About Riftmap
Riftmap maps cross-repo dependencies across your entire GitLab or GitHub organisation — Terraform, Docker, CI templates, Helm, and more. One read-only token. No YAML to maintain.
