Backstage is dead

Backstage shaped how the industry thinks about internal developer portals. It pioneered the category, gave platform engineers a vocabulary, and proved that centralizing the developer experience wasn't just a nice idea, it was a survival strategy for scaling orgs.

But Backstage is dead. Not because it was bad. But because the world moved on.

Respect

Backstage did three things nobody else pulled off in 2020.

It's flexible. You could mold it into whatever portal you wanted. Software catalog, scaffolder, TechDocs, custom plugins., Tthe building blocks were there, and you decided what to build. For platform teams that wanted full control, nothing else came close.

It carries Spotify's name. When a company running one of the most sophisticated microservices architectures on the planet says "this is what we built to tame our own complexity," people listened. When the message comes from a practitioner and not a vendor selling a vision, engineers listen even more. It built a real community. The CNCF incubation, 270+ adopters, 230+ plugins, thousands of contributors. Platform engineering went from a niche discipline to a Gartner-recognized category, and Backstage was at the center of that conversation.

None of what I'm about to say erases it.

What made it painful

Here's what actually happened when teams tried to run Backstage in production.

You need to be a React developer.

Backstage is a React framework. But platform engineers write Terraform, Go, Python, Kubernetes manifests. Gartner flagged this explicitly, correctly stating that platform engineering leaders are backend people, and asking them to maintain a React frontend with abstractions like createPlugin, createRoutableExtension, and the @backstage/core-plugin-api package was a different job entirely.

One r/DevOps user nailed it: "The idea of backstage is super cool, but for me, as a DevOps engineer, the fact that I need to write a lot of React code instead of GitHub workflows and Terraform files made me leave the project." (source)

You can’t bring your own data model.

Backstage ships five entity kinds: Component, API, System, Resource, Domain. If your org models data pipelines, ML models, feature flags, or infrastructure tenants, you're either jamming them into Component with custom annotations or forking catalog internals to add a new kind, and maintaining that fork across every upgrade.

DevOps.com found that tuning the data model is so hard that "many adopters abandon hope and work with the default data model." (source) That's not a minor UX complaint. If your catalog doesn't reflect reality, nobody trusts it, and if nobody trusts it, nobody opens it.

Plugin data stayed siloed. 

This one's technical but it's the root of a lot of the frustration. Each Backstage plugin runs its own frontend and backend context with its own API clients and its own database tables. The Kubernetes plugin queries your clusters. The CI/CD plugin pulls from Jenkins. The PagerDuty plugin calls PagerDuty. None of it flows into a shared data layer.

So you can't ask "which services owned by my team had incidents last week that correlated with deployments?", because the incident data, the deployment data, and the ownership data live in three separate plugin boundaries with no schema connecting them.

The cost was brutal. 

6-12 months to stand up a usable instance. Two to five full-time engineers for years, per Gartner. True cost of ownership around $150K per 20 developers.

Another r/DevOps member: "At scale, Backstage is not an 'other duties as assigned' sort of tool to own. It will require dedicated resources as it grows. That's usually the biggest thing people overlook." (source)

And adoption reflected all of it. 

A ShiftMag case study: "Despite zero TypeScript and MERN experience we pulled off deploying Backstage in our platform, with much better user experience. Only 5% of our engineers use it." (source) Spotify reported 99% internal adoption. Their own VP of Engineering acknowledged external orgs average around 10%.

AI changed what you should expect from an IDP

OK, so Backstage is painful to get up and running (and adopted). 

But pain alone doesn't kill technology. 

What kills it is when the world changes and the pain no longer buys you anything useful.

That's what happened once AI was introduced to our life.

In 2020, building a portal UI was genuinely hard. Backstage gave you a head start on the UI. 

In 2026, AI builds that UI in minutes (you don’t need Backstage for it).

It’s not about AI making Backstage easier. It makes Backstage unnecessary. 

The UI isn't where the value is anymore.

Think about where engineering is going. 

We're moving from manual to autonomous engineering. 

Coding assistants were the first wave. What's already here is agents that pick up Jira tickets, find the relevant repo in your catalog, pull recent commits, generate a fix, open a PR, and request review from the service owner, end to end.

But here's what nobody talks about: the agent itself is a tiny piece of the system. The real infrastructure is everything around it.

Agents need a context lake, structured, real-time data about your engineering org served through a single endpoint, because an agent running on a stale .cursorrules file doesn't know that service ownership transferred to a different team last Tuesday. They need to have access only to the data they are allowed. Not only for security and compliance reasons, you also want to minimize their context window to avoid hallucinations.

Engineering needs an agent registry, because when three teams independently build triage agents wired to different tools with different permissions, you don't have agentic engineering, you have agent sprawl. 

Agents need guardrails and human-in-the-loop checkpoints that are defined centrally, not hard-coded as if-statements in each agent's repo. 

Agents need governance, scoped credentials, audit trails, cost controls, because an agent stuck in a retry loop will burn tokens for hours until someone manually kills it or the monthly invoice lands. 

Agents and Humans need orchestration, because most real workflows are a mix of agents, tools, and people. Coordinating these moving parts require both deterministic and non-determentistic workflows.

None of that is the agent. All of it is the platform underneath the agent. The infrastructure.

That's what makes the IDP more important than ever. 

It becomes the system of record and system of action for the whole engineering org, the layer that gives agents context, enforces policy, sets controls, and keeps humans in control.

But isn't Backstage responding?

Yes. And what they're shipping is smart.

v1.40 brought the Actions Registry, plugins can register typed, schema-validated actions with permission enforcement. @backstage/plugin-mcp-actions-backend exposes those as MCP tools, so agents in Cursor or Claude can discover and invoke them. The New Frontend System went "adoption-ready" in late 2025. A new design system is replacing Material UI. At KubeCon Atlanta, the maintainers titled their talk "AI-Native Backstage."

They clearly see where things are heading. So what's the problem?

Every one of these improvements sits on the same foundation: React frontend, plugin-based backend, YAML entities in a relational database. The Actions Registry exposes discrete operations, "register a component," "trigger a scaffolder template." An agent can call catalog:register-component, but it still can't reason about your dependency graph, your production-readiness posture, or your org's standards. It runs commands. It doesn't understand context.

The MCP integration is "highly experimental" as of early 2026. The initial auth model used static tokens, no per-user identity. v1.43's Dynamic Client Registration is still maturing.

But the real issue isn't maturity. It's architecture.

In Backstage, the UI sits at the center and everything else serves it. An agentic engineering platform puts the context lake at the center, flexible data model, relationship graph, policy enforcement, a human-to-agent collaboration experience, a skills and tools catalog, with the UI as one consumer alongside agent-native interfaces. Getting from one architecture to the other isn't a version bump. It means decoupling the catalog from the rendering layer, building a real-time API, implementing MCP at the context level (not just action level), and treating agent identity as a first-class citizen.

That's a re-architecture. Not a feature release. Backstage is adding the right capabilities at the edges. The center hasn't moved.

What should Backstage do to stay relevant?

Three things.

Stop being a React framework. The world doesn't need another way to render a service catalog page. AI builds UI faster than any plugin ecosystem can.

Rebuild the catalog as a context lake. The entity model and metadata graph are Backstage's most valuable asset. Expose them through a real-time API that agents and humans both consume, with guardrails and audit trails built in. Make MCP a first-class interface, not an experimental plugin.

Evolve from portal to platform. The category has moved. What started as internal developer portals is becoming agentic engineering platforms, systems that orchestrate the entire SDLC, power autonomous ticket resolution and self-healing incidents, surface engineering intelligence, and support human-to-agent collaboration natively. Backstage serves humans through a UI. The next generation serves agents and humans through a shared infrastructure layer.

This isn't a roadmap item. It's a reinvention. And the window is closing.

The platform engineering market didn't outgrow the idea of Backstage. It outgrew the architecture.

What Backstage pioneered, a single pane of glass for your engineering org, matters more now than it did in 2020. But the pane of glass needs to face two directions: toward the humans who make decisions, and toward the agents that execute them.

Backstage earned its place in the history of platform engineering. Whether it earns a place in its future depends on what it's willing to let go of.