Backstage won the developer portal war and most teams running it still failed. Spotify's open-source framework, now a CNCF project, holds about 89% of the IDP market, runs at more than 3,400 organizations, and serves over two million developers outside Spotify. That is a decisive victory by any market-share metric. Then you find the number nobody puts on a keynote slide: the average internal adoption rate of a self-hosted Backstage instance sits around 10%. Most teams stand up a portal, demo it to leadership, and watch it quietly fail to become the thing engineers open every morning.

So the slogan making the rounds in platform circles this year, "DIY is dead," is aimed at the exact tool that dominates the category. That sounds like a contradiction. It isn't. It's a math problem about where a small platform team's hours actually go.

The 89% that doesn't mean what you think

Framework market share and developer adoption are two different scoreboards, and Backstage is winning one while losing the other. Winning the framework war means a lot of organizations chose Backstage as the thing to build on. It says nothing about whether developers inside those organizations use the resulting portal.

The honest read of the data is grim: teams "burn out on maintenance before delivering features developers actually want," and 56% of Backstage adopters name upgrades as their single biggest pain point. Not catalog design, not plugin gaps. Upgrades. The treadmill of keeping a fast-moving framework current is the thing that eats the year.

I've watched this pattern up close on infra teams that had every reason to succeed. The portal goes live, gets a round of applause, and then the catalog data goes stale because nobody owns the integrations, the scorecards never get wired to real ownership data, and three months later the platform engineers are spending their sprints chasing a plugin that broke on the latest bump. The portal became the project instead of the platform. That is the failure mode "DIY is dead" is actually pointing at. Not that Backstage is bad software. That the operational tax quietly eats the value you were trying to create.

The free option is the expensive one

This is the part that should make a VP of Engineering uncomfortable. The Backstage software costs nothing. Running it in production does not.

Credible 2026 estimates put a production-grade self-hosted Backstage at three to five full-time engineers for up to 18 months. Total cost of ownership for a 100-engineer org lands somewhere between $375,000 and $750,000 per year once you count the maintenance team, infrastructure, and opportunity cost. Independent comparisons put self-hosting at four to ten times the cost of commercial alternatives once you actually price the engineering time.

Read that back as a security and reliability problem, because that's what it is. A two- or three-person platform team burning its capacity on Backstage upgrades is a team not building golden paths, not closing the compliance scorecards that justified the platform budget, and not wiring the catalog to the ownership data your incident response actually needs at 3 a.m. The license is free. The engineers are the most expensive line item you have, and self-hosting spends them on plumbing.

Port and Cortex are a different bet, not a managed Backstage

The biggest mistake I see in evaluations is treating every option as a flavor of the same thing. Port and Cortex are not "Backstage but hosted for you." They threw out the framework.

Both are proprietary, SaaS-only, and cannot be self-hosted. They abandon the Backstage plugin model entirely in favor of an opinionated, low-code catalog and scorecard engine. Port cannot run on your own infrastructure at all; a 50-engineer team runs roughly $18,000 per year before you reach the enterprise tier. Cortex doesn't publish pricing, but a 2024 Forrester TEI pegged it near $65 per user per month at scale.

What you buy with that is time-to-value measured in days instead of quarters. What you give up is extensibility and, critically, data residency. With Port or Cortex you are handing a third party your full engineering metadata graph: every service, every owner, every dependency, every scorecard result. For a lot of shops that's a fine trade. For some it's a non-starter, and I'll come back to why.

The managed middle, for teams that genuinely need plugins

There's a hedge between "run it yourself" and "throw out the framework." Roadie (around $22 to $24 per developer per month) and Spotify's own Portal, marketed as "Backstage in a box," keep the Backstage ecosystem and full plugin compatibility while outsourcing the upgrade pain to someone else.

This is the option most "we evaluated Backstage and it hurt" teams should have started with. If you have a real, specific need for Backstage plugins (a custom TechDocs flow, an internal plugin your team already wrote, an ecosystem integration that only exists in that world) but you do not want to staff a portal SRE rotation, managed Backstage is the answer that keeps the ecosystem and kills the treadmill. You pay per developer instead of paying in headcount.

The tiebreaker is regulation, not preference

Here is where the clean "just buy the SaaS portal" advice breaks, and it's the part security-conscious readers should weigh heaviest.

For defense contractors and heavily regulated entities, SaaS-only options can be disqualifying on their face. Port and Cortex require trusting a third party with your complete engineering metadata graph, and "we sent our entire service catalog and ownership map to a vendor's cloud" is not a sentence that survives a serious audit in a regulated environment. That single constraint pushes those organizations back toward self-hosted or managed Backstage regardless of cost.

So data residency is the real tiebreaker, and it overrides the economics. If you're air-gapped or under strict residency rules, the cheaper SaaS portal isn't actually on the menu, no matter how good its time-to-value looks on a slide. That's why "just buy Cortex" is not universal advice, and anyone giving it without asking about your compliance posture hasn't done the work.

The counterpoint: sometimes self-hosting earns its keep

It would be easy to read all of this as "never self-host," and that's wrong. There's an honest threshold, and it's a function of two things: team size and plugin need.

Below roughly 200 engineers, with no exotic plugin requirements and no data-residency mandate, the maintenance burden of self-hosted Backstage rarely pencils out against a SaaS portal. Above 200, or with strict residency rules, or a genuine need for custom Backstage plugins, self-hosted or managed Backstage starts to earn its keep. At that scale you have the headcount to absorb the upgrade treadmill, and the per-developer SaaS pricing starts adding up to real money. The build-vs-buy line is not religious. It's a size-and-constraints line, and it moves as you grow.

How to make the call this quarter

Run your situation through these in order. The first one that fits is your answer.

  1. Price the engineers before you price the license. Write down how many FTEs you'll dedicate to self-hosted Backstage for the next 18 months (plan for three to five for anything polished) and, more importantly, what those people won't build instead: golden paths, compliance scorecards, catalog ownership wiring. If that opportunity cost scares you, stop here. You've found your answer, and it isn't self-hosting.
  1. Under ~200 engineers, no custom-plugin need, no residency mandate? Buy the SaaS portal. Port (roughly $18,000/year at 50 engineers) or Cortex (around $65/user/month at scale) gets you working scorecards and a populated catalog in weeks. At a three-person platform team, time-to-value beats ideological purity every time.
  1. Need the Backstage ecosystem but not the ops? Take the managed middle. Roadie (about $22 to $24/developer/month) or Spotify Portal keeps plugin compatibility and removes the upgrade pain that 56% of adopters call their worst problem. This is the pragmatic default, not the exotic choice.
  1. Regulated or air-gapped? Self-hosted or managed Backstage is likely your only door. Treat the staffing cost as a compliance cost, and budget the upgrade treadmill explicitly up front. Discovering it in month nine, when your two platform engineers are underwater, is how the project dies.
  1. Whatever you pick, make adoption the metric you report. Not "we shipped a portal." Actual usage. A catalog sitting at 10% adoption is a failed project no matter how elegant it looks in a demo. The interface is the easy part. The platform behind it is the substance, and that's where your two or three engineers should spend their year.

The decision was never really about open source versus proprietary. It's about whether your scarcest resource, a tiny platform team, spends the next 18 months maintaining a portal or building the thing the portal is supposed to be a window into.

Sources

  • https://roadie.io/blog/platform-engineering-in-2026-why-diy-is-dead/
  • https://byteiota.com/backstage-hits-89-idp-market-share-what-it-means/
  • https://tasrieit.com/blog/port-vs-backstage-vs-cortex-developer-portal-comparison-2026
  • https://newsletter.getdx.com/p/backstage-and-the-developer-portal-market