The State of Backstage in 2026 - Ben Lambert & Patrik Oldsberg, Spotify

In this talk, the speakers provide an update on the Backstage project, highlighting developments since the last CubeCon. They discuss significant growth metrics, including over 4,000 adopters and 255 open source plugins, indicating the extensibility of Backstage. The presentation covers new features in the front-end system, such as improved plugin isolation, built-in support for permissions and feature flags, and the upcoming stability of the front-end system at version 1.0. They also delve into enhancements in the authentication process for the CLI, introducing dynamic client registration and refresh tokens. Additionally, the discussion touches on the action registry for plugins, the evolving software catalog, and future plans to enhance AI integration and improve the release process.

Thank you for coming to see our talk today, the state of backstage in 2026, which is our maintain the track talk at CubeCon EU. Uh we were last here in Amsterdam three years ago uh when we first introduced the new backend system and there's a lot happened since then. Uh we'd like to share today with you what we've been working on since CubeCon in Atlanta last year.

So first off, some introductions. You might have seen us before. My name is Ben. I am a senior engineer at Spotify and a maintainer of Backstage. And I have with me, >> hello Patrick go by ragvip on GitHub and also those things. >> Cool. Um first off an agenda. Uh fallen over. Uh as always we're going to start off with some project updates. So some numbers to

see how the relevant areas are ticking along. Uh as well as some highlights uh that we'd like to share with you. And then we're going to switch gears a little bit uh and talk about some exciting new updates with the front end system. Um, then we there's some fun things in the CLI uh with regards to authentication and new integrations that we've been working on and we're

going to dive into those. And of course, we're going to talk about back uh AI uh and what that means for backstage and how we think backstage is now more important than ever. And then finally, there's a road map slide uh just telling you what's next for you all and what's next for us, I guess. All right, so first off, some project updates. What has been happening

around the project? So, let's start off with some numbers, some general product numbers. Uh we're up to over four. Oh wow, 4,000 adopters. Uh, which is great to see. Uh, the project continue to grow. We have now over 255 open source plugins across the ecosystem, which is really highlighting the extensibility of Backstage and the plug-in model and the strength of it. Uh, and of course the most

important number, GitHub stars. We're up to 32.9,000 of those. Nearly 33,000. If everybody that's not start it can start it, we maybe get it over to 33,000 by the end of this talk. Maybe not. Uh um and now a quick look at the community plugins repository. Uh if you're not familiar with this uh this is where all the community maintained plugins live. So previously the backstage backstage

monor repo used to include both the core plugins like the catalog and the scaffolder as well as community contributed plugins too. Uh we've since moved them out into their own repository uh with dedicated tooling and a looser governance model so that it makes it a little bit easier for us to onboard new maintainers there. Um, we're up to over 190 plug-in packages there across like 100 workspaces

maybe, which is great to see. Uh, and we have like 85 uh maintainers currently working in there reviewing code, managing issues, and shipping releases. So, thank you to all of those maintainers for keeping the plug-in ecosystem healthy. All right. Uh, now here's something super exciting. We have two new co core maintainers to the project, uh, Andre and Ramis. Um they've both been working and contributing for many

years at this point and between the two of them they are maintainers of five different project areas I think uh across tooling documentation community plugins core framework demo site list goes on and they've also helped us represent cube represent the project at cubecon. Uh if you've been around the backstage community for any sort of time you'll know these people um they're familiar faces most likely so we

are super thankful for them and their hard work and excited to have them on board as co- maintainers. uh a little bit of kind of public humiliation uh audience participation. Aramis and Andre are there. Can you stand up so we can just have a round of applause for you guys? Thank you. Thank you. All right, Patrick. >> Uh so for the last bit of the project updates,

uh I want to talk about our new process for handling pull request reviews. Uh so for a long time we've had a project board with automation u but it wasn't very visible for contributors. it was based around randomized assignment. Uh but the problem with that was that each maintainer just got a flood of PRs to handle and it was kind of tricky to focus uh the review

effort. So for a long time we've been trying to enable also a group of community reviewers uh that can help us out but that's also tricky because for a review to count as accepted on GitHub uh the reviewer needs to have right access to the repo. Uh so that in turn means we need to be quite restrictive with that group. Um now so it was with all

of this in mind that we set out to improve the process. It's a quick overview uh of what we now have. Uh to the left you see a global queue uh of all incoming PRs. So as a maintainer I can look through this list filter out on my own project area assigned pull requests uh to myself. As soon as I assign a PR, it's removed from the

global queue and put on my personal board. So this allows me to have a much more focused set of PRs to work with. Now the two very important features of these boards um first off it tracks the state of each pull request. So you can see if it it needs another review uh if it's waiting for the author and that's of course automated and reflected in labels.

Uh so contributors can clearly see the state of their PR. The second thing is that this is a prioritized list. So each pull request is scored based on things like size CI checks and a couple of other factors and things we can evolve over time. uh and also including if co-pilot uh likes the PR or not. Uh and it's a priority system or sorry this priority system

it helps us bring uh the reviewers into this process. If someone from the reviewers group approves a PR it gets a big bump in priority. So this makes it possible for reviewers to have real impact in the process without having full access to the repo. Uh so that way we can make it a much larger group. Uh so of course we're looking for more reviewers. Uh if

you're already an org member uh and there's an issue pinned on the main repo uh that you can go check out uh just comment on it. Otherwise, check out our governance documentation uh for more info. You also get rewarded as a reviewer. Um the more you help out, the higher priority you will get on your own Okay, that's it for project updates. Uh next we of uh

of course have to talk about the front end system. So there's been a lot happening since last time. Uh let's start with some highlights. Couple of general things is that we have better plug-in isolation, better documentation, better testing utilities with more built-in mock APIs. One of the huge things uh is that the old system now has forwards compatibility with the new system. This means that if you

want to support both systems, you no longer need to have any awkward compat wrappers. You just need to provide the wiring for both systems. We we've also improved the appwide navigation, uh which I will show you in just a little bit. uh plugins and pages now have titles and icons which lets us get rid of the weird nav items uh and instead just have pages as the

top level navigation primitive. Uh one of the last big additions was adding built-in support for permissions and feature flags uh on plugins and extensions. We had to do a lot of work uh in the app wiring to enable this h but we're now also set up to build other app level features uh that depend on the user identity. So another big challenge for us is to start

replacing material UI with backstage UI uh our new design system. It's both kind of targeted migrations in plugins like refreshing uh the entity page cards which we did recently but also making broader changes to the app structure. Uh but rather than talking about this uh let me jump into a quick demo to show you more. >> Got this? >> Wow. Magic. >> All right. So here we

have a new backstage app. Um, you can see here the the thing I want to highlight is the new plug-in header. So, this kind of shows backstage UI is uh it's a lot about information density and kind of um you know being able to show more information at once. This header is roughly half the size of the old one and it just shows the overview of what

plugin you're on. Uh you can have global actions in the header both app level and plug-in level action actions. So here in the visualizer you can see the little copy as JSON up there. Now another uh thing we just added are subpages. So these different tabs here uh are subpages of this plugins and they are extensions. So they become you know configurable. You can replace each of

the subpages only rather than the entire page. So this makes plugins a bit more kind of easier to to configure and extend. Um and we found this to be quite uh powerful already. Uh if we look at the user settings page uh we have a couple of subpages here but we also have notifications. And this is the notifications plugin providing uh a subpage to the user settings

uh but without any extra wiring needed in the uh user settings plug-in to enable that. So it's kind of a new new way to extend existing plugins. Uh I want to do that and then I want to do that. Yes. Okay. Uh all right. So that's quite a lot about what we just shipped. Um but where are we at stabilitywise with a new frontend system? Well, we

haven't gotten to 1.0 yet uh as we hoped, but we are almost there. The the release that went out last week is the 1.0 release candidate. Uh with all the recent uh additions, uh and well, we closed all the gaps uh and ship the final fixes that we wanted. And unless anything major pops up, we will mark uh the front end system as stable uh 1.0 in

just a release or two. Now, with the latest release, uh we also felt that the new front end system is a much better starting point for the new backstage adopters. So it's now the default in new apps. We also have new agent skills available uh which we launched uh this week. Uh so there's one for app migration and two different ones for plug-in migrations uh depending on

if you want to fully migrate the plug-in or just have dual system support. Uh to get started you can uh point the skills API to uh backstage.io and uh shout out to Hake over there for helping drive that work. Um now we of course also have to stop supporting uh the old system at some point. Um, but we also recognize that there are a large number of

backstage deployments out there that still rely on it. Uh, phasing out the old system will probably be more aggressive than usual simply due to how much faster migrations can be done now with agent assistance. But we'll of course also keep listening to feedback and see how migrations progress. Uh, expect support for the old system to last until the end of the year. And we can also expect

a bit of a soft phase out of the old system. Uh where you know some features might only ship in the new front system. All right. Uh okay. So let's talk a little bit about MCP and some CLI improvements we've been hard at work building and shipping over the past few months. So first off I want to start off with a section on authentication. So au authentication

has been one of the main blockers when trying to talk to backstage from outside the browser. So I think in one version 124 it was which is like two years ago we shipped something called secure by default which meant that all backend plugins required a valid backstage token. Now in the browser this is all handled for you. You sign in with your o provider and then the

off backend plug-in exchanges that session for a backstage token and then that's what's passed around to all the different backend plugins. But for CLI and MCP that's it's not that straightforward, right? You can't always go through that same flow of plain HTTP. So some providers might require require browser interaction or the O back end actually might behind be behind an SSO proxy or something like that. So

getting a token programmatically becomes pretty difficult. So the common workaround has been these static tokens right that you can define in config and then you can use them to like break through that or barrier or bypass the authentication using those tokens. Uh but they come with a lot of downsides. They are longived. They are hard to manage. they are not great from a security perspective. So roughly

six months ago we showed this at Atlanta which we implemented uh dynamic client registration which was aligned with like the MCP spec which helped us move away from these static tokens. That spec has since evolved uh since then. So now we have something called client identity metadata documents which is going to replace DCR. I'm not going to go into the purposes of or the differences between those

two things uh in this talk but the key point is that CIMD is a lot simpler. Um, we shipped support for CIMD uh about a month ago, I think. Um, and I think this week Claude implemented support for that. So now clients are catching up to that implementation of that spec too. Um, one last thing I want to call out is token lifetime. So previously user tokens

were only valid for like an hour, uh, which isn't great for an MCP use case, uh, where sessions can go on for much longer. So we've added support for offline access scopes and refresh tokens which means that clients can refresh your access token automatically without any user interaction. So you can carry on working with claude or however you like to work without interruptions. Uh okay. Um as

I mentioned on the previous slide uh this secure by default model and the backstage token requirement that CLIs also couldn't talk to back uh backend plugins which was kind of a blocker for things like the scaffolder CLI. Um with the introduction of CIMD however that's kind of changed now. Um it gives us a standard oorthth flow that the CLI can reuse just like an MCP client to

get a token on your behalf. So now you can log into back any backstage instance using this backstage CLI or login command which opens a backstage front end and goes through this like pop-up approval flow. Um yeah you can also sign into multiple backstage instances too. So this is useful if you've got staging in production or if you just want to test out changes locally. Uh the

next one's a cool one. So some of you might might remember in Atlanta we introduced something called the actions registry. So the idea here is pretty simple that we want to give plugins a way to expose reusable actions through the shared surface so that cl different clients can consume them independently. Um if you've ever written a scaffolder action before this should feel pretty familiar I guess. Um,

the main difference is that these actions run alongside the plug-in that provides them rather than being centralized in this scaffolder backend plug-in. Um, up until I think it was last week's mainline release, there was two main ways to use these. One was through actually scaffolder templates. So, you can actually call them part of a scaffolder template, which has been a pretty cool use case, but the most

common by far has been to expose these actions as tools in an MCP server using this MCP actions backend plug-in. Uh, one important detail with the actions registry is that they're just available over HTTP, which means that we can integrate them into new services pretty easily. And that's exactly what we've done with the CLI. And the main benefit from this functionality is that you can now call

out to actions in CI workflows. You can also build skill scripts and a bunch more stuff with like the CLI. Um, yeah, earlier I mentioned that the scaffolder CLI was blocked on authentication. With this now in place, we're kind of about 80% of the way there to like an MVP of a scaffolder CLI. Now we have authentication and a nice modular C cli. Um it's still super

experimental I will say. Um and we're cleaning up over the next few releases. Uh but I would definitely encourage you to go and give it a try. Uh and yes before we jump into demo um there's some new catalog actions which I want to briefly talk about. So we introduced a new query catalog entities action which is built upon a brand new querying format for the catalog

called entity predicates. So this allows us to be or have much more expressive queries when searching the catalog. So it's a lot more flexible now. Um and this also fixed a little bit of like a gap or a bug I guess you could call it with um agents before. So agents only really had one way to query the catalog which was this get catalog entity. And you

can only provide a name, a kind, and a namespace. And if it didn't get it correct on the first time, it would just give up because we can't search the catalog. Whereas now this is a much more flexible querying format for you to be able to do that through uh tools. We've also added a add and remove location. So you can now mutate the catalog and manage

locations directly. Uh another highly requested one was validate entities. So being able to validate uh or submit in raw YAML to run a full validation loop which is great for CI if you want to check the val validity of a catalog info file before merging for instance. Uh and then the last one is who am I? uh which is kind of important for agents. So this enables

things like asking what components do I own to claude. Uh and yes, one last thing before we jump into a demo. I we're really starting to see how important the action registry is becoming especially as now agents are taking on much more of the software development life cycle and adding actions to MCP servers significantly expands what they can do. So, we're going to we're going to be

working on contributing more uh actions to the core plugins. And I'd also encourage you all uh to think about the plugins that you own. Maybe it's open source, maybe it's private internal uh and what tools you might want to expose to agents, too. All right, let's jump into a demo. So, let's hope the demo gods are working and the Wi-Fi works. Let's have a look. all right,

so first off, I'm going to show the CLI. Uh, I'm going to run this or login command here and hope this works. And then we get a little popup asking you maybe can't see. Can you all see this? Is anybody can't see this? >> All right, that was good. I'm just going to make it a bit bigger so you can all see. Uh, yes. So, first off,

you're picking your instance. This is loaded from app config, but you can uh configure this how you like. So, it's picking the one that we have uh which is local 77. I'm going to select that. It's now going to open up the familiar kind of pop-up flow if you've used MCP already. Um, and then we're going to authorize this session. It's going to switch to close. I

can go back and then I can run this actions list. So, this is going to show us all the actions that I can actually run with the CLI locally. Uh, you can see I've got the catalog, the author, and the scaffolder plugin uh installed in back my uh back end. Uh, and I can execute each one of these actions. I'm just going to run this one. We'll

pack into jQ so you can see the format a little bit easier. So, this is the who am I action. So, this just returns like the catalog entity of me that's signed in, which you can see is me, Ben Lambert at the bottom. Uh, and also the attached groups uh that I'm a part of and any claims that I have. Uh, let's jump over to Claude real

quick and I'm just going to follow the same flow here. I'm just going to go to MCP, connect to my local backstage. We go through the same uh all flow again. We authorize this, head back to Claude. Uh, and then if I jump into the MCP part and view the tools, I can see all of these different tools that I can call and all the descriptions. And

this is exactly the same list in the CLI. Uh, let me just go back and ask it a nice question. What components do I own? Right, this is where we hope that Claude is working. And it's going to use the MCP tools. It's drizzling. Uh, yeah. So now we can see it's going to call the who am I action first which is going to get context about

who I am. Uh it can see you can see here it's returning that it's me Ben Lambert the user Ben and I'm a member of platform team and then it goes to make another query to the catalog here which is using this new query catalog entities action which is searching for the owned by relation if it's owned by me or if it's owned by any of my

groups. Uh yeah and I can see a nice breakdown of the stuff that I own in backstage. Cool. Uh I am gonna now Yeah, that worked. There we go. Pop back to Patrick. Okay. Now, um if you've been developing in Backstage, uh you know that our CLI is a big monolith. Uh it's also targeting a mix of different user personas like uh operators, builders, publishers, and end

users. what Ben just demoed is primarily for end users and they do not want to install uh the entire backstage CLI just to run those commands. So it's a good thing that in the latest release we finally shipped CLI modularization. Uh it splits up the CLI into separate modules each with their own set of commands. For example, there's a module for for linting, one for migrations, one

for config management and so on. One important features of these modules is that you can also run them as standalone CLI for example with MPX. So this ability to run them separately is especially important for end users where it's much easier to run one-off commands like uh the off and actions ones uh that Ben just demoed. Uh this also sets us up much better to evolve uh

the backstage tooling in a better way uh rather than awkward peer dependencies and and toggles. We can now just switch out an entire module for something new. Uh so we will of course also refactor the other uh our other CLIs to follow that pattern. um but also have some other interesting items on our road map uh like being able to use vest instead of just or replacing

eslint with oxlint. Now you can also build your own CLI modules. Um I'll give a quick overview of what that looks like. Uh to the left you see the module API which is uh which you use to just register one or more commands for your modules. It's a bit like the back system but it's much more lightweight. The purpose of the system is really just to provide

a common base and shared surface for commands. Now the way you implement commands isn't opinionated at all. You get args forwarded uh a common context but that's it. You parse the flags uh in and then just do whatever you want really in the command implementation. Now we currently recommend CLI uh for flag parsing but that's also something that we can switch out over time. Now the reason

we do this split between uh and and lazy load the uh the implementation is to keep the CLI snappy. Uh there's a huge difference between in speed uh between having to load the full dependency tree of all the different implementations of modules into the runtime as opposed to just um the outer module wiring. And lastly uh shout out to our new core maintainer Aramis for doing a

lot of this work. All right. Uh so that's a bunch about toolings and features. I want to zoom out uh and look more generally at Backstage's role in AI and the valuable context that it provides. What I want to talk about is a broader picture that's emerging. Backstage has always been about being a single hub for developer experience and that used to mean uh web UI. That's

still a really big part of it. Uh it's very valuable to be able to go into UI, look up information, check the latest build results, see deployment status metrics, but we are now of course also seeing backstage power other surfaces. There's the CLI that we just talked about uh which is really useful for automation uh for example in CI workflows and skill scripts. Uh and then there's

MCP tools and AI uh MCP and AI tools uh where we have the actions registry and new catalog entities and other solutions in the wild. Now, an interesting uh trend is that with this shift towards automated programming, uh developers are spending less time manually writing code and while still shipping more. At Spotify, we have a high degree of AI adoption. And what we're seeing seeing uh for

our internal backstage usage is that it's gone up the last couple of months. Another interesting trend is that the more an engineer uses AI tools, the more they also use the backstage UI, which indicates that AI does not replace the UI. We're seeing the usage change though, of course, uh it's less about information lookup and more about operations. With less time spent writing code, more time is

spent across these other surfaces. If anything, that points towards backstage being more important than ever to help coordinate this steep increase in delivery and maintenance. Now, all of these surfaces interact on the same underlying data. Um, and at the core of that is the software catalog. But here's the challenge. Uh, for AI, the context is especially important. But the catalog model today is essentially a blackbox. The

schema is defined in code, and if a plug-in contributes to the schema, that's often scattered across code and documentation. It's hard to discover what the data in the catalog really means. It's just kind of raw data with little context. You can fill in some of these gaps manually, but that's put puts more burden on adopters and it doesn't scale that well. So, that's a pretty big problem

uh which we have now set out to solve. What we're currently working on is evolving the catalog model into something that's more inspectable and extensible in a structured way. We're changing the way the base model is declared and how you can customize it. We're also aiming for plugins to be able to declare contributions to the model so that when you install a plug-in, its annotations or even

kinds or custom fields become part of the model that can then be queried and understood by other parts of the system. We're still in the early stages of this work. Uh but it's one of our top priorities right now. So, let me hand it back to Ben uh to show you the progress we've made so far. >> All right. So before I jump in and show us

some uh screenshots of what we've been working on so far, I want to recap these three highlevel use cases that we're targeting. So first is uh plugins claiming ownership of things like annotations. So as Patrick mentioned, a lot of the plugins define their own annotations like Kubernetes and page duty and there's no real standard way to describe or validate them. So they end up as these arbitrary

key value pairs which as mentioned makes the catalog feel a little bit like a black box especially for things like LMS. Uh second is extending the spec uh of an existing kind. So internal internally at Spotify and I'm sure this is true for other adoptists as well that we store a lot of extra information alongside uh the default meta or the default catalog model on components etc.

Um but without context that's just additional data. So you've got keys and values but no information about what they actually mean or what values can be expected. Uh and it kind of makes things hard to interpret. And third is creating entirely new kinds in the catalog. So today you can do these um you can create these new kinds using processes and JSON schema. Uh but they're completely

internal to the catalog. Like nothing outside of the processing loop in the catalog actually knows what these kinds represent. And all three of these uh use cases is exactly what we've been looking at for this new model extension uh API. Um and that's what this is designed to solve. So now this is really hot off the press. It hasn't landed in release yet. We're aiming for 150.

um but it should be available in the next next release pretty soon. And the idea is we're introducing this new core service into backstage that lets you define uh these model extensions. As you can see on this slide, this is the new builder that we're building. So here's a quick sneak peek at what this might look like. So I'm using the Kubernetes plugin here as an example.

Um so the Kubernetes plug-in uses annotations on entities to map them to Kubernetes resources. And there's a few ways to do it, but one of them is this label selector annotation. And the problem is unless you or an LLM already understand how label selectors work and how they work in backstage, it's pretty hard to understand what that annotation actually means and what format it expects and how

to use it correctly. So in this example, we're using the builder uh to add an annotation to the model along with proper descriptions and metadata. Uh you can also define the JSON schema for validation as well as some uh examples too. And this is really important for both humans and agents, right? Instead of guessing what this field means, you now have structure, validation, context, which makes the

catalog much easier to reason about. Okay, so what about new kinds? Uh, so today something like scaffolder templates, for instance, aren't actually part of the default model. They're installed separately as a module, which means you also need to wire up these things to make the processes work. With this approach, this changes. Uh, you no longer need to build or register those processes yourself. Instead, plugins can contribute

directly to your software ecosystem model. So for example, when you install the scaffolder plugin, it's going to register the template kind automatically along with all the associated metadata and schemas. Uh which effectively replaces what that processor was doing before. Most of the heavy lifting is still handled by the existing JSON schema, but we layering on additional metadata around the kinds and exposing everything through a standard API

that both the catalog and other plugins can consume. Uh there's also some extra capabilities here like defining relations uh between kinds which again also used to live in those processes. I'm not going to go too deep into relations in this bit. If you want to know more, please come check us out at the booth after we are there tomorrow and today towards the afternoon. Um, and lastly,

before we head into the last f last few final slides, uh, a quick look at how you can add your own model extension. So, in this example, we're adding uh a manager field to the spec of a group. Uh, this one's a little bit more involved because we also need to define the relations that come from it. And in this case, it's a brand new relation. So,

I've split this into two parts. So first off you define the relation itself which is this new API uh that lets you gen create brand new relations into the model and then you exist the then you update the existing kind and the API version uh to include your new field along with how that relationship is generated. Uh so overall you're not just adding data anymore. You're adding

or defining how that data connects and behaves with the catalog All right, let's finally wrap up with a little bit of a look ahead into the future in our road map for 2026. So, a few highlights I want to call out. Catalog model extensions, what we've just been talking about there. That's a big focus for us right now. Getting all of that into like a machine readable

format for LLMs and making sure it's in a really good place over the next few releases. That's our top priority right now. Um, another thing that's totally hot off the press, uh, is this AI context kind, which on my notes here, it says landed this week. actually landed about 2 hours ago. Um it's closely related to model extensions. Uh but it's all about providing additional context to

AI. So the initial use case is storing things like skills in the catalog. U mainly for like governance and discoverability. Um we're starting there probably going to evolve into more things like prompts later down the line. Uh there's an RFC out. Please go check it out and leave some comments and feedback on there. We're planning on picking this work up pretty soon uh to try and get

more stuff into the catalog around AI. Um release process. Uh this is something we've been wanting to improve for quite some time. We're likely going to be moving away from the monthly backstage versioning model uh and instead slowing releases down for core framework and APIs whilst increasing the uh release cadence for plugins themselves. So the goal here is to reduce a lot of confusion around versioning make

things a little bit clearer overall stability uh as well as shipping plugins faster. Uh backstage UI is also continued to evolve uh adoption across the core plugins and is help shel help it shape this library. Wow. Uh and we're also looking to expand this further across the plug-in ecosystem too. And finally, as mentioned earlier, we're also going to be phasing out support for the old front-end system.

And that is all we had today. Thank you so much.