 Good morning, everyone. It's a pleasure to welcome you all to BackstageCon on behalf of Red Hat. I am Balaji Siva-Supermanian. I lead the product management team for DollarPort Tools. Today, I want to share with you how Red Hat is contributing to streamlining Backstreet adoption in enterprises. For those not familiar, Red Hat is all about open source-driven innovation. We live and breathe open source ethos, actually contributing actually over one million projects. As top contributors to projects like Linux and Kubernetes, we are thrilled to bring that enthusiasm to the Backstage project. Red Hat's expertise in building, contributing, and expanding the open source project to industry standard, as well as broadening adoption in enterprises align seamlessly with the Backstage goals. So let's dive into the challenges that we see and how we are approaching to solve these problems. Given the limited time I have today, I'll just spotlight three key blockers. Enterprise RBAC, ecosystem of validated, secure plugins, ease of plugin management. For the most enterprises, Backstage default access for everyone just doesn't cut it. Backstage permission framework requires creating and maintaining an RBAC plugin involving significant coding and ongoing maintenance work. Not exactly the most scalable way for an enterprise. So introducing Red Hat RBAC plugin. We have simplified the game, allowing you to define roles, assign groups to those roles, and access permission without having to write any complex code. Manage your access policy seamlessly through the Backstage UI or configuration files. And here's the kicker, it's free, open source. You can, it's ready for download. You can download from that URL shown there. There's also a talk at 240 by Gorkham if you wanna know more about this plugin. And the Backstage plugin seamlessly connect the various developer ecosystem tools to the Backstage, right, and we have seen many interest there. Exciting news, in the last six months we have released over 10 new plugins and more to come from our contributions to Backstage. To improve your Backstage experience. You can download these plugins today from the Backstage marketplace. We also realize it's not just contributing first, we also have to maintain it and enrich them over time, and we will do so. Now let's talk about a key concern in our community is a lack of provenance and security check on plugins. This poses risks for enterprises as well as uncertainty or maintenance and compatibility issues. Our call to action to the community is let's create a validation process, ideally a cell service for plugins. So for every release in Backstage community marketplace. We are already coordinating with select ISV partners to kickstart a validation process. And we wanna improve the plugin ecosystem with as many ISV vendors contributing first party plugins to the ecosystem. And that is a good way to get started there. So stay tuned for updates. And as you plan to join forces with the other contributors here to build a safer, vibrant plugin ecosystem. And finally, let's talk about plugin management. Adding a new plugin today involves a series of steps, changing code, rebuilding, repackaging and redeploying Backstage. Even with the declarative plugin integration, there's still, you need to rebuild and redeploy Backstage. It could be a problem if you're running a production instance with lots of developers already on it. I wanna introduce you to dynamic plugins. A one-take solution from a catalog or a simple configuration. No need to touch code or go through entire rebuild, redeploy process. You can add new plugins to your production Backstage instance without the hassle of coding. This is a game changer, especially for enterprises supporting a multitude of developers with diverse requirements. You can try it out today. It's available in tech preview. Go to that URL shown there. Also share the feedback and follow the RFC in the community, Backstage community, if you want to put your thoughts in there and provide feedback. And let's see the dynamic plugin in action. On the left side, we are adding a plugin by just updating the Helm chart. The user wants to add a Quay plugin in the production Backstage instance. So essentially, he goes to the Backstage Helm chart and provides a URL of the Quay plugin. He also adds an SHA hash to validate the plugin that is downloaded and secure. And then he restarts the Backstage instance. Voila, instant access to the new plugin in your Backstage instance. On the right side, you see a plugin catalog convenience. The user installs a plugin directly from the plugin catalog with click. And it, again, does the same thing, essentially, in the background. But you have the plugin again instantaneously. Exciting, right? So please go ahead and try it out. And we're outside here in the booth. So you can combine and ask for more information if needed. As we wrap up, I want to reiterate Red Hat's commitment to the Backstage project success. We are thrilled about the prospect of Backstage being a staple in enterprise everywhere. And we have something for you. Our dollar advocates penned a book packed with best practices and a guide for seamless enterprise adoption of Backstage. You can download it there. You can just use the QR code, and you will be able to reach that URL. Looking to explore even more, try our commercial offering, Red Hat Dollar Per Hub, with full compatibility with the upstream Backstage. And obviously, fully supported from Red Hat. Simply send a request to that alias shown there. We will give you immediate access right away. And thank you today for joining me and enjoy the rest of the conference. Oh, by the way, if you want to give feedback on the session, here's a link. Awesome, Valadji. Thank you so much. Do we have any questions? We can take like two quick ones, I think. Anybody? Over here. Doesn't the dynamic plug-in set up sort of contradict the safety and testing of deployment virus CICD? You know, you have the ability to do the dynamic plug-in. You know, it's on your end to be able to enable that. It's a plug-in itself. So it enables that framework, so that if you want to enable those plug-ins, obviously, you will only give access to certain people who have permissions to enable dynamically. You don't want anybody to install a plug-in. Number one, you want to have only the admins, essentially, have access to those plug-ins. So you have to have the process to obviously have the plug-in ready to go. And as I mentioned before, you can put a security hash to make sure it's the right plug-in. And then only you can automatically enable it. The goal is for us is to, as we go to production, let's say, a year from now or two years, you had to start more and more plug-ins in the ecosystem. Today, over 150 plug-ins, I'm thinking in the next few years, we have more and more. And people may want to add more of these plug-ins dynamically so that you're able to quickly enable developers. Any other questions? One more here. Is the developer portal that Red Hat's making, is that like OpenShift specific? Or will it support any Kubernetes clusters? Yeah, the Red Hat developer hub runs on any Kubernetes. OK, thank you. Thank you so much. Thank you.