On 31 March 2026, Zohar Einy, the CEO of Port, published a post with a headline that did the rounds all spring. "Backstage is dead. Not because it was bad. But because the world moved on," he wrote. His sharper line was the one platform engineers kept re-sharing: "The UI isn't where the value is anymore."
Ten weeks later GitLab shipped Orbit, its Knowledge Graph, and one of the first screenshots on the marketing page is a blast-radius graph. "The context layer for AI agents," the tagline says. Not a portal. Not a catalog. A graph you query.
So the discourse has a new shape. Backstage is dead, or it still runs most of the internal-developer-portal market, depending on whose post you read that week. Port is the successor, or Orbit is, or the developer portal itself is finished and the graph won.
Here is the claim I want to plant before any of that. GitLab Orbit is not a developer portal, and it is not trying to be one. It ships no service catalog, no scorecards, no ownership pages, and its own documentation never once uses the word "portal." But the more useful point is that the question "is Orbit a portal, and does it replace Backstage" is aimed at the wrong axis. Whatever you call the thing that claims to know all your services, a catalog, a knowledge graph, a portal, none of Backstage, Port, or Orbit parses the artifact layer. So none of them can tell you which repositories a base-image bump or a Terraform-module change is about to break across a mixed GitHub-and-GitLab estate. That is the question that survives the catalog wars, and right now it has no winner.
The question everyone is asking is the wrong one
The trouble with "does Orbit replace Backstage" is that it treats three different things as if they were one product with one job. They all wear the same loose label, the thing that knows about all your services, and that label hides more than it reveals.
A developer portal is a human-facing catalog with a UI on top: services, owners, docs, APIs, scorecards, golden paths. A knowledge graph like Orbit is a machine-facing index of code symbols and lifecycle metadata, built to answer queries, mostly from agents. An artifact graph is the resolved map of which repository's Dockerfile, Terraform module, or Helm chart feeds which other repository. Three layers, three jobs, three buyers. The catalog wars are being fought between the first two. The third has no combatants at all, which is the part I keep coming back to.
What a developer portal actually is
The two products people mean when they say "portal" are Backstage and Port, and at heart each is a registered catalog: a human writes down what exists, and the tool renders it, governs it, and puts a search box in front. That is genuinely useful. The line I want to draw is about how they know what they know, not whether they are worth running.
Backstage: the catalog is real, and it is hand-authored
Backstage titles its own homepage "Backstage Software Catalog and Developer Platform," and the catalog is the heart of it: one place for every service, its owner, its docs, its APIs, its scorecards, wired to templated golden paths for spinning up new components. The adoption is not in doubt. Its own "Wrapped 2025" post counts 3.4k+ adopters and 31k stars as of 30 December 2025. If you want a portal, this is the centre of gravity, and I have a lot of respect for what it does.
The mechanism is the thing to be precise about. Entities enter the catalog as human-authored YAML. Backstage's own docs say it plainly: "Teams owning the components are responsible for maintaining the metadata about them, and do so using their normal Git workflow." A component is a catalog-info.yaml file, committed to a repo, maintained by hand. Discovery processors do crawl your org and register the files they find, but the GitHub provider is pointed at catalogPath: '/catalog-info.yaml' and finds files that already exist. It does not write them, and it does not infer entities from your code. This is the catalog-maintenance trap: the YAML is accurate only as of the last person who edited it.
Backstage is chasing the same wave as everyone else, and fairly. It has shipped MCP server support, and its Wrapped post frames the catalog as infrastructure that now serves "both your human developers and their AI helpers." Concede that plainly. But it is Backstage exposing its already-registered catalog to agents over MCP, not parsing the catalog into existence from your code. The entry mechanism is unchanged.
Port: modelled, not parsed, with an AI assist on population
Port self-describes as "the internal developer portal," and its blueprints are the honest expression of its architecture. Port's own guide: "Blueprints are the foundational building blocks of the internal developer portal. They hold the schema of the entities you wish to represent in the software catalog," and they are "completely customizable." That flexibility, a schema you define yourself rather than one you inherit, is Port's real advantage. You bring your own data model. This is well-built, well-resourced software.
And Port has moved on drift. Its software-catalog page advertises AI that auto-relates catalog components, mapping the connections between components you have already discovered, on top of auto-discovery across a hundred-plus built-in integrations. That is a genuine mitigant, and it would be wrong to say Port's catalog "just drifts" as if nothing had changed. The honest line is narrower. The schema, the blueprint, is still modelled by a human. The AI relates and populates over data Port already holds through its integrations, it does not parse your repositories for structure nobody declared. It is a maintenance aid on a registered architecture. These are still modelled graphs, not parsed graphs.
What Orbit actually is, and why "portal" gets it backwards
Orbit is not a catalog you fill in. It is a graph GitLab builds by parsing your code and lifecycle data, then serves to machines. That is the architectural inverse of a portal, and it is why the question gets it backwards.
Give Orbit its due, because the scale is real. GitLab's launch blog reports it indexed over 40,000 projects, 500 million nodes, and 2 billion edges in under 45 minutes. It is a single Rust binary backed by ClickHouse or DuckDB, driven by a YAML ontology, and it "serves the combined graph over a Cypher-like DSL, MCP, REST, and the GitLab CLI." It parses somewhere between twelve and fourteen programming languages, depending which GitLab source you read: the launch blog lists twelve, the GitHub README says "11+" and names fourteen. On top of that symbol-level code graph sits a layer of SDLC metadata: merge requests, pipelines, security findings, ownership. For anyone who thinks the graph is the substrate agents and humans both call into, Orbit is genuinely impressive and genuinely validating.
Now the shape of it. A portal is registered: a human writes the catalog, the tool renders it. Orbit is the opposite motion, GitLab parsing the graph out of what your repositories already contain and handing it to a machine to query. There is no catalog surface. The docs never use the words "catalog" or "scorecard," describe Orbit as "an analytical system designed for point-in-time SDLC insight," and no Orbit source, blog, docs, or README, uses the word "portal" at all. It is the context layer beneath the SDLC, not a front door on top.
Two honest bounds. First, reach: Orbit Remote is GitLab.com (SaaS) only, not self-managed GitLab, on Premium or Ultimate, behind the knowledge_graph feature flag, disabled by default. GitLab moved it from experiment to beta in 19.1, but beta here is not general availability: it is still behind that flag, still off by default, and its own docs still call it "available for testing, but not ready for production use." That is narrower than "GitLab-only."
Second, layer: Orbit's marketing reaches for the words "blast radius," and for symbol-level and merge-request-level questions it delivers on them. But its graph is code symbols plus lifecycle metadata. It does not resolve artifact provenance. It does not know that this base image is built by repo X, that this Terraform module resolves to repo Y, that this Helm value feeds a downstream chart. That is Orbit Remote, the hosted service. Orbit also ships Orbit Local, a single-binary CLI that runs entirely on your machine, needs no GitLab instance or network connection, and parses one local repository into a DuckDB, code only, no SDLC data. Local is an even purer symbol graph, one repo on your laptop with no cross-org reach and no artifact provenance, so both shapes sit below the artifact layer. Symbol graphs and artifact graphs are different categories, and even the 800-pound gorilla is sitting on the symbol layer.
Registered, parsed, and the axis nobody is on
There is a clean way to name the difference between a portal and Orbit, and it is registered versus parsed. It is accurate. It is also a narrowing gap, not the durable one.
Backstage and Port are registered. An entity exists to the tool because a human wrote it down, and it stays true only for as long as humans keep editing it. Orbit is parsed. It reads code and metadata GitLab already holds, so nobody hand-maintains it and it does not drift the way a catalog does. That explains a lot: why the portal goes stale and the graph stays current, why one costs you FTEs and the other costs you infrastructure.
But watch what all three are doing. Backstage is wrapping its registered catalog in MCP for agents. Port is using AI to relate the entities it already holds. Orbit was born parsed. All three are converging on the same destination, the structured graph an agent queries, so if you build your whole argument on registered-versus-parsed you are building it on the one seam every vendor is actively closing. The durable line runs on a different axis. None of the three parses the artifact layer, and no amount of catalog AI changes that, because the artifact layer was never in any of their catalogs to begin with.
Where the breaking edge actually lives
The cross-repo edge that breaks when you bump a base image or a shared module is a boring, declared thing, and it is the one I actually get paged about. A Dockerfile FROM line pinning a downstream service to your base image. A Terraform source block resolving to the module repo. A Helm value pointing at an image, a GitLab CI include, a GitHub Actions uses:, a go.mod require. It was written down, in a manifest, in a repo. Just not the repo you happen to have open. Backstage knows about that edge only if a human typed it into a catalog-info.yaml. Port knows it only if you modelled a blueprint and something populated it. Orbit sees code symbols and SDLC metadata on GitLab.com, which is a different layer. The base-image bump, the module change, the Helm value that feeds a downstream chart are invisible to all three. And it is usually the dependency nobody remembers anyway, the one that lived only in the head of the engineer who left.
That layer is what Riftmap parses. It installs across a whole GitHub or GitLab organisation from one read-only token, with no per-repo YAML to maintain, because Riftmap only ever reads. It reads the edges your manifests declare, deterministically: Dockerfile FROM, Terraform source, Helm value references (the repository under an image: block in values.yaml), GitLab CI include, GitHub Actions uses:, go.mod requires. It resolves each one to the repo on the other side. Riftmap connects GitHub orgs, GitLab orgs, or both in one workspace.
Here is the shape of the edge that sits underneath all three. I scanned the cloudposse organisation on 18 July 2026, 244 repositories in all, and one Terraform module stood out. cloudposse/terraform-null-label is pulled in by 149 of those repos; the next most-consumed module in the org has 15. Every one of those 149 edges was read from a Terraform source attribute in a module block, the string cloudposse/label/null, resolved through HashiCorp's registry naming convention to the repo that actually publishes it, and pinned to a version. 141 of the 149 point at the current release, 0.25.0. The other eight are stuck on older tags, silently, with nothing anywhere recording that they lag.
Riftmap scores that edge at 0.9, not a flat 1.0, because the last hop is a convention, HashiCorp's own terraform-<provider>-<name> rule, rather than the repo sitting literally in the string. I would rather show you the honest 0.9. It is still a deterministic, rule-based resolution, not a guess. And it is a resolved cross-repo module edge: this module lives in that repo, at that version, consumed here. That is exactly the artifact-provenance edge a symbol graph has no node for, and an SDLC metadata layer does not model. It is also not written down in any catalog.
It is not only Terraform. In a scan of nine public GitHub orgs I wrote up earlier, the most load-bearing repository in Grafana's organisation turned out to be a repo of CI workflow definitions, imported by 188 others, an edge Riftmap resolves from a GitHub Actions uses: string with the org and repo written into it. Across those nine orgs, infrastructure ran from roughly a third of the cross-repo coupling in the most code-heavy org to nearly all of it in the most infrastructure-heavy one. None of that is written down in a catalog for a human to browse.
So which do you actually need?
These three are not really competitors. They are three layers, and which one you need depends on the question you are trying to answer. They stack. They do not cancel.
A catalog and a UI for humans: a portal
If what you want is a browsable home for your services, with owners, docs, scorecards, and golden paths, you want a developer portal. Backstage if you want the huge plugin ecosystem and you are willing to run it and write some React. Port if you want a managed product, your own data model, and AI to help keep the catalog connected, and you are willing to pay for it. Both are the right tool for "give humans one place to find and govern services," and I have written up the wider field of Backstage alternatives if you are choosing.
A code-and-SDLC graph for agents in a GitLab shop: Orbit
If your estate lives on GitLab.com and your priority is grounding AI agents in code symbols and merge-request history, Orbit is the strongest thing shipping in that lane, with the caveats stated plainly: GitLab.com only, Premium or Ultimate, feature-flagged, and not production-ready as of this writing. It is the graph, not the front door.
What an infra change breaks across GitHub and GitLab: an artifact graph
If the question that keeps you up before a base-image bump is which repositories break, none of the above answers it, and you want an artifact graph: a graph that parses those manifests and resolves the cross-repo edges to the artifact on the other side. That is the graph Riftmap builds, across a GitHub org, a GitLab org, or both in one workspace, and you can watch it run against a real organisation at riftmap.dev. A portal for humans, a knowledge graph for agents, an artifact graph for blast radius. Different questions, different tools.
The catalog wars are a fight over the UI
The whole "is the portal dead" argument is a fight about the data model and the interface. Registered versus modelled. Human-facing versus agent-facing. A schema you inherit versus one you define. Real stakes, and Backstage, Port, and Orbit are all in it, swinging.
But the question I opened with sits one layer underneath all of it. Which repositories does this change break. It does not live in a catalog, a blueprint, or a symbol graph. It lives in the FROM lines and the source blocks and the include directives your pipelines already run, and only a graph that parses those manifests can answer it. The catalog wars will crown a winner. The artifact layer is a different fight, on a different axis, and so far only one kind of graph has shown up to it.
A few questions, answered directly
Is GitLab Orbit a developer portal? No. Orbit ships no service catalog, no scorecards, and no ownership UI, and none of its own documentation uses the word "portal." It is a knowledge graph of code symbols and SDLC metadata that GitLab parses from your repositories and serves to AI agents over MCP, REST, and the GitLab CLI. A portal is a registered catalog a human maintains. Orbit is the architectural opposite of that.
What is the difference between GitLab Orbit and Backstage? Backstage is a registered catalog: humans author catalog-info.yaml files and Backstage renders and governs them behind a UI. Orbit is a parsed graph: GitLab builds it from your code and lifecycle data with no catalog to maintain, and exposes it for querying rather than browsing. Backstage is a human-facing portal; Orbit is a machine-facing graph. They sit at different layers, and as of mid-2026 Backstage runs anywhere while Orbit Remote is GitLab.com-only (Orbit Local is a code-only CLI for a single local repository).
Can GitLab Orbit replace Backstage or Port? Not really, because they do different jobs. Orbit has no catalog, scorecards, or golden-path UI, so it does not give humans the browsable service directory a portal is for. Backstage and Port do not parse a code-and-SDLC graph for agents the way Orbit does. If you need a portal you still need a portal; Orbit is a graph you would query alongside one, not instead of it.
Do any of these show infrastructure blast radius across repos? No. Backstage, Port, and Orbit do not parse the artifact layer, so none of them resolves which repositories a base-image, Terraform-module, or Helm change will break across your estate. Backstage knows an edge only if a human catalogued it, Port only if you modelled it, and Orbit sees code symbols and SDLC metadata on GitLab.com only. Answering that question needs a tool that parses Dockerfile FROM, Terraform source, GitLab CI include, and GitHub Actions uses: edges and resolves them to the repo on the other side, which is what an artifact graph like Riftmap does.
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.
Top comments (0)