So far, the roundups and I agree. Backstage is genuinely expensive to run. Where we part ways is on what that means. The roundup logic is: Backstage is expensive, therefore buy a cheaper portal. The actual logic should be: Backstage is expensive, therefore figure out which part of it you wanted, because you might be able to buy just that part, and for one specific part, no portal sells it.
The three searches hiding inside one query
When a team types "Backstage alternatives", they arrived there from one of three places. The triage question is which one.
Job one: you want what a portal does
Some teams want the portal itself. Golden-path templates for scaffolding new services. Scorecards that track whether services have runbooks, SLOs, and passing security scans. A single pane of glass for ownership, on-call, and documentation. Self-service actions that let a developer spin up an environment without filing a ticket.
If this is your job, the roundups are right and I have nothing contrarian to offer. The commercial portals are real products built by serious teams, and the honest comparison between them comes down to taste and scale. Port gives you a flexible data model you configure visually rather than in code, which suits organisations whose workflows do not fit standard patterns. Cortex leans hardest into scorecards and engineering standards, which suits organisations whose pain is "we have 400 services and no idea which ones meet our bar". OpsLevel is deliberately opinionated, which suits teams that want the vendor to have made the workflow decisions already. All three will get you to a working portal in weeks instead of quarters, and all three cost real money at scale, which is the trade you are making.
What I want you to notice is what these products have in common with Backstage underneath the better onboarding. They are all catalog-model systems. Each one maintains a registry of entities, services, teams, resources, and the relationships between them, and that registry is populated by some mix of integrations and humans declaring things. That is the right architecture for the portal job. Ownership is something a human decides. A runbook link is something a human writes down. Scorecards evaluate criteria a human defined. The catalog model fits because the data genuinely originates with people.
Job two: you want Backstage itself, without operating it
Some teams evaluated Backstage and concluded the product was right but the operational burden was not. They want the open-source ecosystem, the plugin library, the CNCF governance, and they want someone else to run it.
This path matured significantly in the last year. Spotify Portal for Backstage went GA in October 2025 as a fully managed, no-code SaaS version of Backstage operated by Spotify itself, with setup wizards in place of the configuration work that used to consume the first quarter. Roadie has offered managed Backstage for years and remains the established independent option, handling hosting, upgrades, and the GitHub rate-limit problems that bite self-hosters.
If your evaluation said yes to Backstage's model and no to its operations, this is your category, and it is a perfectly defensible choice. You keep the ecosystem and shed the toil. I have no quarrel with it.
But notice, again, what does not change. Managed Backstage is still Backstage. The Software Catalog is still populated by catalog-info.yaml files in your repos, and the relationships in it, including the dependsOn entries, are still whatever a human last wrote there. Spotify operating the infrastructure does not update your YAML when an engineer changes a Terraform module source. The hosting was never the part that went stale.
Job three: you wanted to see what depends on what
Now the third search, the one I keep meeting in the wild.
A meaningful fraction of teams never wanted golden paths or scorecards. They reached for Backstage because of the dependency graph. They wanted the answer to "what breaks if I change this", or "which repos consume this base image", or "the engineer who understood how these sixty repos fit together is leaving in three weeks". They saw the Software Catalog's dependency view, recognised the thing they were missing, and adopted a developer portal to get it. That is not a misreading of Backstage. It is the original System Z brief: ownership, dependencies, versions. It is also the kind of question a parsed graph answers concretely rather than in the abstract: when I scanned all 208 kubernetes-sigs repos, 153 of them turned out to import a single shared module — the sort of fan-in a stale catalog never shows you.
For this job, the catalog model is not the solution with some maintenance cost attached. The maintenance cost is the failure mode. I wrote about this pattern at length in the catalog maintenance trap, but the short version goes like this. A dependency entry in catalog-info.yaml is a second declaration of a fact your repos already declare. The first declaration is the Terraform source block, the Dockerfile FROM line, the go.mod require, the .gitlab-ci.yml include, the Helm Chart.yaml dependency. Engineers must edit those files to ship. Nothing forces them to edit the catalog YAML to match, so within weeks the two declarations diverge, and the graph in the portal becomes documentation that was supposed to be authoritative. Which is worse than no graph, because people make blast-radius decisions on the assumption it is current.
Here is the part the roundups structurally cannot say. Switching portal vendors does not escape this. Port's marketing makes the point against its rivals better than I could: it criticises YAML-based catalogs for creating developer overhead and not updating in real time from the source of truth, eroding trust and adoption. That criticism is correct, and it applies to the entire category whenever the data in question is the dependency graph, because dependencies are facts about source files, and source files change with every commit. A portal can ingest from integrations, and the good ones do for cloud resources and Kubernetes objects. But the cross-repo dependency edges your infrastructure actually runs on, module sources, image references, CI includes, chart dependencies, live in manifests that no portal in those roundups parses.
So if job three is your job, the honest answer to "what is the best Backstage alternative" is: not a portal. Any portal. The alternative is a different architecture entirely, one where the graph is parsed from the declarations that already exist instead of modelled from declarations you ask humans to add. I went deep on that architectural distinction in modeled graphs and parsed graphs; the one-line version is that a parsed graph cannot go stale relative to the source, because the source is the input.
The triage, in one table
| Why you wanted Backstage |
Right category |
Representative options |
| Golden paths, scaffolding, scorecards, ownership, self-service |
Commercial developer portal |
Port, Cortex, OpsLevel |
| Backstage's model and ecosystem, minus the operations |
Managed Backstage |
Spotify Portal, Roadie |
| Dependency visibility and blast radius across repos |
Parsed dependency graph |
Riftmap, or build your own parser |
| Keeping third-party dependencies up to date |
Automated update tooling |
Renovate, Dependabot |
| Code search and symbol navigation across repos |
Code intelligence |
Sourcegraph |
I added the last two rows because they are the other jobs I see mislabelled as portal problems. Renovate and Dependabot keep versions current but tell you nothing about who consumes what. Sourcegraph's symbol graph is genuinely excellent at code-level navigation and stops at the infrastructure boundary, a distinction I unpacked in symbol graphs and artifact graphs. Neither is a Backstage alternative, but both get evaluated as one, which tells you how muddled this category's vocabulary is. The muddle gained its biggest entrant in June, when GitLab shipped Orbit, a group-wide symbol-and-SDLC graph. I read everything GitLab Orbit actually shipped, and it stops at the same infrastructure boundary as Sourcegraph: no HCL, no Dockerfiles, no artifact edges.
And a row I deliberately left out: "build your own portal from scratch". Teams do it. Canva did, then migrated off it, and the engineer who ran that migration described the homegrown portal as something they got value from while using it, not wasted work. That is the right way to think about sunk platform investment generally, including a Backstage proof of concept that taught you which job you actually have.
Where Backstage genuinely wins
I want to be precise about when the answer to "Backstage alternatives" is "none, use Backstage", because that answer is real.
If you have a platform team with frontend capacity, a genuine need to own and extend the portal, and an organisation large enough that the per-developer cost of the framework amortises, Backstage is a defensible choice that thousands of organisations have made work. The plugin ecosystem is unmatched. The CNCF governance means it will outlive any single vendor's funding cycle. And the things humans should declare on purpose, ownership, on-call, runbooks, tech docs, are things Backstage handles well precisely because the catalog model fits them.
The mistake is not adopting Backstage. The mistake is adopting any catalog-model system, Backstage or its commercial successors, for the dependency graph, and then spending organisational willpower trying to keep humans updating a second declaration of facts the repos already state. That spend is the maintenance cost everyone complains about, and it does not buy accuracy. It buys a graph that is accurate to within whenever someone last cared.
The question underneath the query
The roundups argue about which portal. After two years of conversations with teams who walked away from Backstage, I think the better argument is about which job. The portal jobs are well served, by the portals and by managed Backstage, and the vendors fighting over that SERP have earned their places in it. The dependency-visibility job is the one that query quietly smuggles in, and it is the one place where every option in every roundup shares Backstage's actual weakness rather than fixing it.
If the sentence that sent you searching was some version of "we wanted to know what breaks when we change things, and the catalog could not keep up", then you were never shopping for a portal. You were shopping for a graph, and the graph already exists, written across your Terraform sources, Dockerfiles, CI includes, chart dependencies, and module files. The work is parsing it, not re-declaring it.
That parsing is what I build. Riftmap connects to a GitLab or GitHub org with a read-only token, parses the dependency declarations across twelve ecosystems, Terraform, Docker, Helm, Kubernetes, CI templates, Go, npm, Python, Ansible, and more, and serves the resulting graph two ways: a blast-radius UI for engineers, and a JSON API for coding agents that need cross-repo context at planning time. There is no catalog to maintain because there is no catalog. If your job is one of the other two, use the table above with my blessing; Riftmap is not a portal and will not become one. If your job is the third one, the free tier covers 15 repos and the first scan takes about ninety seconds, which is less time than reading one more roundup.
FAQ
What is the best alternative to Backstage?
It depends on which job sent you looking. If you want golden paths, scaffolding, scorecards, and self-service, a commercial developer portal like Port, Cortex, or OpsLevel is the right category. If you want Backstage's model and plugin ecosystem without operating it, managed Backstage — Spotify Portal or Roadie — fits. If you wanted dependency visibility and blast radius across repos, no portal solves that well, because the dependency graph is a fact about source files; a parsed dependency graph like Riftmap reads it from the manifests instead of asking humans to re-declare it.
Why do teams abandon Backstage?
The most common reason is that the cost of standing it up and keeping it maintained exceeds the value returned. Backstage is a framework, not a finished product: the community site internaldeveloperplatform.org estimates a total cost of ownership around 150,000ドル per 20 developers, and roundups note most organisations need two to three full-time engineers for six months or more just to stand up a basic service catalog. The dependency graph in particular goes stale, because catalog YAML is a second declaration of facts the repos already state, and nothing forces engineers to keep it in sync.
Is Backstage still worth using in 2026?
Yes, for the right team. If you have a platform team with frontend capacity, a genuine need to own and extend the portal, and an organisation large enough that the per-developer cost amortises, Backstage is a defensible choice with an unmatched plugin ecosystem and CNCF governance. The mistake is not adopting Backstage — it is adopting any catalog-model system, Backstage or its commercial successors, as the dependency graph, and then spending organisational willpower keeping humans updating facts the repos already declare. The deep-dive on this question, with Spotify's own external-adoption figure of around 10% and a diagnostic for predicting your own outcome before you commit, is in is Backstage worth it?.