Every "Backstage alternatives" roundup lists the same five portals. None of them asks the question that decides which alternative is right: what job sent you looking in the first place?
A senior platform engineer at a Nordic consultancy summarised his Backstage evaluation to me in one sentence: the cost of setting it up and keeping it maintained was bigger than what they got back. He is not an outlier. I have heard the same verdict, in nearly the same words, from engineers across r/devops threads, client engagements, and direct conversations. The team evaluates Backstage seriously, sometimes runs a proof of concept, and walks away. Then they type "Backstage alternatives" into a search box, and the search results take over.
Go read those results. As of mid-2026, every page that ranks is a vendor roundup, and every roundup follows the same script. Port lists alternatives and Port is the best one. Cortex lists alternatives and Cortex is the most comprehensive. OpsLevel lists alternatives and OpsLevel is the fully managed answer. The supporting cast rotates between Roadie, Mia-Platform, Configure8, Rely.io, and Atlassian Compass, but the structure never changes. Backstage is hard, here are five portals that are easier, ours is first.
Here is the thing none of those pages will tell you, because their business depends on not telling you. "Backstage alternatives" is not one search. It is at least three different searches wearing the same query, and the right alternative depends entirely on which one is yours. Two of the three are well served by the portal vendors in those roundups. The third is not served by any of them, because the portals inherit the exact property that made you walk away from Backstage.
This post is the triage the roundups skip. I will be fair to every tool in it, including Backstage, because the engineers reading this can smell a strawman from the next time zone. And I will be upfront that I build a tool that fits exactly one of the three jobs, and explicitly does not fit the other two.
What Backstage actually is, honestly
Backstage is an open-source framework for building internal developer portals, created at Spotify and open-sourced in March 2020. It remains a CNCF Incubating project with one of the largest contributor communities in the foundation. It pioneered the developer-portal category, and most of the commercial portals in those roundups exist because Backstage proved the demand first.
The origin story matters more than people give it credit for. Backstage began as an internal Spotify project called System Z, built so that engineers in a fast-growing organisation could understand ownership, dependencies, and versions across an exploding service landscape. Hold onto that word "dependencies". It comes back later.
The criticisms are equally well established, and I will not pretend they are mine. Backstage is a framework, not a product. You clone it, stand up a PostgreSQL database, configure authentication, and start writing or installing plugins, most of which are community-maintained without vendor support. The estimates for what this costs are public and not in dispute. The community site internaldeveloperplatform.org puts the true cost of ownership at around $150,000 per 20 developers, a figure that Port and OpsLevel both cite in their own marketing. Cortex's roundup says most organisations need two or three full-time engineers for six months or more just to stand up a basic service catalog. Other practitioners put production-readiness at six to twelve months. Gartner has noted that organisations mistakenly believe Backstage is a ready-to-use portal, and that the rude awakening during implementation leads to projects being put on hold or abandoned.
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.
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.
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.
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)