Dora NodaBackstage owns roughly 89% of the internal developer platform market. It also, by most accounts, gets opened by about 10% of the engineers at a typical company that installed it. Spotify, which built and open-sourced the thing, reports internal adoption closer to 99%. Those three numbers aren't in tension — they're describing three different questions — but stacked next to each other they explain something most "which IDP should we adopt" posts skip entirely: winning the category and winning the developer's actual attention are different fights, and Backstage has only won one of them.
What "89% market share" is actually measuring
The 89% figure — cited across 2026 platform-engineering coverage, including byteiota's breakdown and GetDX's newsletter — is a share-of-choice number. Among companies that have already decided to run an internal developer platform, 89% of them picked Backstage over Port, Cortex, Humanitec, or a homegrown option. It's not a claim about how many developers at those companies use it day to day. Those are separate surveys with separate denominators, and conflating them is exactly the mistake a "market leader" headline invites.
The underlying scale is real, not a rounding trick. Backstage counts more than 3,400 organizations and upwards of 2 million developers outside Spotify itself, per CNCF's project page, with 270+ public adopters listed by name — LinkedIn, Vodafone, CVS Health, REI, Siemens, and Lego among them. It joined the CNCF Sandbox in September 2020 and graduated to Incubating status in March 2022, and in March 2026 shipped its "New Frontend System" as the default after a multi-year migration — the kind of maturity signal that gets a platform past a risk-averse enterprise's procurement review. None of that is disputed. What's disputed is what happens after procurement signs off.
The Day 2 problem: standing it up vs. keeping it open
Spotify's internal Backstage adoption sits around 99% — nearly every engineer at the company that invented it opens it regularly, because Spotify has spent years wiring in the plugins, golden paths, and data sources that make it the fastest way to get anything done. Outside Spotify, multiple 2026 surveys put average adoption closer to 10% of eligible engineers. Roadie calls this the "Day 2 problem": standing up a Backstage instance — installing it, wiring the software catalog, connecting a CI system — is the easy, well-documented part. Getting an engineer to open it a second time, a month later, once the initial rollout enthusiasm fades, is where most deployments quietly stall.
The mechanism is simple and not specific to Backstage: adoption only happens when developers get value they can't get faster somewhere else. If the portal just mirrors information already sitting in GitHub, Slack, or a wiki page, a developer has no reason to add a fourth tab to their routine. Backstage's own docs on adoption strategies concede the point — a catalog with no plugins wired to real workflows is a directory, not a platform.
The plugin-upgrade tax, with receipts
The gap between "we deployed it" and "people use it" would be a normal maturity curve if it closed over time. What keeps it open, according to the same 2026 adopter surveys, is a specific, recurring cost: 56% of Backstage adopters cite upgrades as their single biggest pain point. Not onboarding. Not documentation. Upgrades.
The mechanism is architectural, not incidental. Backstage plugins are built against a plugin API that has historically shipped breaking changes between versions — meaning a Backstage version bump doesn't just update the core app, it can force a rewrite across every custom plugin a platform team has layered on top. Roadie documents a real case where one client's platform team spent six weeks on a single major-version upgrade — worth treating as one illustrative war story sitting alongside the 56% aggregate figure, not as the evidence itself, but the shape of the anecdote matches what the survey number implies: the tax scales with how much a team has actually built on the platform, so the teams furthest along in adoption pay the steepest upgrade bill.
There's a second, quieter cost underneath the first. Backstage's plugin system is a React framework — createPlugin, a component-based frontend, its own build tooling. The people who actually operate a platform team day to day write Terraform, Go, Python, and Kubernetes manifests, not React. Gartner's own platform-engineering research flags this mismatch: the skill a plugin author needs (frontend engineering) isn't the skill the platform team was hired for (infrastructure engineering). So the upgrade tax doesn't just cost calendar time — it costs a context switch into a skill set the team that's paying the bill doesn't otherwise use.
The strongest counter-argument: is this fixable, or architectural?
It would be a strawman to treat the upgrade tax as a simple bug Backstage will eventually patch away, so it's worth engaging the sharpest version of the opposing case directly. In May 2026, Port.io published "Backstage Is Dead", arguing the market didn't outgrow Backstage's idea — it outgrew its architecture. The piece's core claim: Backstage puts a UI at the center of the platform, with plugins as React components bolted onto it, while what platform teams actually need in an AI-agentic era is a context lake at the center — a flexible data model and relationship graph that both humans and agents can query, with the UI as one thin, replaceable consumer of that data rather than the thing the whole system is organized around. Port's framing of the adoption numbers is blunter than the surveys above: Spotify's internal number, they note, and the external ~10% average aren't two points on the same maturity curve — they're evidence the two populations are using fundamentally different things.
That's a real architectural argument, not just a competitor's sales pitch, and it deserves a real answer rather than dismissal. The honest read: Port is correct that a UI-centric plugin architecture makes upgrades structurally expensive in a way a data-model-centric one wouldn't — that's the same mechanism the 56%-upgrade-pain stat is measuring, just traced to its root cause instead of its symptom. Where the "dead" framing overreaches is treating that as reason to abandon a software catalog and golden-path model entirely; the underlying problem — a plugin ecosystem is only as maintainable as the API contract underneath it — applies to any tool that lets a platform team keep extending it, agentic or not. The fix isn't "no UI," it's "don't build your core deploy workflow's dependency graph on top of someone else's plugin API in the first place."
What this means for a platform's own golden-path bet
That's the concrete lesson for a self-hosted PaaS deciding how to offer its own golden path. A tool like Backstage is a fine catalog and portal layer — a place a developer looks up what's running and who owns it — and an earlier post on building a Bex golden path in Backstage walked through exactly that: a real Backstage Software Template, wired to bex's own deploy API, that turns "New Component" into a live URL with no wiki page in between. But the deploy backend underneath that template should never be a Backstage plugin, because a plugin is exactly the artifact this post's numbers say gets expensive to maintain: a piece of code whose contract with the host application can change out from under you on the host's release schedule, not yours.
A git-push PaaS's actual golden path — clone a repo, bex.yml declares the service, push, get a running HTTPS endpoint — has no plugin marketplace sitting between the developer and the deploy. There's one opinionated path, and the platform team maintaining it is upgrading their own code on their own schedule, not refactoring against a breaking change that shipped in someone else's frontend framework. That's not an argument against running Backstage as a catalog on top — it's an argument for keeping the thing that actually deploys code a layer down from any tool whose plugin API you don't control.
For a platform team deciding where to draw that line today, three concrete questions do most of the work: does the feature need to live in the catalog UI at all, or does it just need an API a catalog can call — because the latter never has to survive a plugin-API breaking change? If it does need a UI, can it ship as a thin iframe or static widget against a stable endpoint, rather than a createPlugin-registered React component coupled to the host app's internal version? And who on the team actually owns the upgrade when it eventually breaks — a platform engineer who already writes Go and Terraform, or a frontend specialist hired to maintain someone else's plugin contract? A "no" to that last question is usually the tell that a golden path is quietly renting complexity it doesn't need to own.
The 89%-vs-10% gap isn't really a Backstage problem. It's what happens whenever "the market standard" and "the tool a developer will actually reopen tomorrow" turn out to be two different things to build for.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources:
- Backstage Hits 89% IDP Market Share: What It Means.
- Backstage and the Developer Portal Market — GetDX.
- Backstage — CNCF Project Page.
- Backstage Adoption: The Day 2 Problem — Roadie.io.
- Strategies for Adopting — Backstage Docs.
- Self-Hosting Backstage: The Real To-Do List — Roadie.io.
- Backstage Is Dead. The Platform Engineering World Moved On — Port.io.
