Merge branch 'master' into patch-3

Signed-off-by: Damola Obaleke <45045727+damolaobaleke@users.noreply.github.com>
2026-02-03 11:12:36 -08:00
parent 89b199f1c8 3581e7d2c9
commit caa10d6944
12732 changed files with 1670724 additions and 558733 deletions
@@ -13,7 +13,7 @@ It’s the first open source infrastructure platform by Spotify that allows you

 ![img](assets/blog_1.png)

-<!--truncate-->
+{/* truncate */}

 ## As simple as writing a plugin.

@@ -9,7 +9,7 @@ authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaac

 Two days ago, we released the open source version of [Backstage](https://backstage.io/), our homegrown developer portal. And we learned a thing or two via the feedback we received. So, I wanted to take this opportunity to further explain what we’re trying to do with Backstage — and more importantly, what we want to give to the greater engineering community beyond Spotify.

-<!--truncate-->
+{/* truncate */}

 ## What’s the big infrastructure problem?

@@ -85,4 +85,4 @@ We are envisioning [three phases](https://github.com/backstage/backstage/milesto

 https://github.com/backstage/backstage/milestones

-Want to discuss the project or need support? Join us on [Discord](https://discord.gg/MUpMjP2) or reach out on [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com).
+Want to discuss the project or need support? Join us on [Discord](https://discord.gg/backstage-687207715902193673) or reach out on [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com).
@@ -9,7 +9,7 @@ authorImageURL: https://pbs.twimg.com/profile_images/1224058798958088192/JPxS8uz

 We’re proud to announce that our first internal plugin at Spotify has been open-sourced as part of Backstage. This plugin works with the newly open-sourced [lighthouse-audit-service](https://github.com/spotify/lighthouse-audit-service) to run and track Lighthouse audits for your websites.

-<!--truncate-->
+{/* truncate */}

 ## What is Lighthouse?

@@ -33,7 +33,7 @@ Trigger an audit directly from Backstage, or trigger audits programmatically wit

 ## Using Lighthouse in Backstage

-To learn how you can enable Lighthouse auditing within Backstage, head over to the [README](https://github.com/backstage/backstage/tree/master/plugins/lighthouse) for the plugin to get started.
+To learn how you can enable Lighthouse auditing within Backstage, head over to the [README](https://github.com/backstage/community-plugins/tree/main/workspaces/lighthouse/plugins/lighthouse) for the plugin to get started.

 ## A personal note

@@ -11,7 +11,7 @@ We want users to be able to create their own version of Backstage quickly and ea

 In this blog post we’ll look at what a Backstage app is and how to create one using our [CLI](https://www.npmjs.com/package/@backstage/cli).

-<!--truncate-->
+{/* truncate */}

 ## What is a Backstage app?

@@ -45,7 +45,7 @@ The only thing you need to do is to start the app:

 ```bash
 cd my-app
-yarn dev
+yarn start
 ```

 And you are good to go! 👍
@@ -102,7 +102,7 @@ Install in your app’s package folder (`<root>/packages/app`) with:

 ```bash
 # From your Backstage root directory
-yarn add --cwd packages/app @backstage/plugin-<plugin-name>
+yarn --cwd packages/app add @backstage/plugin-<plugin-name>
 ```

 After that, you inject the plugin into the application where you want it to be exposed. Please read the documentation for the specific plugin you are installing for more information.
@@ -125,4 +125,4 @@ If you are developing a plugin that might be useful for others, consider releasi

 ## Ready to get started?

-Head over to GitHub and check out the [project](https://github.com/backstage/backstage) or download our [CLI](https://www.npmjs.com/package/@backstage/cli). If you have more questions, join us on [Discord](https://discord.gg/MUpMjP2) or [create an issue](https://github.com/backstage/backstage/issues/new/choose).
+Head over to GitHub and check out the [project](https://github.com/backstage/backstage) or download our [CLI](https://www.npmjs.com/package/@backstage/cli). If you have more questions, join us on [Discord](https://discord.gg/backstage-687207715902193673) or [create an issue](https://github.com/backstage/backstage/issues/new/choose).
@@ -9,7 +9,7 @@ authorImageURL: https://avatars0.githubusercontent.com/bih

 Just a few weeks ago, we released our internal plugin for [Lighthouse website audits] as our first open source plugin, so the whole community could use it. Today, we’re excited to add a new plugin to that list — say hello to the [Tech Radar plugin]!

-<!--truncate-->
+{/* truncate */}

 ## What is Tech Radar?

@@ -22,7 +22,7 @@ We also assign clear definitions for each lifecycle:
 - **Use:** This technology is recommended for use by the majority of teams with a specific use case.
 - **Trial:** This technology has been evaluated for specific use cases and has showed clear benefits. Some teams adopt it in production, although it should be limited to low-impact projects as it might incur a higher risk.
 - **Assess:** This technology has the potential to be beneficial for the company. Some teams are evaluating it and using it in experimental projects. Using it in production comes with a high cost and risk due to lack of in-house knowledge, maintenance, and support.
- **Hold:** We don’t want to further invest in this technology or we evaluated it and we don’t see it as beneficial for the company. Teams should not use it in new projects and should plan on migrating to a supported alternative if they use it for historical reasons. For broadly adopted technologies, the Radar should refer to a migration path to a supported alternative.
+- **Hold:** We don't want to further invest in this technology or we evaluated it and we don't see it as beneficial for the company. Teams should not use it in new projects and should plan on migrating to a supported alternative if they use it for historical reasons. For broadly adopted technologies, the Radar should refer to a migration path to a supported alternative.

 Since rolling out the Tech Radar, it has become the source of truth when creating, maintaining, or evolving our software ecosystem. Spotify has dozens of entries in our Radar and it can scale quite well whilst being easy for our engineers and engineering managers to consume.

@@ -32,13 +32,13 @@ To learn about how you can bring the Tech Radar to your Backstage installation,

 ## A personal note

-I want to thank both the Backstage team and Spotify. Firstly, I’ve been working with our internal version of Backstage for over a year, and the developer experience since open sourcing has been even more of a joy to work with. Secondly, the 10% hack time that Spotify generously provides to all engineers enabled me to open source the Tech Radar plugin.
+I want to thank both the Backstage team and Spotify. Firstly, I've been working with our internal version of Backstage for over a year, and the developer experience since open sourcing has been even more of a joy to work with. Secondly, the 10% hack time that Spotify generously provides to all engineers enabled me to open source the Tech Radar plugin.

 Since open sourcing it, the community has shown great interest in yet another powerful use case of Backstage. There was also an enthusiastic open source contributor who volunteered to migrate the plugin to TypeScript and React Hooks [in just 29 minutes](https://github.com/backstage/backstage/issues/661) of opening the issue!

-I can’t wait to see how others benefit from the Tech Radar in their organizations!
+I can't wait to see how others benefit from the Tech Radar in their organizations!

 [lighthouse website audits]: https://backstage.io/blog/2020/04/06/lighthouse-plugin
-[tech radar plugin]: https://github.com/backstage/backstage/tree/master/plugins/tech-radar
+[tech radar plugin]: https://github.com/backstage/community-plugins/tree/main/workspaces/tech-radar/plugins/tech-radar
 [thoughtworks]: https://www.thoughtworks.com/radar
 [zalando]: https://opensource.zalando.com/tech-radar/
@@ -9,7 +9,7 @@ authorImageURL: https://avatars2.githubusercontent.com/u/46946747

 One of the great things about the open source community is once you put your work out there, you really never know where it might end up. That’s certainly the case here.

-<!--truncate-->
+{/* truncate */}

 When Weaveworks decided to build an X-ray diagnostics app to help fight COVID-19, they pulled together a lot of different open source resources — from projects big and small, built by both familiar tech partners and some brand new ones, too.

@@ -1,6 +1,5 @@
 ---
-# prettier-ignore
-title: "Starting Phase 2: The Service Catalog"
+title: 'Starting Phase 2: The Service Catalog'
 author: Stefan Ålund, Spotify
 authorURL: http://twitter.com/stalund
 authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaace78c3009b28e917-user-full-200-130.generated_400x400.jpg
@@ -12,7 +11,7 @@ We released the open source version of Backstage a little less than two months a

 ![img](assets/20-05-20/Service_Catalog_MVP.png)

-<!--truncate-->
+{/* truncate */}

 ## Progress so far

@@ -40,7 +39,7 @@ On top of that, we have found that the service catalog is a great way to organis

 ![img](assets/20-05-20/tabs.png)

-More concretely, having this structure in place will allow plugins such as [CircleCI](https://github.com/backstage/backstage/tree/master/plugins/circleci) to show only the builds for the specific service you are viewing, or a [Spinnaker](https://github.com/backstage/backstage/issues/631) plugin to show running deployments, or an Open API plugin to [show documentation](https://github.com/backstage/backstage/issues/627) for endpoints exposed by the service, or the [Lighthouse](https://github.com/backstage/backstage/tree/master/plugins/lighthouse) plugin to show audit reports for your website. You get the point.
+More concretely, having this structure in place will allow plugins such as [CircleCI](https://github.com/backstage/backstage/tree/master/plugins/circleci) to show only the builds for the specific service you are viewing, or a [Spinnaker](https://github.com/backstage/backstage/issues/631) plugin to show running deployments, or an Open API plugin to [show documentation](https://github.com/backstage/backstage/issues/627) for endpoints exposed by the service, or the [Lighthouse](https://github.com/backstage/community-plugins/tree/main/workspaces/lighthouse/plugins/lighthouse) plugin to show audit reports for your website. You get the point.

 ## Timeline

@@ -9,7 +9,7 @@ image: https://backstage.io/blog/assets/6/header.png

 ![img](assets/6/header.png)

-<!--truncate-->
+{/* truncate */}

 ## You asked, we listened

@@ -49,6 +49,6 @@ Alpha is our shorthand for "we don’t yet think Backstage is ready for producti

 As with most alpha releases, you should expect things to change quite a lot until we reach the beta stage (we’re targeting the end of summer). There are obviously many things missing as well, but we wanted to start collecting feedback early and make it easier to see the end-to-end flow.

-If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/EBHEGzX) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏
+If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/backstage-687207715902193673) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏

-To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://mailchi.mp/spotify/backstage-community).
+To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://info.backstage.spotify.com/newsletter_subscribe).
@@ -9,7 +9,7 @@ authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4

 Getting authentication right is important. It helps keep your platform safe, it’s one of the first things users will interact with, and there are many different authentication providers to support. To this end, we chose to use [Passport](http://www.passportjs.org/) to provide an easy-to-use, out-of-the-box experience that can be extended to your own, pre-existing authentication providers (known as strategies). The Auth APIs in Backstage serve two purposes: identify the user and provide a way for plugins to request access to third-party services on behalf of the user. We’ve already implemented Google and GitHub authentication to provide examples and to get you started.

-<!--truncate-->
+{/* truncate */}

 ## What is Passport?

@@ -7,10 +7,10 @@ authorURL: https://twitter.com/stalund
 **TL;DR** Today we are announcing a new Backstage feature: Software Templates. Simplify setup, standardize tooling, and deploy with the click of a button. Using automated templates, your engineers can spin up a new microservice, website, or other software component with your organization’s best practices built-in, right from the start.

 <video width="100%" height="100%" controls>
-  <source src="/blog/assets/2020-08-05/feature.mp4" type="video/mp4" />
+  <source src="/video/software-templates.mp4" type="video/mp4" />
 </video>

-<!--truncate-->
+{/* truncate */}

 ## Balancing autonomy and standardization

@@ -69,10 +69,10 @@ New components, of course, get added automatically to the Backstage Service Cata

 ## Define your standards

-Backstage ships with four example templates, but since these are likely not the (only) ones you want to promote inside your company, the next step is to add [your own templates](https://backstage.io/docs/features/software-templates/software-templates-index). Using Backstage’s Software Templates feature, it’s easy to help your engineers get started building software with your organization’s best practices built-in.
+Backstage ships with four example templates, but since these are likely not the (only) ones you want to promote inside your company, the next step is to add [your own templates](https://backstage.io/docs/features/software-templates/). Using Backstage’s Software Templates feature, it’s easy to help your engineers get started building software with your organization’s best practices built-in.

 We have learned that one of the keys to getting these standards adopted is to keep an open process. Templates are code. By making it clear to your engineers that you are open to pull requests, and that teams with different needs can add their own templates, you are on the path of striking a good balance between autonomy and standardization.

-If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/EBHEGzX) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏
+If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/backstage-687207715902193673) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏

-To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://mailchi.mp/spotify/backstage-community).
+To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://info.backstage.spotify.com/newsletter_subscribe).
@@ -1,16 +1,21 @@
 ---
-# prettier-ignore
-title: "Announcing TechDocs: Spotify’s docs-like-code plugin for Backstage"
+title: 'Announcing TechDocs: Spotify’s docs-like-code plugin for Backstage'
 author: Gary Niemen, Spotify
 authorURL: https://github.com/garyniemen
 ---

 Since we [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage), one of the most requested features has been for a technical documentation plugin. Well, good news. The first open source version of TechDocs is here. Now let’s start collaborating and making it better, together.

-<iframe width="780" height="440" src="https://www.youtube.com/embed/mOLCgdPw1iA" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen>
-</iframe>
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/mOLCgdPw1iA"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>

-<!--truncate-->
+{/* truncate */}

 Internally, we call it TechDocs. It’s the most used plugin at Spotify by far — accounting for about 20% of our Backstage traffic (even though it is just one of 130+ plugins). Its popularity is evidence of something simple: We made documentation so easy to create, find, and use — people actually use it.

@@ -40,7 +45,7 @@ More specifically, with this first iteration, you can:
 - Choose your own storage solution for the documentation.
 - Define your own API to interface with your documentation solution.

-For a full overview, including getting started instructions, check out our [TechDocs Documentation](https://backstage.io/docs/features/techdocs/techdocs-overview).
+For a full overview, including getting started instructions, check out our [TechDocs Documentation](https://backstage.io/docs/features/techdocs/).

 But before you go there, let me tell you a bit about the TechDocs story — and why we believe TechDocs is such a powerful yet simple solution for great documentation.

@@ -112,7 +117,7 @@ Code-like-docs, what? Okay, it’s just my little play on words. This is what I

 ### Golden Paths

-At Spotify, we have the concept of [Golden Paths](https://engineering.atspotify.com/2020/08/17/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/) — one for each engineering discipline. My favourite definition of Golden Path is that it is the “opinionated and supported path”. Each Golden Path has an accompanying Golden Path tutorial that walks you through the opinionated and supported path.
+At Spotify, we have the concept of [Golden Paths](https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/) — one for each engineering discipline. My favourite definition of Golden Path is that it is the “opinionated and supported path”. Each Golden Path has an accompanying Golden Path tutorial that walks you through the opinionated and supported path.

 The Golden Path tutorials are Spotify’s most used and important documents and have shown themselves to be the most challenging to manage within a docs-like-code environment. One reason for this is that they are long, divided into many parts, and ownership is typically spread among many different teams. We have had to make use of GitHub codeowners to handle ownership and had to create datasets and data pipelines to be able to attach GitHub Issues to the specific parts or files that a team owns. Another challenge of the Golden Path tutorials is that parts are often dependent on other parts. We are just starting to look into how we can solve these dependency challenges in order to remove friction for engineers writing tutorial documentation.

@@ -8,7 +8,7 @@ authorURL: https://twitter.com/stalund

 ![cncf](assets/cncf-sandbox/cncf.png)

-<!--truncate-->
+{/* truncate */}

 Backstage garnered quite a bit of interest from developers and organizations when it was first announced, and community interest continues to grow as plugins and new features are added with the open source community. We released the open source version of Backstage ‘early’. That was intentional. Because even though we’ve been using Backstage internally for years, we wanted the open source version to be developed with input and contributions from the community. And that’s exactly the product that’s going into the [CNCF Sandbox](https://www.cncf.io/sandbox-projects/) today.

@@ -18,4 +18,4 @@ The Backstage community is healthy and growing quickly. Over [130 people](https:

 We’re excited to embark on this journey with the CNCF community. There’s so much great tech being built here, and it’s about time we share it to build even greater products, together. Entering into the CNCF Sandbox is just the first step. We are committed to working with the community to bring Backstage through the Incubation step, and finally all the way to becoming a Graduated, top-level project.

-Thanks to everyone for your support so far. We hope you [join us](https://mailchi.mp/spotify/backstage-community) in this next chapter of Backstage's journey. If you have questions or feedback, feel free to [email](mailto:backstage-interest@spotify.com) me directly.
+Thanks to everyone for your support so far. We hope you [join us](https://info.backstage.spotify.com/newsletter_subscribe) in this next chapter of Backstage's journey. If you have questions or feedback, feel free to [email](mailto:backstage-interest@spotify.com) me directly.
@@ -8,7 +8,7 @@ authorURL: http://twitter.com/katherinemzhou

 We are excited to launch the Backstage Design System, which includes a [Figma UI kit](https://www.figma.com/community/file/850673348101741100), a rich set of [reusable code components](http://backstage.io/storybook) on Storybook, and [Guidelines](https://backstage.io/docs/dls/design) for designers and developers as they build plugins for Backstage.

-<!--truncate-->
+{/* truncate */}

 ## Not just the way it looks

@@ -12,7 +12,7 @@ Now you may be thinking, “Yeah, sure, that sounds nice and all, but how does B

 ![plugins](https://backstage.io/img/cards-plugins.png)

-<!--truncate-->
+{/* truncate */}

 Think of plugins as a mini version of an infrastructure tool or service — just the parts you need, made quick and easy. The advantage of using a Backstage plugin instead of a tool’s dedicated UI is that all your infrastructure is packaged into a “single pane of glass” instead of being spread out like independently built “islands”. Once you grow your infrastructure portfolio, the complexity really starts to add up. The Backstage plugin model allows you to add more tools without increasing the cognitive load for your users.

@@ -34,7 +34,7 @@ This grand vision is actually not that far off. Already today there is a growing

 Not all plugins you need will be open source. Every company has their own homegrown tooling. Building internal plugins lets you tailor your version of Backstage to be a perfect fit for your infrastructure and software development needs. If you end up [building plugins](https://backstage.io/docs/plugins/create-a-plugin) that could be useful for other companies, please consider releasing them as open source and [add them to the Marketplace](https://backstage.io/docs/plugins/add-to-marketplace).

-If you start developing a plugin that you aim to release as open source, we suggest that you create a [new plugin Issue](https://github.com/backstage/backstage/issues/new?labels=plugin&template=plugin_template.md&title=%5BPlugin%5D+THE+PLUGIN+NAME). This helps the community know what plugins are in development and opens up opportunities for collaboration. You can also use this process if you have an idea for a good plugin, but you need help building it.
+If you start developing a plugin that you aim to release as open source, we suggest that you create a [new plugin Issue on the community plugins repo](https://github.com/backstage/community-plugins/issues/new/choose). This helps the community know what plugins are in development and opens up opportunities for collaboration. You can also use this process if you have an idea for a good plugin, but you need help building it.

 We are really excited to see all the amazing plugins that have already been built, and look forward to seeing even more ideas and collaboration as the Backstage community continues to grow.

@@ -1,17 +1,23 @@
 ---
-# prettier-ignore
-title: "New Cost Insights plugin: The engineer’s solution to taming cloud costs"
+title: 'New Cost Insights plugin: The engineer’s solution to taming cloud costs'
 author: Janisa Anandamohan, Spotify
 authorURL: https://twitter.com/janisa_a
 ---

-How did Spotify save millions on cloud costs within a matter of months?? We made cost optimization just another part of the daily development process. Our newly open sourced [Cost Insights plugin](https://github.com/backstage/backstage/tree/master/plugins/cost-insights) makes a team’s cloud costs visible — and actionable — right inside Backstage. So engineers can see the impact of their cloud usage (down to a product and resource level) and make optimizations wherever and whenever it makes sense. By managing cloud costs from the ground up, you can make smarter decisions that let you continue to build and scale quickly, without wasting resources.
+How did Spotify save millions on cloud costs within a matter of months?? We made cost optimization just another part of the daily development process. Our newly open sourced [Cost Insights plugin](https://github.com/backstage/community-plugins/tree/main/workspaces/cost-insights/plugins/cost-insights) makes a team’s cloud costs visible — and actionable — right inside Backstage. So engineers can see the impact of their cloud usage (down to a product and resource level) and make optimizations wherever and whenever it makes sense. By managing cloud costs from the ground up, you can make smarter decisions that let you continue to build and scale quickly, without wasting resources.

-<iframe width="780" height="440" src="https://www.youtube.com/embed/YLAd5hdXR_Q" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/YLAd5hdXR_Q"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>

 Are we turning engineers into accountants? Nope, we’re just letting engineers do what they do best, in the place that feels natural to them: inside Backstage.

-<!--truncate-->
+{/* truncate */}

 ## Why put a cost management tool in the hands of engineers?

@@ -60,7 +66,7 @@ Engineers can then determine for themselves if the time invested in an optimizat

 ## Getting started

-You can begin working with the Cost Insights plugin today on [GitHub](https://github.com/backstage/backstage/tree/master/plugins/cost-insights). We include an example client with static data in the expected format. The `CostInsightsApi` should talk with a cloud billing backend that aggregates billing data from your cloud provider.
+You can begin working with the Cost Insights plugin today on [GitHub](https://github.com/backstage/community-plugins/tree/main/workspaces/cost-insights/plugins/cost-insights). We include an example client with static data in the expected format. The `CostInsightsApi` should talk with a cloud billing backend that aggregates billing data from your cloud provider.

 The current release of Cost Insights includes:

@@ -77,4 +83,4 @@ And if you’re interested in contributing to our outstanding issues, you can fi

 ## Ready for DevSecCostOpsPlus (and whatever’s next)

-There’s DevOps, there’s DevSecOps, and then there’s Backstage: one frontend for all your infrastructure. From building, testing, and deploying to monitoring and security — Backstage helps you manage your entire tech organization and provides a seamless developer experience for engineers, from end to end to end. And now that also extends to cost management for your cloud infrastructure and tooling. Happy building and [happy optimizing](https://github.com/backstage/backstage/tree/master/plugins/cost-insights).
+There’s DevOps, there’s DevSecOps, and then there’s Backstage: one frontend for all your infrastructure. From building, testing, and deploying to monitoring and security — Backstage helps you manage your entire tech organization and provides a seamless developer experience for engineers, from end to end to end. And now that also extends to cost management for your cloud infrastructure and tooling. Happy building and [happy optimizing](https://github.com/backstage/community-plugins/tree/main/workspaces/cost-insights/plugins/cost-insights).
@@ -10,7 +10,7 @@ authorURL: https://github.com/Rugvip

 ![Animation cycling between stability index scores](assets/2020-12-22/stability-index-hero.gif)

-<!--truncate-->
+{/* truncate */}

 Backstage has a great and growing community of users and contributors. With so much valuable feedback, this inevitably means that sometimes we will go back and revise design decisions that introduce breaking changes. Furthermore, as we continue to ship new features and systems, we’ll continue this cycle of iterating, gathering feedback, and iterating again before reaching a stable API.

@@ -1,6 +1,5 @@
 ---
-# prettier-ignore
-title: "New Backstage feature: Kubernetes for Service owners"
+title: 'New Backstage feature: Kubernetes for Service owners'
 author: Matthew Clarke, Spotify
 authorURL: https://github.com/mclarke47
 ---
@@ -11,7 +10,7 @@ TLDR; We’re rethinking the Kubernetes developer experience with a new feature:

 And since Backstage uses the native Kubernetes API, the feature works with whichever cloud provider (AWS, Azure, GCP, etc.) or managed service (OpenShift, IBM Cloud, GKE, etc.) you already use.

-<!--truncate-->
+{/* truncate */}

 ## The missing link between K8s and your service

@@ -70,4 +69,4 @@ To contribute or get more information on Kubernetes in Backstage, [join the disc

 [here]: https://github.com/backstage/backstage/issues?q=is%3Aissue+is%3Aopen+kubernetes+label%3Ak8s-plugin
 [read the docs]: https://backstage.io/docs/features/kubernetes/overview
-[join the discussion on discord]: https://discord.gg/MUpMjP2
+[join the discussion on discord]: https://discord.gg/backstage-687207715902193673
@@ -8,13 +8,13 @@ authorURL: https://www.linkedin.com/in/austinlamon

 One of the greatest strengths of Backstage also presents a never-ending challenge: Backstage is highly customizable and allows you to easily build a unique developer portal suited to your organization’s needs. The downside of this flexibility is that it can be hard to know where to start. Backstage can do so many things — integrating every part of your tech infrastructure and developer experience — but if you set off building a developer portal without a plan, it’s easy to get overwhelmed by all the possibilities. To help you form your plan, this post will detail how Spotify came to design our internal portal and recommend potential models for you to use when designing and building your own.

-<!--truncate-->
+{/* truncate */}

 ## Infrastructure as tech culture

 Before providing recommendations on getting started with Backstage, it’s helpful to have a bit of context as to why Spotify made the design decisions we did. No two companies are identical — and thus, no two Backstage implementations are the same.

-Rolling back the clock just a few years, [Spotify was challenged](https://engineering.atspotify.com/2021/05/18/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture/) to continue to scale our engineering team (and the number of features and components built) but retain the speed of product development. Some user research with Spotify developers highlighted a clear problem: there was simply too much non-documented institutional knowledge needed to get things done. No one could find anything and everyone was interrupting everyone else trying to figure things out.
+Rolling back the clock just a few years, [Spotify was challenged](https://engineering.atspotify.com/2021/05/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture/) to continue to scale our engineering team (and the number of features and components built) but retain the speed of product development. Some user research with Spotify developers highlighted a clear problem: there was simply too much non-documented institutional knowledge needed to get things done. No one could find anything and everyone was interrupting everyone else trying to figure things out.

 Spotify’s developers were facing three big challenges on a daily basis:

@@ -23,12 +23,14 @@ Spotify’s developers were facing three big challenges on a daily basis:
 - They needed to keep an eye on what squads around them might be building to ensure they could reuse systems when they needed to solve similar problems in the future.

 In short, Spotify developers needed to continue building industry leading features at breakneck speed, while simultaneously maintaining a mental model for all the software at Spotify (oh, and help every new joiner develop that mental model as well!).
-<br>
+
+<br />

 ## Three jobs: Create, manage, explore

 Around the same time, the [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) framework was becoming popular and luckily, a few Spotifiers helped guide the vision for a _sense-making tool for developers_ toward using it. After user research and many failed attempts, we landed on three jobs Spotify developers needed to do consistently:
-<br>
+
+<br />

 - **Create**: Spotify developers want to delight their customers with incredible features. They create new software to do that.
 - **Manage**: Spotify developers are proud of their work and treat their software and data like products. That requires maintaining all the software they own on an ongoing basis.
@@ -73,7 +75,8 @@ Within today’s complex development environments, there are barriers both big a
 After talking with companies who have already adopted Backstage, we’ve seen a few common strategies for getting started. The different strategies are based on the size of your engineering org (which often also corresponds with how fast you’re growing).

 ![200 engineers](assets/21-05-20/200-engineers_v.2.png)
-<br>
+
+<br />

 ### My org has ~200 engineers (and is growing fast)

@@ -7,13 +7,13 @@ authorURL: https://www.linkedin.com/in/austinlamon
 [![The Backstage community is growing! In just over a year, Backstage has gone from a few open source building blocks to a thriving platform used by engineering orgs with thousands of developers. But even with 30+ adopting companies and 400+ contributors, we are still in the very early stages of reaching the platform’s potential.](assets/21-06-22/spotify-backstage-header.gif)](https://backstage.spotify.com/)
 _[backstage.spotify.com](https://backstage.spotify.com)_

-The Backstage community is growing! In just over [a year](https://engineering.atspotify.com/2021/03/16/happy-birthday-backstage-spotifys-biggest-open-source-project-grows-up-fast/), Backstage has gone from a few open source building blocks to a thriving platform used by engineering orgs with thousands of developers. But even with 30+ [adopting companies](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) and 400+ contributors, we are still in the very early stages of reaching the platform’s potential.
+The Backstage community is growing! In just over [a year](https://engineering.atspotify.com/2021/03/happy-birthday-backstage-spotifys-biggest-open-source-project-grows-up-fast/), Backstage has gone from a few open source building blocks to a thriving platform used by engineering orgs with thousands of developers. But even with 30+ [adopting companies](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) and 400+ contributors, we are still in the very early stages of reaching the platform’s potential.

 In order to grow Backstage further, Spotify is increasing the support we provide both adopters (the people integrating Backstage into their organizations) and contributors (the people building features and improving the code). The more companies that adopt Backstage, the more support the project gets, the stronger the platform becomes for everyone.

 And while Spotify remains committed to maturing the Backstage platform — both as original creator and active maintainer — we also want to make room for the community to take greater ownership. Backstage may have started inside Spotify, but it belongs to all of you. So, we hope you join us in what’s next.

-<!--truncate-->
+{/* truncate */}

 ## What’s next: More support for adopters and contributors

@@ -49,13 +49,13 @@ We’ve launched a new website at: [backstage.spotify.com](https://backstage.spo

 You’ll find a high-level introduction to the platform, tips and tricks tested by Spotify to accelerate developer effectiveness, and access to a group of partners that have scaled Backstage for numerous adopters. You can also use the site to book product overviews, demos, and technical deep dives with members of the Spotify team.

-We will continue to post important product announcements, technical documentation, feature demos, and community news here on Backstage.io. ([Subscribe to the newsletter](https://mailchi.mp/spotify/backstage-community) to stay up to date.) And both contributors and adopting companies can continue to find around-the-clock/around-the-world technical support on [GitHub](https://github.com/backstage/backstage) and [Discord](https://discord.gg/MUpMjP2).
+We will continue to post important product announcements, technical documentation, feature demos, and community news here on Backstage.io. ([Subscribe to the newsletter](https://info.backstage.spotify.com/newsletter_subscribe) to stay up to date.) And both contributors and adopting companies can continue to find around-the-clock/around-the-world technical support on [GitHub](https://github.com/backstage/backstage) and [Discord](https://discord.gg/backstage-687207715902193673).

 ## Separate community sessions for adopters and contributors

 [![Backstage Community Sessions, hosted by Spotify](assets/21-06-22/backstage-community-sessions.png)](https://github.com/backstage/community/#backstage-community)

-Earlier this year, we began hosting [Backstage Community Sessions](https://github.com/backstage/community/#backstage-community) — official meetups for anyone who wanted to join them. Since [the very first one](https://youtu.be/4-VX9tDdJYY), the Backstage team has been inspired and humbled by the community’s participation in these sessions — from hearing the [Expedia Group team share their journey adopting Backstage](https://youtu.be/rRphwXeq33Q?t=1509) to discussions about TypeScript and Material-UI. It’s great collaborating through code — but it’s also a lot of fun when you can see each other’s faces and have a conversation.
+Earlier this year, we began hosting [Backstage Community Sessions](https://github.com/backstage/community/#backstage-community) — official meetups for anyone who wanted to join them. Since [the very first one](https://youtu.be/4-VX9tDdJYY), the Backstage team has been inspired and humbled by the community’s participation in these sessions — from hearing the [Expedia Group team share their journey adopting Backstage](https://youtu.be/rRphwXeq33Q?t=1509) to discussions about TypeScript and Material UI. It’s great collaborating through code — but it’s also a lot of fun when you can see each other’s faces and have a conversation.

 And while these sessions have been a success, the feedback we’ve gotten from the community has been very clear: more frequent and more focused conversations. So, later this summer, we’ll be launching standalone Backstage Adopter Sessions and Backstage Contributor Sessions. We hope this will lead to more useful sessions for everyone — and, of course, you are welcome to attend either or both:

@@ -66,9 +66,9 @@ Speaking of reviewers and maintainers…

 ## Adding reviewers and maintainers

-[![GitHub logo](assets/21-06-22/gh-reviewers.png)](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md#reviewers)
+[![GitHub logo](assets/21-06-22/gh-reviewers.png)](https://github.com/backstage/community/blob/main/GOVERNANCE.md#reviewers)

-We have introduced [reviewers](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md#reviewers) to the project! By adding this new role, we’ve expanded the number of people who are permitted to approve and merge pull requests. This will offload some of the review work from the maintainers, simplifying and speeding up the review process for contributors.
+We have introduced [reviewers](https://github.com/backstage/community/blob/main/GOVERNANCE.md#reviewers) to the project! By adding this new role, we’ve expanded the number of people who are permitted to approve and merge pull requests. This will offload some of the review work from the maintainers, simplifying and speeding up the review process for contributors.

 Of course, with these new efforts, we expect even more companies to adopt Backstage, which means the platform will continue to grow, and the number of PRs will continue to grow with it. As that happens, we hope to add to both the maintainer and reviewer teams in the future.

@@ -1,6 +1,5 @@
 ---
-# prettier-ignore
-title: "Announcing the Backstage Search platform: a customizable search tool built just for you"
+title: 'Announcing the Backstage Search platform: a customizable search tool built just for you'
 author: Emma Indal, Spotify
 authorURL: https://www.linkedin.com/in/emma-indal
 ---
@@ -13,7 +12,7 @@ So, you don’t just get an improved out-of-the-box experience for searching wha

 With one query, your teams can find exactly what they’re looking for: anything and everything.

-<!--truncate-->
+{/* truncate */}

 ## Search and explore

@@ -80,9 +79,9 @@ That's why we have put effort into making your search page experience composable

 A good example of the level of customization the platform allows is how list items are displayed in search results. A search result component can be a list, this list can consist of different list items (search results returned from the search engine) — but these list items could look different depending on what the search result returns in terms of its fields.

-Let’s say that for an entity returned from the software catalog maybe the most important information to show is the name, while a result returned from the TechDocs plugin should maybe show the text content as the most important information. This can be customized by creating <CustomResultListItem /> components (like TechDocsResultListItem or CatalogResultListItem or whatever list item component you want) and configuring them in the app.
+Let’s say that for an entity returned from the software catalog maybe the most important information to show is the name, while a result returned from the TechDocs plugin should maybe show the text content as the most important information. This can be customized by creating `<CustomResultListItem />` components (like `TechDocsResultListItem` or `CatalogResultListItem` or whatever list item component you want) and configuring them in the app.

-If there is no need to customize your search result list items, the <DefaultResultListItem /> component is there for you to reuse.
+If there is no need to customize your search result list items, the `<DefaultResultListItem />` component is there for you to reuse.

 ## Getting started with Backstage Search

@@ -97,6 +96,6 @@ Whichever situation you’re in, we have you covered.

 We’ve built the foundation for the Backstage Search platform, and we can't wait to see the exciting engines, collators, and components the community builds on the platform.

-You can check out our [project roadmap](https://backstage.io/docs/features/search/search-overview#project-roadmap) in our search documentation or track the progress of our [Beta milestone](https://github.com/backstage/backstage/milestone/27) and [GA milestone](https://github.com/backstage/backstage/milestone/28).
+You can check out our [project roadmap](https://backstage.io/docs/features/search/#project-roadmap) in our search documentation or track the progress of our [Beta milestone](https://github.com/backstage/backstage/milestone/27) and [GA milestone](https://github.com/backstage/backstage/milestone/28).

-For any questions, feedback or ideas about the Backstage Search platform, join us in the #search channel on [Discord](https://discord.gg/MUpMjP2)!
+For any questions, feedback or ideas about the Backstage Search platform, join us in the #search channel on [Discord](https://discord.gg/backstage-687207715902193673)!
@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4

 **TLDR**; At a high level, Backstage performs three main jobs: [Create, Manage, and Explore](https://backstage.io/blog/2021/05/20/adopting-backstage#three-jobs-create-manage-explore). Throughout the year, we’ve been focussed on improving the stability and scalability of these areas while enhancing the feature sets based upon requests from the community. Software Templates — which enable push-button deployments with all your standards and best practices built-in — is our first feature-complete release candidate to graduate to beta. Read on to learn how this release improves template customization and flexibility, as well as performance.

-<!--truncate-->
+{/* truncate */}

 Let’s rewind a little bit, around a year in fact. Backstage had been open sourced, and we released our first version of Software Templates and our Scaffolder plugin.

@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4

 **TLDR:** Another beta has landed! We continue to focus on improving the stability and scalability of Backstage while enhancing its functionality. Thanks to focused efforts from the TechDocs core team and community, we're happy to say that TechDocs — [our docs-like-code solution](https://backstage.io/blog/2020/09/08/announcing-tech-docs) for all the software in your catalog — is now, after [Software Templates](https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta), the second core feature to graduate to beta.

-<!--truncate-->
+{/* truncate */}

 In addition to new features and improvements, we made numerous compatibility updates ahead of this feature release. You'll find support for a variety of CI systems, cloud storage solutions, and source control systems — so that TechDocs works for most orgs, right out of box. But there's much more to explore in this beta, thanks to contributions from the community.

@@ -21,9 +21,10 @@ When we set out to define what beta looked like, we combed through GitHub issues

 TechDocs can be transformational once fully up and running (update your code and your docs with the same pull request!). But for first-time users and especially those unfamiliar with the MkDocs ecosystem upon which TechDocs is built, there are often many small, obtuse hurdles that can get in the way of success. Leading up to the beta release, we worked to surface and improve relevant errors and other details during the documentation generation process. Better still, all of this detail is now provided to users _in real-time_, as docs are generated and refreshed.

-<!-- vale off -->
-<p>🙌 Shout out to <a href="https://github.com/dhenneke">Dominik Henneke</a> for implementing the interactive experience.</p>
-<!-- vale on -->
+<p>
+  🙌 Shout out to <a href="https://github.com/dhenneke">Dominik Henneke</a> for
+  implementing the interactive experience.
+</p>

 ## Custom homepages: Make TechDocs yours

@@ -31,9 +32,10 @@ TechDocs can be transformational once fully up and running (update your code and

 We strive to make it so that you can mold Backstage into the shape that best fits your organization. With this beta release, just as you can with the Catalog entities and [Search](https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform#composable-search-page-experiences), you can now customize and compose your own TechDocs homepage. Use it to level up the front page of your Backstage documentation by highlighting golden documentation at your company, or use the new and improved (and Catalog-inspired) experience. Read more about [how to customize the TechDocs homepage](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-customize-the-techdocs-home-page).

-<!-- vale off -->
-<p>🙏 Thanks to <a href="https://github.com/kuangp">Phil Kuang</a> for the improved default TechDocs home experience.</p>
-<!-- vale on -->
+<p>
+  🙏 Thanks to <a href="https://github.com/kuangp">Phil Kuang</a> for the
+  improved default TechDocs home experience.
+</p>

 ## Simpler YAML annotations: What's in a ref?

@@ -43,9 +45,9 @@ We often forget that in order to enable TechDocs on a Catalog entity, documentat

 In the beta, we've simplified this annotation dramatically for documentation authors, aligning its value with TechDocs' docs-like-code philosophy itself. In the vast majority of cases, its value will simply be `dir:.` — which means this catalog entity contains documentation and the mkdocs.yml file describing this documentation lives in the current directory. We continue to support edge cases for [other techdocs-ref annotation values](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-understand-techdocs-ref-annotation-values), as well.

-<!-- vale off -->
-<p>👏 Another round of applause for Dominik for driving this improvement through.</p>
-<!-- vale on -->
+<p>
+  👏 Another round of applause for Dominik for driving this improvement through.
+</p>

 ## Everything neat and tidy

@@ -67,4 +69,4 @@ If you're upgrading from a prior, alpha version of TechDocs, be aware that there
 - If you've configured TechDocs to publish generated content to a remote storage solution provider like AWS S3, Google Cloud Storage, or Azure Blob Storage, you will need to use the TechDocs CLI to migrate the contents of your storage bucket. [See full migration instructions here](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-migrate-from-techdocs-alpha-to-beta).
 - In order to take advantage of the stale file deletion functionality, you may need to add some permissions to the account or role used by your TechDocs backend to publish contents to your storage provider. [See "Using Cloud Storage docs"](https://backstage.io/docs/features/techdocs/using-cloud-storage) for updated permissions recommendations.

-Thanks again to the whole community for hitting this milestone with us! Catch us in [Discord](https://discord.gg/MUpMjP2) or an [upcoming community session](https://github.com/backstage/community) if you have any questions.
+Thanks again to the whole community for hitting this milestone with us! Catch us in [Discord](https://discord.gg/backstage-687207715902193673) or an [upcoming community session](https://github.com/backstage/community) if you have any questions.
@@ -11,7 +11,7 @@ We’re excited to celebrate an important milestone for the Backstage community:

 Before digging into why we believe this is so important, we want to send a huge “thank you” to all the Backstage adopters and contributors who have helped grow the Backstage community. First, to the publicly listed adopters as your visible support for the project excites others to learn more about Backstage. Second, to those non-listed adopters, many of whom still engage in the community via issues, comments, or code contributions. Thank you!

-<!--truncate-->
+{/* truncate */}

 ## Why we care about public adopters

@@ -41,5 +41,5 @@ If you are a Backstage enthusiast, please [join me][news] and the entire Backsta
 [da]: https://medium.com/dazn-tech/developer-experience-dx-at-dazn-e6de9a0208d2
 [ex]: https://backstage.spotify.com/blog/community-session/firehydrant-expedia-loblaw/
 [plugins]: https://backstage.io/plugins
-[news]: https://mailchi.mp/spotify/backstage-community
+[news]: https://info.backstage.spotify.com/newsletter_subscribe
 [gh]: https://github.com/backstage/backstage/blob/master/ADOPTERS.md
@@ -15,7 +15,7 @@ In 2021 we’ve seen the project and community grow in every dimension, reaching

 Now let’s hear from the maintainers and look at the stats!

-<!--truncate-->
+{/* truncate */}

 ## The community grew…and grew

@@ -48,11 +48,25 @@ Along with the growth in contributors, PRs, and issues, our active, thriving com

 Watch the visualization below to see where in the world all those contributions came from this past year.

-<iframe width="780" height="440" src="https://www.youtube.com/embed/O1xtDv_XDt4" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/O1xtDv_XDt4"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>

 ### What does 9,000 contributions look like?

-<iframe width="780" height="440" src="https://www.youtube.com/embed/bCqhoK7it2g" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/bCqhoK7it2g"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>

 Can you spot your name in the video above?

@@ -11,7 +11,7 @@ _This blog post is co-authored by Emma Indal ([@emmaindal](https://github.com/em

 _TLDR;_ We’re excited to announce the arrival of homepage templates for Backstage. It can be intimidating to build up your own instance of Backstage, so we decided to make your life a bit easier by giving you an out-of-the-box homepage to hit the ground running. This template can be found in our [Backstage Storybook](https://backstage.io/storybook/?path=/story/plugins-home-templates--default-template), as well as future templates that we build.

-<!--truncate-->
+{/* truncate */}

 ## Why homepage templates?

@@ -9,11 +9,11 @@ authorImageURL: https://avatars.githubusercontent.com/u/8433119?v=4

 _TLDR;_ The Spotify team recently announced [Backstage Upgrade Helper](https://backstage.github.io/upgrade-helper): a tool that helps adopters keep their Backstage application up-to-date. **Spoiler alert**: this is also a hidden and heartwarming tale about the beauty of open source innovation.

-<!--truncate-->
+{/* truncate */}

 ## Upgrading Backstage was a common pain point

-Without a doubt, one of the most exciting things about Backstage is our community. Step into our daily [Discord conversations](https://discord.gg/sBEF5VkG) and the monthly [Community Sessions](https://www.youtube.com/watch?v=0QMQYSTKAx0) and you’ll find a ton of great ideas, problem-solving, and support for one another.
+Without a doubt, one of the most exciting things about Backstage is our community. Step into our daily [Discord conversations](https://discord.gg/backstage-687207715902193673) and the monthly [Community Sessions](https://www.youtube.com/watch?v=0QMQYSTKAx0) and you’ll find a ton of great ideas, problem-solving, and support for one another.

 During one of these discussions, we realized we all shared the same pain point — upgrading a Backstage application.

@@ -29,7 +29,7 @@ We started by creating a fork from React Native’s open source project, applyin

 The Backstage Upgrade Helper tool enables adopters to easily upgrade their Backstage app by using the power of git to create a diff between different versions.

-Whenever a new version of Backstage is released, the Helper scaffolds a new dummy Backstage app using the `backstage-create-app` cli utility and checks all the generated files in a specific git branch. After the branch is generated, it gets compared with all the existing ones, which results in generating specific git patches stored in specific files. By selecting the version of the current Backstage release together with the version you want to upgrade to, the UI knows which patch file needs to be picked up.
+Whenever a new version of Backstage is released, the Helper scaffolds a new sample Backstage app using the `backstage-create-app` cli utility and checks all the generated files in a specific git branch. After the branch is generated, it gets compared with all the existing ones, which results in generating specific git patches stored in specific files. By selecting the version of the current Backstage release together with the version you want to upgrade to, the UI knows which patch file needs to be picked up.

 So, now you can update your Backstage application in three steps rather than manually reading the changelogs of all the Backstage modules in reverse order.

@@ -9,7 +9,7 @@ authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4

 **TLDR:** Backstage has turned two. Of course, this is software, so we expect things to move fast. But when you have a passionate, worldwide community building together, we’ve now seen firsthand just how fast that can be. We’re marking our second year as a community by becoming a CNCF incubating project, reaching 100 public adopters, releasing version 1.0 of the core app, and other very nice birthday gifts. Rather than a toddler finding their feet, Backstage today is beginning to look awfully grown-up for a two-year-old.

-<!--truncate-->
+{/* truncate */}

 ## Out of the Sandbox and into Incubation

@@ -49,7 +49,14 @@ The Backstage community is truly global with adopters and contributors from almo

 We asked a few contributors and maintainers to share their thoughts around this two-year milestone.

-<iframe width="780" height="440" src="https://www.youtube.com/embed/-j-waaybcH0" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/-j-waaybcH0"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>

 Warms the heart, doesn’t it? Thanks again to all our contributors for making this possible. Seriously. We’re proud of what the community has accomplished and how we’ve accomplished it. All along, it’s your enthusiasm and warm/collaborative/positive vibes that have carried us and this project through.

@@ -1,6 +1,5 @@
 ---
-# prettier-ignore
-title: "New release: Backstage 1.0"
+title: 'New release: Backstage 1.0'
 author: Francesco Corti, Spotify
 authorURL: https://github.com/fcorti/
 authorImageURL: https://avatars.githubusercontent.com/u/6010860?v=4
@@ -10,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/6010860?v=4

 _TL;DR:_ If you’ve been waiting for Backstage to come out of beta, we’re excited to announce that Backstage 1.0 is here!

-<!--truncate-->
+{/* truncate */}

 It’s been two years since Spotify [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage) so companies of all shapes and sizes — and in every industry all over the world — could build highly extensible and customized developer portals to best suit their organization’s needs and culture. Now hundreds of adopters are using Backstage as the single pane of glass for their core development, managing millions of components and technical documentation, and helping hundreds of thousands of developers be more productive and happy.

@@ -25,11 +24,11 @@ To start, let’s define Backstage: it’s an open platform for building develop
 Our definition of Backstage 1.0 includes:

 - Backstage Core 1.0 libraries as the set of libraries to make the platform work
- [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview) 1.0
- [Backstage Software Templates](https://backstage.io/docs/features/software-templates/software-templates-index) 1.0
- [Backstage TechDocs](https://backstage.io/docs/features/techdocs/techdocs-overview) 1.0
+- [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/) 1.0
+- [Backstage Software Templates](https://backstage.io/docs/features/software-templates/) 1.0
+- [Backstage TechDocs](https://backstage.io/docs/features/techdocs/) 1.0

-Coming soon: [Backstage Search](https://backstage.io/docs/features/search/search-overview) 1.0 will be included in the near future as part of the regular releases to the Backstage platform.
+Coming soon: [Backstage Search](https://backstage.io/docs/features/search/) 1.0 will be included in the near future as part of the regular releases to the Backstage platform.

 In terms of features, the maintainers will not be shipping new stuff as part of the major release but instead:

@@ -54,6 +53,6 @@ If you want to know more about this first major release, check out the following

 - [Release notes](https://backstage.io/docs/releases/v1.0.0) and [Changelog](https://github.com/backstage/backstage/releases/tag/v1.0.0).
 - [Backstage official documentation](https://backstage.io/docs/) and [backstage.spotify.com](https://backstage.spotify.com/).
- [Discord channel](https://discord.gg/EUaBAS58).
+- [Discord channel](https://discord.gg/backstage-687207715902193673).
 - [Backstage repository on GitHub](https://github.com/backstage/backstage).
 - [List of public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md).
@@ -1,6 +1,5 @@
 ---
-# prettier-ignore
-title: "Introducing the TechDocs Addon Framework"
+title: 'Introducing the TechDocs Addon Framework'
 author: Gary Niemen, Spotify
 authorURL: https://github.com/garyniemen/
 authorImageURL: https://avatars.githubusercontent.com/u/65337273?v=4
@@ -12,9 +11,9 @@ _This blog post is co-authored by Eric Peterson ([@iamEAP](https://github.com/ia

 _TL;DR:_ Introducing the TechDocs Addon Framework — a way for us all to contribute and share additional features, TechDocs Addons, on top of the base docs-like-code experience.

-<!--truncate-->
+{/* truncate */}

-[TechDocs](https://backstage.io/docs/features/techdocs/techdocs-overview) is a centralized platform for publishing, viewing, and discovering technical documentation across an entire organization. It's a solid foundation! But TechDocs doesn't solve higher order documentation needs on its own such as: How do you create and reinforce a culture of documentation? How do you build trust in the quality of technical documentation?
+[TechDocs](https://backstage.io/docs/features/techdocs/) is a centralized platform for publishing, viewing, and discovering technical documentation across an entire organization. It's a solid foundation! But TechDocs doesn't solve higher order documentation needs on its own such as: How do you create and reinforce a culture of documentation? How do you build trust in the quality of technical documentation?

 To address this need, we’re proud to introduce the [TechDocs Addon Framework](https://github.com/backstage/backstage/issues/9636) — a way for us all to contribute and share additional features, TechDocs Addons, on top of the base docs-like-code experience. Using TechDocs Addons, you can customize the TechDocs experience to address some of these higher order needs.

@@ -1,11 +1,10 @@
 ---
-# prettier-ignore
-title: Releasing Backstage Search 1.0 
+title: Releasing Backstage Search 1.0
 author: Emma Indal, Spotify
 authorURL: https://www.linkedin.com/in/emma-indal
 ---

-**TL;DR** If you’ve been waiting for Backstage Search to come out of beta, we’re excited to announce that [Backstage Search 1.0](https://backstage.io/docs/features/search/search-overview#backstage-search-10) is here!
+**TL;DR** If you’ve been waiting for Backstage Search to come out of beta, we’re excited to announce that [Backstage Search 1.0](https://backstage.io/docs/features/search/#backstage-search-10) is here!

 We first released the Backstage Search Platform over a year ago. Backstage Search Platform is a search experience built for you, by you.

@@ -13,7 +12,7 @@ We first released the Backstage Search Platform over a year ago. Backstage Searc

 Backstage Search Platform makes it possible for you to search across your entire software ecosystem. With a Search platform that is customizable and extendable, you can identify your needs within your organization and set up search to solve these problems. Whether it is to search through the Software Catalog or technical documentation generated by the TechDocs plugin.

-<!--truncate-->
+{/* truncate */}

 ## So what is Backstage Search 1.0?

@@ -0,0 +1,40 @@
+---
+title: Backstage Security Audit & Updates
+author: Patrik Oldsberg, Spotify
+authorURL: https://github.com/Rugvip
+---
+
+**TL;DR** Backstage’s security posture continues to mature! Today, we’re releasing a report from an independent security audit and the first version of the Backstage Threat Model.
+
+![Backstage Security Audit & Updates](assets/22-08-23/backstage-security-audit.png)
+
+As an [Incubating project](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/) within the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/), Backstage was fortunate enough to take advantage of a sponsored security audit. The [Open Source Technology Improvement Fund (OSTIF)](https://ostif.org/) sponsored the audit as part of its ongoing efforts to secure the open source software ecosystem, and the audit itself was performed by [X41 D-Sec](https://x41-dsec.de/). Our goal with the audit was to evaluate and improve Backstage’s security posture, focusing on the core Backstage framework and plugins.
+
+{/* truncate */}
+
+## Report Findings and Fixes
+
+The security audit and improvements concluded earlier this month, on August 18th. The audit **findings** totalled two critical, two high, five medium, and three low severity vulnerabilities, alongside 15 side findings with no direct security impact. As of the [Backstage 1.5 release](https://backstage.io/docs/releases/v1.5.0), eight out of the 12 main findings and many of the side findings are fully remedied. If you are a few versions behind there’s no need to worry though, most fixes were included in the 1.3 release.
+
+Out of the four findings that have yet to be fixed, three are related to rate limiting or internal DoS concerns. With the introduction of the Backstage Threat Model (more on that below), Backstage’s positioning states that this is outside the scope of the security concerns of Backstage. Rather, we trust internal users of Backstage to not intentionally sabotage the availability of the service. This is not to say that we will never aim to get these findings addressed, but we have pushed them to be potential future improvements as we focus our near-term efforts on improving the product in other ways.
+
+The last outstanding finding is to build out the capabilities of our service-to-service auth system. This is an area where the audit identified a couple of missing pieces in our early version of the implementation. We have since closed the gap by introducing token expiration, and will continue to work on this as we open up for more complex and hardened deployment patterns through the [evolution of the backend system](https://github.com/backstage/backstage/issues/11611).
+
+Another important finding was the potential for confusion and user impersonation due to most authentication providers having sign-in enabled by default. This finding reinforced our decision to switch sign-in to being disabled by default for all authentication providers, which was part of the [1.1 release](https://backstage.io/docs/releases/v1.1.0).
+
+Perhaps the most important outcome of this audit is that it helped us focus our efforts to keep improving the security of Backstage. It identified priority areas in both implementation and documentation for us going forward. One particular area that was pointed out in a finding is the documentation around the security model of Backstage deployment. There have been several efforts to highlight this in documentation, but it is still not clear enough. What we’ve been lacking is documentation that is completely dedicated towards detailing the security concerns of Backstage. That is why in addition to publishing the security audit report, we are also introducing the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model).
+
+## Introducing the Backstage Threat Model
+
+The existing Backstage documentation has many security concerns interwoven within its text, but to find them all, you need to spend a lot of time reading. We previously lacked a one-stop-shop for readers that are interested in the security model and concerns of Backstage. So, we are happy to introduce the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model), which closes this gap. The Threat Model outlines key security considerations for operators, developers, and security researchers. It is a living document that will evolve and expand alongside the Backstage project.
+
+The threat model document covers the trust model and roles involved in a typical Backstage setup, the responsibilities that fall on integrators of Backstage, and common configuration concerns across all Backstage projects. Beyond these three topics, it also dives deeper into a number of core features. The `auth`, `catalog`, `scaffolder`, and `techdocs` plugins are all covered separately with their individual security concerns.
+
+We’d like to point out a few key parts in case you are in a rush. Be sure to familiarize yourself with the integrator's responsibility to protect the Backstage installation from unauthorized access. If you ingest organizational data into the catalog and use that to sign in users, you’ll also want to check out the first halves of the authentication and catalog sections.
+
+## Links and References
+
+- [Full Audit Report](assets/22-08-23/X41-Backstage-Audit-2022.pdf)
+- [Backstage Security Policy](https://github.com/backstage/backstage/blob/master/SECURITY.md)
+
+On behalf of the Backstage maintainers and community: thanks to the CNCF, OSTIF, and X41 D-Sec for the opportunity to improve the project.
@@ -0,0 +1,91 @@
+---
+title: FYI 📣 The Plugin Analytics API
+author: Eric Peterson, Spotify
+authorURL: https://github.com/iamEAP
+authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4
+---
+
+**TL;DR** If you didn't know, now you know: the Backstage plugin analytics API is here to help you understand how developers in your organization are using Backstage.
+
+![The Plugin Analytics API](assets/22-09-08/analytics-api-fyi.png)
+
+{/* truncate */}
+
+## What is the plugin analytics API?
+
+The plugin analytics API is a [utility api](https://backstage.io/docs/api/utility-apis) available by default in every Backstage instance, intended to bridge the gap between the needs of Backstage integrators and plugin developers. While Backstage integrators want visibility into the plugins they’ve installed, they lack the power to instrument those plugins. And although plugin developers have the power to instrument plugins, they can’t do so without a single, vendor-agnostic way to track events. Enter: the plugin analytics API.
+
+While “analytics” as a concept can be broad, the goal of the API is narrowly focused: empower those deploying Backstage to understand usage of their instance. The plugin analytics API isn’t designed to solve for observability use-cases like tracing, logging, performance monitoring, error metrics, or alerting. Rather, the API is designed to capture and quantify real user interactions, which can form the basis for metrics like daily active users, top plugins, and more.
+
+## Start collecting data
+
+Backstage core (and a few other plugins) are already instrumented with [key events](https://backstage.io/docs/plugins/analytics#key-events) that are ready for you to start collecting and analyzing.
+
+The simplest way to get started is to use one of the [supported analytics tools](https://backstage.io/docs/plugins/analytics#supported-analytics-tools) and install its provided API implementation like you would any other utility API. For example:
+
+```tsx
+// packages/app/src/apis.ts
+import {
+  analyticsApiRef,
+  configApiRef,
+  identityApiRef,
+} from '@backstage/core-plugin-api';
+import { GoogleAnalytics } from '@backstage/plugin-analytics-module-ga';
+
+export const apis: AnyApiFactory[] = [
+  // Instantiate and register the GA Analytics API Implementation.
+  createApiFactory({
+    api: analyticsApiRef,
+    deps: { configApi: configApiRef, identityApi: identityApiRef },
+    factory: ({ configApi, identityApi }) =>
+      GoogleAnalytics.fromConfig(configApi, {
+        identityApi,
+      }),
+  }),
+];
+```
+
+If your chosen analytics tool doesn’t have an integration yet, you can write a custom integration by [following these instructions](https://backstage.io/docs/plugins/analytics#writing-integrations). (And if you’re integrating with a publicly available analytics service, as opposed to a custom in-house system, why not [consider contributing it back to the community](https://backstage.io/docs/plugins/create-a-plugin)?)
+
+## Instrument plugins
+
+While some key events are already instrumented, there may be important actions in open source plugins that are un-instrumented, not to mention in your custom, InnerSource plugins. Luckily, the plugin analytics API can be leveraged by open source and InnerSource plugins all the same.
+
+To capture an event, invoke the `useAnalytics()` react hook and call the function it returns when the user performs the action you wish to track (e.g. merging a pull request):
+
+```tsx
+import { useAnalytics } from '@backstage/core-plugin-api';
+
+const analytics = useAnalytics();
+analytics.captureEvent('merge', pullRequestName);
+```
+
+Don’t worry about having to stuff additional levels of detail into just the event action and subject, you can provide extra dimensional data on the `attributes` property, as well as a primary metric on the `value` property, like this:
+
+```tsx
+analytics.captureEvent('merge', pullRequestName, {
+  value: pullRequestAgeInMinutes,
+  attributes: {
+    org: orgName,
+    repo: repoName,
+  },
+});
+```
+
+In situations where your plugin is tracking multiple events and you want all of those events to share common dimensional data, you can use the `<AnalyticsContext>`. Every event captured in child components underneath this context automatically inherits the values you set:
+
+```tsx
+import { AnalyticsContext } from '@backstage/core-plugin-api';
+
+<AnalyticsContext attributes={{ vcsProvider: 'github' }}>
+  {children}
+</AnalyticsContext
+```
+
+In fact, Backstage core uses an `<AnalyticsContext>` to automatically decorate every event with a corresponding plugin ID and an extension name in order to facilitate plugin-level analysis.
+
+While the above should be enough to get you going, don’t forget to check out [the complete guide to event capture](https://backstage.io/docs/plugins/analytics#capturing-events), which covers event naming considerations, testing, and more.
+
+## Get involved
+
+If you didn’t know, now you know! If you’re passionate about data and want to help push the Backstage analytics ecosystem forward, join us in the [#analytics channel on discord](https://discord.com/channels/687207715902193673/1007303347914690610), contribute [integration ideas](https://github.com/backstage/backstage/issues/new?assignees=&labels=plugin&template=plugin_template.md&title=%5BAnalytics+Module%5D+THE+ANALYTICS+TOOL+TO+INTEGRATE), or [suggest a new analytics event](https://github.com/backstage/backstage/issues/new?assignees=&labels=enhancement&template=feature_template.md&title=[Analytics%20Event]:%20THE+EVENT+TO+CAPTURE).
@@ -0,0 +1,38 @@
+---
+title: 'ICYMI: BackstageCon & KubeCon NA 2022 Recap'
+description: 'We had a great time in Detroit! Learn more about our first dedicated conference to Backstage and KubeCon NA 2022.'
+author: Emma White, Spotify
+authorURL: https://www.linkedin.com/in/emmamckeewhite/
+---
+
+## ICYMI: BackstageCon & KubeCon NA 2022 Recap
+
+![blog header image](assets/2022-10-28/preview.png)
+
+What an action-packed and memorable week for the Backstage community meeting up IRL at KubeCon North America 2022 in (unseasonably warm and sunny) Detroit. Let’s see what the community was up to:
+
+{/* truncate */}
+
+### BackstageCon: A full day of nothing but Backstage
+
+![BackstageCon group](assets/2022-10-28/groupimage.jpg)
+
+We started the week off strong, packing a ballroom for [BackstageCon](https://events.linuxfoundation.org/backstagecon-north-america/) on Monday. It was a smorgasbord of some of our active community members at the first official Backstage conference — as well as some new faces interested in learning more about Backstage! To welcome us, Roadie’s [Martina Iglesias Fernandez](https://github.com/martina-if) and Spotify’s [Suzanne Daniels](https://github.com/suuus) took center stage. Next up, we listened to three keynotes from the event’s top sponsors: Roadie’s [David Tuite](https://github.com/dtuite) enlightened us on how to 10x developer effectiveness for teams, [Dave Zolotusky](https://github.com/dzolotusky) from Spotify discussed developer happiness and [announced](https://www.linkedin.com/posts/spotify-r%26d_backstage-devex-activity-6990305201710587904-SnDQ?utm_source=share&utm_medium=member_desktop) that [Spotify Plugins for Backstage](https://backstage.spotify.com/blog/spotify-plugins-for-backstage/) are launching soon, and [Valentina Alaria](https://www.linkedin.com/in/valentinaalaria/) from VMware Tanzu talked about how to curate the Backstage experience to enable developer velocity. In between some creative snacks (lemon blueberry popcorn, anyone?) and coffee breaks, we heard from adopters including [Telus](https://backstage.spotify.com/blog/building-for-simplicity-TELUS/), [DAZN](https://backstage.spotify.com/blog/adopter-spotlight/dazn/), HP, US Bank, and more on lessons learned through their adoption journeys, we talked about different ways to leverage data within Backstage, and we discussed new ways to customize Backstage for specific adopter needs.
+
+You can watch all the BackstageCon sessions, talks, and keynotes [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf)!
+
+### Project Meeting: Building a better Backstage together
+
+![project meeting image](assets/2022-10-28/real_project_meeting.jpeg)
+
+The following day, the Backstage maintainers hosted a lively project meeting, where we engaged with a lot of folks that had been at BackstageCon the day before. Over the course of the meeting, the Backstage community talked through recommended approaches for maintaining your Software Catalog as a source of truth, sourcing internal contributors for organization’s Backstage apps, improving frontend performance in a few plugins, how Backstage maintainers work, and appreciation for the contributions from our community. You can read more detailed notes from the project meeting in the repo [here](https://github.com/backstage/community/blob/main/project-meetings/kubecon-na-2022.md).
+
+### KubeCon: Demos, swag, and standing-room only
+
+And last but not least: three days of [KubeCon North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)! At KubeCon, the Backstage team met and greeted so many new faces at our kiosk in the Project Pavilion. We ran demos, answered questions, and handed out lots and lots of SWAG!
+
+![maintainer presentation](assets/2022-10-28/project_meeting.jpg)
+
+Spotify’s [Francesco Corti](https://github.com/fcorti) and core maintainer [Ben Lambert](https://github.com/benjdlambert) took the stage on Wednesday to present the Backstage maintainer talk to a PACKED audience. They discussed how core features of Backstage are changing the way end-user developers interact and manage their ecosystem, and encouraged folks to create the future of developer experience with the rest of the Backstage community. If you missed it, no worries! Their talk track will be posted on the [CNCF YouTube channel](https://www.youtube.com/c/cloudnativefdn).
+
+…and that’s a wrap! What an incredible week. Our growing Backstage community continues to amaze us with its dedication and enthusiasm. We can’t wait to see you all again at KubeCon Europe in The Netherlands! In fact, we’d love to see our adopters give Backstage talks next year (hint, hint). The KubeCon Europe [CFP is open](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/#overview) until Friday, November 18, 2022.
@@ -0,0 +1,16 @@
+---
+title: The Linux Foundation launches its Introduction to Backstage course
+description: The new Linux Foundation course is available for free on edX and is designed to help individuals understand how to map Backstage to their organization needs
+author: Jorge Lainfiesta, Roadie
+authorURL: https://www.linkedin.com/in/jrlainfiesta/
+---
+
+Backstage continues to grow in [popularity and maturity](https://roadie.io/blog/backstage-consolidating-its-role-in-the-cloud-native-ecosystem/), with industry leaders not only adopting the framework but actively participating in the community through contributions and commercial offerings. One of the most recent contributions comes from the Linux Foundation, [launching an introductory course](https://training.linuxfoundation.org/blog/23107/) aimed at DevOps engineers or professionals working on Developer Productivity or Developer Experience. The course is available for free on edX, with a paid option for the certified track.
+
+[![Introduction to Backstage: Developer Portals Made Easy (LFS142x): Enroll!](assets/22-11-15/Introduction-to-Backstage-Developer-Portals-Made-Easy-2-768x432.png)](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy)
+
+{/* truncate */}
+
+The course, [Introduction to Backstage: Developer Portals Made Easy (LFS142x)](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy), starts discussing the benefits of adopting a Developer Portal. Then, it dives into what is Backstage, its main features (Catalog, Scaffolder, TechDocs), and how to map its capabilities to your organization. At last, it provides tips on how to connect with the community to ease up your adoption journey.
+
+The course author, [Jorge Lainfiesta](https://www.linkedin.com/in/jrlainfiesta/), is a Technical Marketing Manager at [Roadie](https://roadie.io). Jorge has a background in software engineering (PayPal) and digital communication (UCLA). He’s been working around Backstage since it was open sourced by Spotify and co-hosts community initiatives like the Backstage Users Unconference.
@@ -0,0 +1,86 @@
+---
+title: Backstage Wrapped 2022
+author: Francesco Corti & Suzanne Daniels
+authorURL: https://github.com/fcorti
+---
+
+![wrapped header image](assets/2022-12-19/wrapped.png)
+
+If 2021 was the year of growth for the Backstage project and community, 2022 can be easily defined as the year of maturity. Both the project and the community continued to grow at an incredible pace and the platform is now more stable, more secure, and more powerful than ever.
+
+Our community is full of people from across the globe who bring incredible engagement and positive vibes to the project. And we finally got to experience this for the first time in real life during [BackstageCon](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf), the very first in-person conference fully dedicated to Backstage, where hundreds of enthusiasts, the maintainers, adopters, and partners joined the event confirming the great momentum and the traction in the market.
+
+But before anticipating too much, let’s share some stats of this amazing 2022.
+
+{/* truncate */}
+
+## We grew … a lot!
+
+Last year we celebrated 75 [public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) and today we have over 600 adopters, confirming the interest around Backstage across all the industries, sectors, and dimensions. Companies like [Toyota North America](https://aws.amazon.com/solutions/case-studies/toyota-ecs-case-study/), Deutsche Bank, Mercedes-Benz, Procter & Gamble, Siemens, LinkedIn, and many more joined the community this year and are actively contributing in growing the product and its maturity.
+
+![Accelerated growth of Public Backstage Adopters, from January 2021–December 2022.](assets/2022-12-19/public-backstage-adopters-2022.png)
+
+Not only are our adopters growing at an exponential rate, but so too are our contributors. Our [Discord server](https://discord.gg/backstage-687207715902193673) is a perfect example of the worlds of our adopters and contributors melding. On average, at any given hour of the day or night, there are more than 500 people online available to talk and provide support on any Backstage topic. Discord discussions run a full gamut of topics – from technical support questions to best practices for onboarding engineers to Backstage – basically, anything and everything an adopter may be interested to know and learn. At the very beginning of 2022, we “only” had 4k Discord members. Today, we have a growing membership of 8.2k.
+
+Isn’t it what we can call a great and vibrant community of enthusiasts?
+
+The growth of the ecosystem is not limited to the adopters and contributors. The ecosystem also includes big tech companies interested in growing Backstage by including it as part of their offering and integrations. Our [collaboration with VMWare](https://youtube.com/watch?v=GAzKCQO8Vt0&si=EnSIkaIECMiOmarE) is a great example of this, and [RedHat](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) joined the party this year – promising even faster growth in contributions and integrations for the Backstage project.
+
+Before we go any further, let’s take a quick look at some more numbers, mainly coming from the [Official Github repository](https://github.com/backstage/backstage). This year…
+
+- Our contributors grew from a group of 500 to 900+
+- Contributions to the project increased from 9k to 15k+
+- The number of forks shot up from 2k to 3k+
+- Backstage stars increased from 14k to almost 20k
+- And lastly, we welcomed over 550 adopters into our community.
+
+All of these people driving the enormous growth and maturity of the project are represented in the chart below, which shows cumulative activities per month for Backstage:
+
+![Main Github metrics for Backstage.io.](assets/2022-12-19/github-metrics-for-backstage-io.png)
+
+Wow… that’s a lot of activity. We’ve generated this animation showing all of your contributions to the Backstage repository in 2022, look at this project grow:
+
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/GoWBvHpH5Cg"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+## But wait… there’s more
+
+The growth of the community is so exciting to see. And with all this community growth, comes growth and maturity of the product, making Backstage better able to support adopters in their developer experience challenges. The Backstage open source project has almost [100 plugins](https://backstage.io/plugins), each one amending Backstage with a tool or service to improve not only adopters’ Backstage apps, but their unique developer experiences. And almost every week we learn of a new one being contributed, which is amazing.
+
+The Backstage platform itself is leaving 2022 more mature than ever, thanks to milestones such as these:
+
+- [Backstage is now beyond version 1](https://backstage.io/blog/2022/03/17/backstage-1.0).
+- [Backstage had its first Security Audit ever and now can rely on a Threat Model](https://backstage.io/blog/2022/08/23/backstage-security-audit).
+- [Backstage Learn helps adopters get started more easily](https://backstage.spotify.com/learn/).
+- [Backstage reached incubating status as part of the CNCF ecosystem](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/).
+
+And like every mature project, now Backstage has also a mascot: Bowie the Beaver!
+
+![Bowie the Beaver.](assets/2022-12-19/bowie-the-beaver.png)
+
+Additionally, we launched a new [Special Interest Groups (SIGs)](https://github.com/backstage/community/tree/main/sigs) initiative this year, following the lead of Kubernetes. We believe Backstage SIGs will better coordinate contributions, grow the platform cohesively with the open source community, and allow contributors to dig even deeper as a community member. At this moment in time there two SIGs in place:
+
+- The [Catalog SIG](https://github.com/backstage/community/blob/main/sigs/sig-catalog/README.md), covering all aspects of the systems and components related to the Software Catalog.
+- The [Adoption SIG](https://github.com/backstage/community/blob/main/sigs/sig-adoption/README.md), covering all aspects of the adoption journey of Backstage.
+
+Our plan is to open more SIGs in 2023 to engage more with the community and to keep driving towards cohesive growth for the community and project.
+
+Last but not least, we mustn't overlook the first ever conference fully dedicated to Backstage: BackstageCon. What was special there? SO much. But in particular two things: seeing everyone in real life and the incredible mood and conversations between maintainers, adopters, partners and enthusiasts. It’s hard to express just how positive and amazing the vibes were in a blog, but you can read our recap [here](https://backstage.io/blog/2022/10/28/backstagecon-kubecon-2022) or watch the sessions [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf). And in the meantime, here are some great numbers from the event:
+
+- 250 attendees or a 100% full venue and packed room.
+- 14 sessions
+- 17 speakers
+
+## Goodbye, 2022. Hello, 2023!
+
+After this incredible year, thanks to everyone in the global Backstage community who contributed to the open source project in 2022. We are already working on the goals for 2023 – and as a roadmap teaser: we are very much committed to making the journey of adoption easier, faster, more valuable, and overall better. We would not be here today without our amazing community, so thank you for everything!
+
+Looking forward to continuing collaborating together for an exciting 2023.
+
+See you then! Happy holidays from everyone on the Backstage team at Spotify!
@@ -0,0 +1,45 @@
+---
+title: Scaling Backstage Ingestion with Incremental Entity Providers
+author: Paul Cowan & Taras Mankovski
+authorURL: https://frontside.com/
+---
+
+At the heart of [Backstage](https://backstage.io/) is the [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/), which is a data store that allows an organization to centralize and visualize its many software services and components. Backstage inspects and transforms an organization's disparate software services and parts into a centralized data store. This blog post introduces the concept of incremental entity providers, which allow Backstage to scale ingestion to even larger datasets.
+
+![catalog pipeline](assets/2023-01-31/catalog-pipeline.png)
+
+{/* truncate */}
+
+A common use case is for an organization to want to surface ownership and metadata about repositories. Backstage provides a mechanism for discovering and transforming repository information into a standard data structure and persisting it into the Backstage [Catalog](https://backstage.io/docs/features/software-catalog/). This process is known as ingestion, where all data is transformed into a standard Backstage data structure known as an entity. Entities in the Catalog’s data store are accessible to the Backstage App via the REST API.
+
+Data is transformed into entities via what is known as the ingestion and processing loop, which can be thought of as an [extract, transform and load (ETL) pipeline](https://en.wikipedia.org/wiki/Extract,_transform,_load), where raw data such as GitHub repositories are loaded from GitHub, transformed into entities and outputted to the Catalog.
+
+## Entity Providers
+
+Backstage offers what are known as [entity providers](https://backstage.io/docs/features/software-catalog/life-of-an-entity) as a means for ingesting the raw data into the pipeline and transforming them into Backstage entities. For example, Backstage comes with a [GitHub Entity Provider](https://backstage.io/docs/reference/plugin-catalog-backend-module-github) that finds all catalog-info.yaml files in GitHub repositories. The processing loop transforms them into Backstage entities and subsequently persists them to the software catalog.
+
+Entity providers are a relatively new abstraction and the recommended way to ingest data into the catalog. The Backstage catalog engine starts each registered entity provider, which connects to its data source (e.g., the GitHub Entity Provider connects to GitHub). The entity provider will query the external data source and convert the data into the entity format. Finally, the entity provider issues what is known as a mutation to the catalog engine. A mutation is a signal from the entity provider to the catalog engine that entities are available to be processed and stored.
+
+A mutation can be either a full mutation or a delta mutation. A full mutation replaces all entities previously ingested by the entity provider with a new set of entities. The entity provider will remove all entities not found in the latest ingestion. A full mutation can be used to ingest relatively small datasets (less than 10,000 entities); however, ingesting more during a full ingestion may cause out-of-memory errors and delay the processing of entities from other entity providers. A delta mutation can surgically add and remove entities from the catalog. A delta mutation is useful when the data source provides events-based APIs like webhooks, which allows the Backstage catalog engine to ingest a small number of entities as they get added, updated and/or deleted.
+
+## Incremental entity providers
+
+A large organization typically deals with massive datasets. Until recently, ingesting large datasets with entity providers has been problematic because performing a full ingestion resulted in out-of-memory errors, and many data sources don’t provide webhooks or other events-based APIs. At the same time, the datasets were too large to efficiently manage through targeted delta mutations.
+
+This is a problem that [DevEx team at HP](http://hp.com) faced when building their software catalog with Backstage. [Damon Kaswell](https://github.com/dekoding), Senior Application Developer on the DevEx team at HP, shared their experience at [BackstageCon 2022](https://www.youtube.com/watch?v=5qHyZntKXRU&list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf&index=13), detailing the problem and the solution that [Frontside](https://frontside.com/) created in collaboration with developers on HP’s DevEx team.
+
+![Damon Kaswell](assets/2023-01-31/damon.jpg)
+
+The solution HP and [Frontside](https://frontside.com/) arrived at was to implement an incremental entity provider. An incremental entity provider effectively performs a full mutation using a series of delta mutations combined with a mark and sweep mechanism. It paginates through the dataset, tracking entities retrieved from each page and the cursor of the next page, pausing ingestion every few seconds to give the processing loop time to process existing entities. Once it reaches the end of the dataset, it determines which entities were not ingested during this ingestion cycle and emits a delta mutation to delete unmarked entities.
+
+Simply by adding a few new tables to the database schema, the incremental ingestion entity provider converts any existing entity provider into an incremental entity provider. These tables allow the incremental entity provider to be long-lived and keep track of its current location in the dataset by persisting a cursor that it uses to page through any large dataset. The larger the dataset, the more pages of data or bursts of work the incremental entity provider will ingest—but there will be no out-of-memory errors, effectively removing scalability problems.
+
+The results speak for themselves. Migrating from regular entity providers to incremental entity providers reduced ingestion time by 92% – from over 4 and a half hours to just 20 minutes. Incremental entity providers eliminated the ingestion maintenance burden from being a constant problem to a non-issue. Writing reliable integration with external services can now be done in days instead of weeks.
+
+## Go forth and ingest!
+
+Backstage provides a robust framework for ingesting data from external sources, but HP needed to scale it beyond its design. The Backstage framework allowed [Frontside](https://frontside.com/) and HP’s developers to extend it with a plugin to support HP’s scaling requirements.
+
+We're delighted to share that as of [this PR](https://github.com/backstage/backstage/pull/14356), the incremental ingestion backend is available for anyone to use with Backstage. The solution was released open source as [@backstage/plugin-catalog-backend-module-incremental-ingestion](https://github.com/backstage/backstage/tree/master/plugins/catalog-backend-module-incremental-ingestion#backstageplugin-catalog-backend-module-incremental-ingestion) and contains a package for creating incremental entity providers. The plugin's [repository README](https://github.com/backstage/backstage/tree/master/plugins/catalog-backend-module-incremental-ingestion) has detailed configuration and usage outlined.
+
+The incremental ingestion entity provider is an excellent addition to the Backstage stack. Battle-tested on large datasets, the incremental entity provider is a significant step forward in smoothing the path to successful ingestion at scale.
@@ -0,0 +1,60 @@
+---
+title: What’s Ahead in 2023?
+author: Lee Mills
+authorURL: https://github.com/leemills83
+---
+
+# What’s Ahead in 2023?
+
+![Fewer “vibes” and more climbs (up the contribution ladder)](assets/2023-02-06/whats-ahead.png)
+
+Okay, everyone. Time to move on from all the 2022 reflections, Top 10 lists, and Wrapped(s), and turn our gaze in the other direction — towards 2023. As the Backstage team moves into the new year, we find ourselves asking those perennial questions: How can we continue to grow and enhance the Backstage community? How can we improve the experience for those adopting Backstage? How can we give the best support to Backstage contributors?
+
+{/* truncate */}
+
+Well, we don’t have all the answers, but we do have some. So we wanted to share more on three ongoing initiatives aimed at moving the needle forward for these three distinct, yet interrelated, questions.
+
+- Grow your influence by climbing the contribution ladder
+- Come join our SIGs (and push for new ones)
+- Work with us to drive a better experience for Backstage adopters
+
+# Climb the contribution ladder
+
+Truth be told, we’ve been wanting to grow the maintainer team for some time, and have had multiple requests from contributors and contributing organizations wanting to become maintainers. But, so far, we just haven’t managed to get anything off the ground. What we see is that becoming a maintainer is too hard and the current ownership model doesn’t work. In short, we need to update Backstage governance.
+
+To address this, we are proposing (RFC links below) the following three initiatives:
+
+- Introduce more steps in between first-time contributor and maintainer in the form of a contributor ladder (loosely based on the [CNCF Project Template](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md)). The ladder might look as follows: Contributor, Org Member, Reviewer, Maintainer, Project Maintainer.
+- Change the ownership model, for example, divide the project up into several project areas, each covering particular parts of the project.
+- Introduce a new process for large contributions in the form of Backstage Enhancement Proposals (BEPs).
+
+Read more and join the already rich discussion in [RFC: Updated Backstage Governance](https://github.com/backstage/backstage/issues/15317) and [RFC: Backstage Enhancement Proposals](https://github.com/backstage/backstage/issues/15318). The RFC will be open until 13/02/2023.
+
+# Come join our SIGs (and push for new ones)
+
+As many of you know, SIG stands for Special Interest Group. The purpose of a SIG is to bring together maintainers and interested contributors within a certain specialist area to discuss, debate, spread knowledge, brainstorm - and drive the overall project forward. They’re also a lot of fun!
+
+We currently have two SIGs up and running:
+
+- [Catalog](https://github.com/backstage/community/tree/main/sigs/sig-catalog?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9fx-nTmQga2j12NqzZaL-lYPq-xQjDoXcWKe_JUoa2RGlK65R9j0CIygfYILr0tGEQSvRVN9xzhiJ6LmVxBthKnStfSA&utm_content=241130993&utm_source=hs_email) started up last June and covers all aspects of the systems and components related to the Software Catalog. The group runs every second Tuesday between 16:00 and 17:00 CET. Just show up or hop into [#catalog](https://discord.com/channels/687207715902193673/923144214580191282) (Discord), if you want to talk to us first. Here are the [notes from our sessions so far](https://docs.google.com/document/d/1xg57CDfX2R5jTGbbWANzifm2szEb664kuTwfEEvKgZU/edit#heading=h.iw0hjv6xfb9e).
+- [Adoption](https://github.com/backstage/community/tree/main/sigs/sig-adoption?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9CAxtT8JSeJZPh41o3ZnDBi0VBFpbL6fEqXInr9HHOFhU3JAo8HekKg1JzE5rhGP5zOaHcsYDd1YxJWNHw-eSk5mLWkA&utm_content=241130993&utm_source=hs_email) kicked off in December and covers all aspects of the Backstage adoption journey including documentation and tutorials. In the first two meetups, we discussed adoption challenges based on user persona, collecting data about those challenges, and bootstrapping the Catalog to improve metadata quality for adopters. This one runs every second Thursday between 16:00 and 17:00 CET. Again just show up or, if you want to talk to us first, you can do so in [#adoption](https://discord.com/channels/687207715902193673/1045031039061479536) (Discord). Here are the [notes from our sessions](https://docs.google.com/document/d/1zeYSzXYgh897bxPQmwy2btOwCFlEjlUDLf00riySLRc/edit?_hsmi=241130993&_hsenc=p2ANqtz-_nPuE5hW4fnbhJ5-uK8r5HisSTU7rkslKirvqu0g-vdynbitPVYF2AVLAatos2dLoxb2Bgx_g4LBgH02kXoq7_Acd43Q#heading=h.iw0hjv6xfb9e) so far.
+
+So that’s SIGs. Get involved and join the ones we have up and running. And/or feel free to propose new ones.
+
+# Help drive a better experience for all adopters
+
+Throughout all stages of adopting Backstage in an organization — initial discovery, evaluation and POC, and scaling to the wider org — we have identified opportunities where we want to make the journey for Backstage adopters faster and smoother.
+
+We’ll go step-by-step, but initial plans are to:
+
+- Make it easier to install, customize, and maintain Backstage
+- Provide Golden Paths for adoption
+- Improve the experience and the content on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
+
+As we move forward, we’d love you to be part of it. Here are some ways that you can contribute to this initiative:
+
+- Simply give us feedback. [Tell us about your adoption journey](https://spotify.co1.qualtrics.com/jfe/form/SV_cuxhYPB6oQDu7gW).
+- Contribute to the pages and documentation on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
+- Pay it forward by making code contributions even during your adoption journey (if you are on one)
+- Join the [Adoption](https://github.com/backstage/community/tree/main/sigs/sig-adoption?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9CAxtT8JSeJZPh41o3ZnDBi0VBFpbL6fEqXInr9HHOFhU3JAo8HekKg1JzE5rhGP5zOaHcsYDd1YxJWNHw-eSk5mLWkA&utm_content=241130993&utm_source=hs_email) SIG
+- Chat with us on [#adoption](https://discord.com/channels/687207715902193673/1045031039061479536) (Discord)
@@ -0,0 +1,91 @@
+---
+title: Backstage Backend System Alpha
+author: Patrik Oldsberg
+authorURL: https://github.com/Rugvip
+authorImageURL: https://avatars.githubusercontent.com/u/4984472?v=4
+---
+
+![backend system alpha header image](assets/2023-02-15/backend-system-alpha.gif)
+
+> UPDATE: The backend system is now released! See [the v1.18 release notes](https://backstage.io/docs/releases/v1.18.0).
+
+For the past year, the Backstage maintainer team has been spending time to give the [old Backstage backend system](https://backstage.io/docs/plugins/backend-plugin) a much needed revamp. Our goal was not to build something completely new from scratch, but rather to solidify the existing foundations that have grown organically. We wanted to make plugin installation a lot simpler, while maintaining and even improving the ways in which you can customize your backend setups.
+
+We’re happy to announce that the [v1.11](https://backstage.io/docs/releases/v1.11.0) release includes the public alpha of the [new Backstage backend system](https://backstage.io/docs/backend-system/)! The system has already been available to use for some time, as some of you have already found, but this alpha release marks the point where we are finally ready to encourage widespread adoption by plugin builders. We still don’t recommend that you use this new system in your production setups just yet, more on that later.
+
+{/* truncate */}
+
+## History of the Backstage backend system
+
+The backend system that we all use today has grown very organically based on all the needs that have been discovered along the journey of the Backstage Open Source project. We started out with a very flexible system that was essentially just a collection of recommended patterns for plugins, along with a couple of common interfaces and utilities. This was largely due to the fact that before it was open sourced, the Backstage backend services at Spotify were all built on top of internal frameworks and practices that we couldn’t bring with us. Back in 2020, we didn’t have a lot of knowledge about what a good backend system for Backstage would look like, so we started off with a highly flexible foundation that would evolve organically over time.
+
+As Backstage grew across all dimensions of adopter count, community size, code size, and capability, we saw the need to take a step back and reevaluate how Backstage backend plugins are built. About one year ago, the maintainers sat down and started to sketch what a new backend system could look like.
+
+## Designing the New System
+
+When we set out on this project, we had a few primary goals. First, we intended to introduce as few new concepts as possible. Our existing system already had a lot of different patterns, and ideally we wanted to only give those patterns names and make them part of the framework. Second, we wanted to keep the backend system recognizable to those familiar with the frontend system. The list of goals goes on, we had a lot of reasons to build this new system, these are a few more important ones:
+
+- Make it easier to create and maintain backend installations.
+- Align how plugins provide points of customization and how those customizations are installed.
+- Make it much easier to maintain plugins, in particular keeping the API stable.
+- Improve the local development and testing experience.
+
+Prioritizing simplicity is often a guiding principle that we use for designs that span multiple ownership roles. We decide on which parts of the system that we think are the most important to have as simple as possible, or, viewed from the opposite end, where in the system we put necessary complexity. In this case, we optimized for keeping the backend setup as simple as possible, followed by modules and plugins, then libraries, and lastly the framework itself. What this guidance means in practice is that when there is complexity that needs to be added to implement a certain feature, we place as much of it as possible within the framework itself, then libraries, plugins and modules, and if absolutely needed, the backend setup.
+
+To get the Backstage backend system to where we are today, we went through three major stages, starting with some very early high level experimentation. If you’re a fan of Git archaeology, you can see some of our early ideas in [our experiments branch](https://github.com/backstage/backstage/commit/fd3e6b67fef25a04789779700db4c37047d59d1b), as well as the [separate repository](https://github.com/backstage/backend-system-exploration) that we used to explore different ideas together with [Roadie](https://roadie.io/). The output of this work was all presented in an [RFC](https://github.com/backstage/backstage/issues/11611) to gather feedback.
+
+A few months later as the RFC settled, we resumed work and followed up with an initial implementation. At this point there were still a lot of details in the design to figure out, especially as we started looking at how our existing plugins and services fit into this new system. We identified a lot of aspects that we inevitably didn’t consider in the initial design, and started exploring technical solutions to those problems. There was a lot of zooming in and out, both implementing details and then stepping back and looking at how that affects the broader system and where to go next. This ended up being the most time consuming stage, and we spent several months iterating on this.
+
+We wrapped up this work just before KubeCon NA 2022, with the full system implemented. The state of the system at this point was presented in our talk on the topic, which you can see just below. Except for a few API tweaks, this is what the system still looks like today.
+
+<iframe
+  width="780"
+  height="440"
+  src="https://www.youtube.com/embed/ZXF7uxrEBVY"
+  frameBorder="0"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+<br />
+
+The final stage was all about polish, which we picked up at the beginning of this year. By leaving a bit of space between the main implementation, or phase two, and the polish phase, phase three, it was much easier to properly scrutinize our past solutions. We forget a lot of the low level reasoning for changes, and it is easier to step back and reconsider parts of the system. For example, we found that our initial design of the `createServiceFactory` function was unnecessarily complex, and could be made much simpler for most usages. In addition to reviewing all the APIs, we also wrote more documentation to help users, ensured that the local development and testing experience was solid, and double checked that there was a smooth migration path from the old system.
+
+## Architecture
+
+Now that you’ve learned about the journey of designing the new system, let’s review the new architecture. This blog includes a brief introduction to the architecture of the new system. If you want to dive deeper, check out our [architecture documentation](https://backstage.io/docs/backend-system/architecture/).
+
+The backend system has five major building blocks:
+
+- Backend instances act as dependency injection containers and are the unit of deployment in which you install plugins and modules that you want to use.
+- Plugins implement the actual features and main business logic, for example the service catalog.
+- Services provide shared utilities for plugins to use, for example logging, database access, and serving HTTP. Services are provided by the backend and can be customized in each backend instance.
+- Extension Points serve as an optional API surface for plugins to provide deeper customization, such as installing custom processors in the catalog. It is up to each plugin to define their own extension points.
+- Modules extend individual plugins with additional features by interacting with the extension points that the plugins expose. A module might for example implement a single entity provider for the catalog.
+
+![backend system architecture](assets/2023-02-15/backend-system-architecture.png)
+
+## Benefits of the New System
+
+This new system reduced the size of a typical backend installation from hundreds of lines of code to just about two dozen, more than an order of magnitude. This reduction comes from shifting complexity away from the backend installation and into the plugins, services, and the backend system itself. Not only does this make a typical backend setup much easier to maintain, but it also makes it much easier to build plugins and modules, and leaves fewer patterns to be unnecessarily invented.
+
+As part of this shift, we’ve moved many concepts from being coding patterns to being features built into the framework. This will allow us to further evolve the backend system in much more interesting ways, and still bring along the entire Backstage plugin ecosystem. It also helps align Backstage plugins around a couple of extensibility patterns, rather than each plugin having their own bespoke patterns for how extensions are installed.
+
+## Alpha, what does it mean?
+
+With the release of the backend system into alpha, we are confident enough in the design of the system that we encourage plugin owners to add support for the new system in their plugins. This means following the [plugin migration guide](https://backstage.io/docs/backend-system/building-plugins-and-modules/migrating) and exporting a plugin instance. Do not remove support for the old system yet – keep your existing `createRouter` export intact.
+
+While we encourage migration of plugins, we do not yet recommend migrating your backend installations to the new system. We want to create space to gather and address feedback from the plugin migration experience, and to make changes if necessary.
+
+If you are worried about the upcoming backend migration, you can [take a peek](https://backstage.io/docs/backend-system/building-backends/migrating#migrating-the-index-file) at our `legacyPlugin` helper. It allows you to forklift over all existing plugin setups to the new backend system, and then migrate plugins one by one.
+
+## Next Steps
+
+During the next release we will keep working on migrating the core plugins, as well as addressing any feedback that we receive. We don’t want to rush a stable release though, and won’t encourage broad adoption until we’re confident that we won’t have to follow it up with immediate breaking changes. Yet, we are excited about where we are today, and are looking forward to the future stable release!
+
+Useful Links:
+
+- [Architecture Docs](https://backstage.io/docs/backend-system/architecture/)
+- [Building Plugins](https://backstage.io/docs/backend-system/building-plugins-and-modules/)
+- [Core Services](https://backstage.io/docs/backend-system/core-services/)
+- [#backend-system](https://discord.com/channels/687207715902193673/1034089724664610938) channel in Discord
@@ -0,0 +1,104 @@
+---
+title: Backstage Turns Three!
+author: Ben Lambert
+authorURL: https://github.com/benjdlambert
+authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
+---
+
+![backstage turns 3 header image](assets/2023-03-15/birthday.gif)
+
+**TL;DR** Spotify released Backstage into open source three years ago today. Since then, the community has grown by leaps and bounds to stretch across the globe (and the Discord server!). Now that Backstage is a threenager, the growing pains are real. So, on this birthday, we want to cover our collective efforts to make it easier to adopt and contribute to Backstage.
+
+{/* truncate */}
+
+## They grow up so fast, don’t they?
+
+Happy birthday, Backstage! Three years ago, Spotify released its homegrown developer portal into the wild after a small team collaborated on an internal Hack Week project. We’d had a lot of conversations with companies looking to build out something similar to what we’d been running for years, so our Hack Week sprint started as an experiment to see if the Backstage core plugins could be valuable in open source.
+
+It's cliché at this point — because we’ve said it a million times — but no one could have predicted what came next.
+
+In three short years, Backstage has grown to a Cloud Native Computing Foundation Incubating project, with more than 900 adopters and 1000+ contributors worldwide. Companies like CVS Health, Siemens, LinkedIn, REI, Vodafone, and Lego are building out their own developer portals from the Backstage framework and bringing their learnings to the project.
+
+A few more stats we love to see (mainly coming from the [project repo](https://github.com/backstage/backstage)):
+
+- 3k+ project forks
+- 38k+ commits
+- 12k+ PRs
+- 15k+ total contributions
+- 21k+ stars on GitHub
+- 9k+ Discord members
+- 100+ open source plugins in the [plugin marketplace](https://backstage.io/plugins)
+
+But, without a doubt, the best thing about the Backstage project is the people in this community. People who are curious, collaborative, and excited to share knowledge. People who’ll sift through Discord at all hours to answer questions and support one another. People who come from all over the world but share a common trait: being passionate about enabling developers to do their best work.
+
+Don’t take our word for it! Take a look at this birthday video we put together with a few community members.
+
+<div
+  style={{
+    position: 'relative',
+    overflow: 'hidden',
+    width: '100%',
+    paddingTop: '56.25%',
+  }}
+>
+  <iframe
+    style={{
+      position: 'absolute',
+      top: 0,
+      left: 0,
+      right: 0,
+      bottom: 0,
+      width: '100%',
+      height: '100%',
+    }}
+    src="https://www.youtube.com/embed/rllOa_MfEWw"
+    frameBorder="0"
+    allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+    allowFullScreen
+  ></iframe>
+</div>
+
+## The growing pains are real
+
+But it's not all sunshine and roses in Backstage-land. If Year 1 was about getting this community going and Year 2 was focused on maturing the platform, then Year 3 needs to address some of the inevitable growing pains a project undergoes as it gains ground.
+
+We hear two things pretty consistently from the community:
+
+- **Backstage is a steep learning curve:** Over the past three years, the project has grown in scope and breadth which can translate to complexity. This is especially true for newcomers looking to get their arms wrapped around the key concepts.
+- **Backstage has barriers to adoption:** Backstage adopters tell us driving widespread adoption of their developer portal remains the biggest challenge they face. Adoption barriers can be technical but are often cultural.
+
+The maintainers and some of our most involved community members are actively tackling how we can make the Backstage onboarding process easier for contributors. There are also lots of ways the project could better support adopters on that journey and make adoption faster and smoother.
+
+We’re looking at everything from cleaning up documentation to opinionated catalog ingestors being discussed in both the Catalog and Adoption monthly SIGs (running meeting notes [here](https://docs.google.com/document/d/1xg57CDfX2R5jTGbbWANzifm2szEb664kuTwfEEvKgZU/) and [here](https://docs.google.com/document/d/1zeYSzXYgh897bxPQmwy2btOwCFlEjlUDLf00riySLRc)). A few priorities that we’ve already mapped out:
+
+- Make it easier to install, customize, and maintain Backstage
+- Provide Golden Paths for adoption
+- Improve the experience and the content on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
+
+Because there are now so many mature adopters — Spotify included — there’s so much knowledge on how to create a roadmap for adoption and use cases, how to roll out your developer portal to your teams and drive inner source contributions, how to measure and attribute developer productivity gains, etc.
+
+Our goal is to tap into the knowledge those adopters have gained and create more tangible resources for the entire community. But we can’t do it without help. And that’s where you come in!
+
+## Getting (more) involved
+
+We’re very grateful for the Backstage ride-or-dies: the contributors who show up to every community session, attend every SIG, and are always ready to jump in on any PR or issue.
+
+But one of the areas where we think the project could greatly improve (and better address some of the growing pains I mentioned above!) is more active contribution — both the total number of people contributing and what they’re contributing.
+
+We’ve already shared a bit on this but the maintainer team is starting to address this challenge by proposing the following three initiatives:
+
+- Introduce more steps in between first-time contributor and maintainer in the form of a contributor ladder (loosely based on the [CNCF Project Template](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md)).
+- Change the ownership model, for example, divide the project up into several project areas, each covering particular parts of the project.
+- Introduce a new process for large contributions in the form of Backstage Enhancement Proposals (BEPs).
+
+These two RFCs on [Updated Backstage Governance](https://github.com/backstage/backstage/issues/15317) and [Backstage Enhancement Proposals](https://github.com/backstage/backstage/issues/15318) remain open so feel free to read and join the discussion! Watch this space as we’ll share more on the go-forward governance and BEPs plan soon.
+
+But if you’re brand-new and just looking to get your feet wet, we’ve also [compiled some small steps](https://backstage.io/docs/getting-started/getting-involved/) you can take to get involved:
+
+- Report (or squash) bugs: Look through the GitHub issues for [bugs](https://github.com/backstage/backstage/labels/bug), [good first issues](https://github.com/backstage/backstage/labels/good%20first%20issue) or [help wanted](https://github.com/backstage/backstage/labels/help%20wanted)
+- Build or suggest a plugin: The Backstage project grows with every new plugin that gets added
+- Add non-code contributions: We welcome things that help the community at large, but may not fit into the scope of the core project
+- Write documentation or improve the website: The current documentation and project site are pretty limited. Better content helps a lot of those growing pains.
+- Contribute to Storybook: Help us [create new components](https://github.com/backstage/backstage/labels/help%20wanted) or improve stories for the existing ones
+- Submit feedback: The best way to send feedback is to file [an issue](https://github.com/backstage/backstage/issues) with as much detail as possible
+- Add your company to ADOPTERS: Adding your company to [ADOPTERS](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) really helps the project, you can do this by filling out this [adopter form](https://form.typeform.com/to/zcOaKikB)
@@ -0,0 +1,34 @@
+---
+title: 'ICYMI: KubeCon EU 2023'
+author: Bailey Brooks, Spotify
+authorURL: http://github.com/bailey
+authorImageURL: https://pbs.twimg.com/profile_images/1477424303192694785/qCfN6XWW_400x400.jpg
+---
+
+![KubeCon CloudNativeCon Europe 2023 banner](assets/2023-04-26/Backstage_News_3-7-23_KubeCon.png)
+
+We had a blast talking all things Backstage at KubeCon EU 2023 in Amsterdam last week. In case you missed it, here’s a quick recap:
+
+{/* truncate */}
+
+## Backstage Project Meeting
+
+![A packed room for the Backstage project meeting](assets/2023-04-26/IMG_2522.png)
+
+On Tuesday the Backstage maintainers hosted a jam-packed project meeting. The community welcomed many teams and individuals that were early in their Backstage journey, either actively adopting, preparing for the POC phase, or learning about the capabilities of Backstage. Many of the newcomers were eager to learn about how Backstage could help streamline their development workflows and improve developer productivity. During the project meeting, the maintainers covered a “day in the life” of a core maintainer, walked through spinning up a new instance of Backstage in a live demo, and opened it up to questions from the community. It’s super exciting to see so much growing interest in Backstage and all of the ways adopters are adapting it to their needs.
+
+## State of Backstage in 2023
+
+![Patrik and Ben onstage for the State of Backstage talk](assets/2023-04-26/IMG_0120.png)
+
+Core maintainers [Ben Lambert](https://github.com/benjdlambert) and [Patrik Oldsberg](https://github.com/Rugvip) took center stage on Wednesday for the Backstage Maintainer Track: State of Backstage in 2023 talk. Backstage has officially hit over 1,000 adopters and 1,000 contributors – so it’s apt timing to modernize the governance model for the project. Taking pointers from the [CNCF Contributor Ladder Governance Template](https://contribute.cncf.io/maintainers/templates/), a new [Backstage Governance Model](https://github.com/backstage/community/blob/main/GOVERNANCE.md) is now in effect! Patrik walked us through the new ladder model which introduces a number of changes, one being the addition of [project area maintainers](https://github.com/backstage/community/blob/main/GOVERNANCE.md#project-area-maintainer). This role lets members of the community take increased ownership over a specific area of interest, like Catalog, Discoverability, TechDocs, Helm Charts, and Kubernetes. New project areas that will be added include Permissions and Software Templates. New project areas can be proposed by nominating a project area maintainer for the area. The new model also adds an organization member role for contributors who want to take a more active role in the Backstage community. You can open an issue to become an organization member [here](https://github.com/backstage/community/issues/new/choose).
+
+![Contributor ladder](assets/2023-04-26/contributor_ladder.png)
+
+Ben and Patrik also covered new capabilities for Software Templates and framework updates. Lots of exciting new features are planned for Software Templates including a new UI, async validation for CustomFieldExtensions, and embedded workflows. Lastly, the maintainers also announced a new focus on declarative integration – permitting plugin installation without TypeScript. Development is still early, but we can’t wait to see this in action!
+
+## Other KubeCon excitement!
+
+Throughout the week, we also heard success stories of adopters, like AppsFlyer’s talk, “How We Migrated Over 1000 Services to Backstage Using GitOps and Survived to Talk About It!” AppsFlyer has over 1,000 services and processes over 200 billion events per day – so migrating to Backstage as their service catalog platform was no small feat. As part of their migration, they also integrated GitOps and Terraform into their Backstage instance. Many attendees found interest in these case studies where you could see the adoption and POC process directly from other adopters. It was exciting to see firsthand how teams can extend Backstage to fit their needs on the fly.
+
+We were thrilled to see so much excitement and interest brewing around Backstage this year! If you missed it, you can catch up as soon as more talks are added to the [CNCF YouTube channel](https://www.youtube.com/@cncf/featured). We can’t wait to catch up with you all again soon at KubeCon North America in Chicago.
@@ -0,0 +1,79 @@
+---
+title: 'Welcome: Backstage Deploy CLI (Alpha)'
+author: Djamaile Rahamat, Spotify
+authorURL: https://github.com/djamaile
+authorImageURL: https://avatars.githubusercontent.com/u/15789670?v=4
+---
+
+_This blog post is co-authored by Emma White ([@ewhite1997](https://github.com/ewhite1997)), Spotify._
+
+![Backstage Deploy banner](assets/2023-05-06/Welcome-Backstage-Deploy.png)
+
+TL;DR: Backstage released a new CLI earlier this year as part of a [new Backstage project](https://github.com/backstage/backstage-deploy). This new capability allows early adopters to deploy their Backstage proof of concept faster than before. In this blog, you’ll learn a little bit more about the Deploy CLI and how you can get started with it.
+
+{/* truncate */}
+
+## Why Backstage Deploy
+
+We’ve heard from Backstage adopters that before reaching widespread adoption at their organizations, teams test out a Backstage proof of concept (POC). To create the POC, teams scaffold an instance, set up the catalog, and change the UI to suit their company’s branding. Once these milestones are completed, there's just one last step before showing off the awesomeness of a Backstage POC internally... deploying the Backstage POC from a local machine to the cloud. This final step often introduces a lot of questions that attempt to determine the easiest and fastest way to do that.
+
+Let’s say you’re at this last step: your POC is ready for deployment, but you have some lingering questions.
+
+For example:
+
+- What Dockerfile should you use?
+- Should the POC be deployed on Kubernetes?
+- How do you deploy the POC on my cloud provider?
+
+To address these questions and reduce friction from deploying a POC, we built a [new CLI](https://github.com/backstage/backstage-deploy). The CLI is simply called `deploy` and is invocable with `npx`. With this new CLI, you can generate a Dockerfile and deploy a Backstage instance onto a preferred cloud provider. While the package’s infrastructure is built to support all cloud providers, currently the CLI only offers an AWS implementation. In the future, we plan to add additional cloud providers to the package and [welcome any contributions](https://github.com/backstage/backstage/blob/6996b3338d678efc03307112524060e9dc2ad769/CONTRIBUTING.md) extending the suite of cloud provider implementations!
+
+**So, what about Kubernetes?** Since the CLI is designed specifically for the POC phase, we believe that Kubernetes isn’t the right fit – as Kubernetes is better suited for production workloads. So, we explored lightweight, container-based solutions, and landed on [Amazon Lightsail](https://docs.aws.amazon.com/lightsail/index.html) as a hosting service for the POC.
+Amazon Lightsail supports [lightweight container](https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-container-services) deployments [at a low cost](https://aws.amazon.com/lightsail/pricing/), and has a [free trial for new users](https://aws.amazon.com/lightsail/pricing/?loc=ft#AWS_Free_Tier)! Given Lightsail’s ease of use and affordability, we recommend using Lightsail over Kubernetes to test out your Backstage POC.
+
+With the Dockerfile and Kubernetes questions answered, we just have to address how to actually deploy the POC. And that is where the new CLI comes in.
+
+## Get started with Deploy CLI
+
+It's now time to put the Deploy CLI into action and deploy a Backstage POC. The following steps guide you through the deployment process.
+
+Deploy CLI makes use of [Pulumi](https://www.pulumi.com/docs/) which is an infrastructure-as-code tool that helps provision resources in the cloud. Before you get started, ensure you have the [Pulumi CLI](https://www.pulumi.com/docs/cli/) and [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) installed on your local machine.
+
+You can find the step-by-step installation documentation for Pulumi under the [Deployment section](https://backstage.io/docs/deployment/backstage-deploy/aws-lightsail).
+
+But we summarize the steps to deploy your POC here. You can invoke the CLI you can use the following command:
+
+```bash
+$ npx backstage-deploy aws --create-dockerfile
+Starting Pulumi
+successfully initialized stack
+installing aws plugin...
+plugins installed
+setting up config
+refreshing stack...
+Refreshing (backstage):
+
+Instance will live at:
+https://backstage-container-service.xxx.us-east-1.cs.amazonlightsail.com/
+```
+
+Once you kick off the command it will create a Dockerfile for you in the root and Pulumi will start provisioning resources in AWS.
+Pulumi will then create a container based deployment in Amazon Lightsail.
+
+After you’re done with the POC, it’s easy to delete the AWS resources you provisioned and save you costs within AWS. You can do so with the following command:
+
+```bash
+$ npx backstage-deploy aws --destroy
+```
+
+## Looking ahead
+
+As mentioned earlier in this blog, we released the Backstage Deploy CLI with an AWS implementation only. In the next few months, we are excited to collect feedback from our end users to understand how the AWS implementation works. With those learnings, we plan to iterate on the Deploy CLI and build out implementations for other cloud providers. Of course, contributions are always welcome!
+
+So, please try this new CLI out and let us know what you think on [Discord](https://discord.com/channels/687207715902193673/995973463208644678)!
+
+Useful links:
+
+- [Backstage Deploy](https://github.com/backstage/backstage-deploy)
+- [Documentation](https://backstage.io/docs/deployment/backstage-deploy/aws-lightsail)
+- [Pulumi docs](https://www.pulumi.com/docs/)
+- [#deployment](https://discord.com/channels/687207715902193673/995973463208644678) channel in Discord
@@ -0,0 +1,74 @@
+---
+title: Switching out the Software Templates Sandbox
+author: Ben Lambert
+authorURL: https://github.com/benjdlambert
+authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
+---
+
+**TL;DR**: For the Backstage maintainers, ensuring that the project is highly secure for every adopter and end-user is one of our top priorities. With the recent vulnerabilities in the `vm2` sandbox we have decided to move away from `vm2` and use `isolated-vm` instead, in order to ensure the security of the Backstage end-users.
+
+![Backstage Security Audit & Updates](assets/22-08-23/backstage-security-audit.png)
+
+{/* truncate */}
+
+## A quick download on templating strings
+
+When using [Software Templates](https://backstage.io/docs/features/software-templates), we allow template authors to [write advanced templating strings](https://backstage.io/docs/features/software-templates/writing-templates/#the-templating-syntax) when composing actions together like the following:
+
+```yaml
+- id: template
+  name: Fetch Skeleton + Template
+  action: fetch:template
+  input:
+    url: ./skeleton
+    copyWithoutRender:
+      - .github/workflows/*
+    values:
+      // highlight-start
+      component_id: ${{ parameters.component_id }}
+      description: ${{ parameters.description }}
+      destination: ${{ parameters.repoUrl | parseRepoUrl }}
+      owner: ${{ parameters.owner }}
+      // highlight-end
+```
+
+These parts that are wrapped with `${{ … }}` are evaluated by the Software Templates backend plugin.
+The template strings provide a rich API that enables template authors to manipulate the parameters provided by users of the templates and to pass the parameters into both the built in filters and custom filters that template authors provided when configuring the plugin.
+
+This templating language is called [Nunjucks](https://github.com/mozilla/nunjucks), which is based on [Jinja2](https://pypi.org/project/Jinja2), both of which are popular templating engines.
+Under the hood these templating strings compile into JavaScript. The [Backstage Threat Model](https://backstage.io/docs/overview/threat-model/) treats the code provided by the template language as untrusted, so adopters need a safe environment – a sandbox – to execute the JavaScript in.
+Up until the latest Backstage release, that sandbox was `vm2`. Now, the project is instead using `isolated-vm` as the sandbox to execute this JavaScript in.
+
+## Why the change?
+
+You might have seen over the last few months [some advisories and CVEs](https://github.com/patriksimek/vm2/security/advisories) that were found in the original [`vm2`](https://github.com/patriksimek/vm2) sandbox that we were using.
+Both the `vm2` maintainers and the Backstage maintainers have been quick at releasing new versions of the sandbox and the Software Templates backend plugin, respectively, to protect their users.
+
+We were recently made aware of another sandbox escape through our HackerOne BugBounty program, with a Proof of Concept using a Software Template.
+The maintainers of the `vm2` project have also been notified. We currently cannot find a simple solution to stop the latest escape. So, In the interest of moving quickly to protect the security of our end-users, we're moving away from that `vm2` and moving towards [`isolated-vm`](https://github.com/laverdet/isolated-vm) instead.
+
+`vm2` has been one of the most popular sandboxes to-date, and we want to thank the `vm2` maintainers for the recent sandbox escape fixes and getting those shipped as fast as possible.
+
+## What does this mean for Backstage?
+
+`isolated-vm` uses a quite different implementation and security model compared to `vm2`.
+
+It is a native dependency and executes code in a `v8` engine so-called `isolate` instead. This means that by design, it does not have any access to neither the node runtime nor any frameworks on top of `v8`, which is precisely what we want to ensure in our sandbox.
+
+This method of sandboxing is much more secure than how the `vm2` sandbox functions, and less prone to escapes.
+
+While we can rest assured that this is a highly secure sandbox, the native dependency might mean there's a little more burden on adopters to install this dependency properly and have the right libraries set up.
+This native dependency must be built upon installation, on the exact architecture that it executes on.
+
+For those who compile and run Backstage on stripped-down environments, you will want to ensure that you have the build basics present, e.g. `build-essential` or similar corresponding to your operating system of choice.
+The `isolated-vm` repo has [some further information](https://github.com/laverdet/isolated-vm#requirements) about the build environment requirements.
+
+With all that said, we think this tradeoff is worth the effort to ensure better security.
+
+## What do you need to do?
+
+This change comes with the v1.15.0 release of Backstage that was released yesterday, so please make sure you are upgraded to the latest version of Backstage to keep your sandbox environments secure.
+
+For more guidance on how to upgrade, check out the documentation for [keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
+
+If you have any further questions you can either reach out to us in the [Community Discord](https://discord.gg/backstage-687207715902193673), or in the [office hours](https://info.backstage.spotify.com/office-hours).
@@ -0,0 +1,188 @@
+---
+title: 'Adopter Spotlight: How Stash simplified monitoring, ownership and true app health with microservices'
+author: Taylor Webber, Staff Engineer, Stash
+---
+
+![backstage header](assets/2023-07-08/banner.png)
+
+**TL;DR**: Monitoring the health of a software application goes beyond surfacing API errors and customer-facing issues. It requires a comprehensive understanding of every facet of a service, including process metrics like DORA, as well as clear ownership of services and processes. By implementing Elevate as an internal developer portal, development teams now have better visibility of ownership in the distributed systems they work in. They also have the benefit of consolidated application health data and other metrics gained from the SaaS products they utilize everyday. This approach ensures a “single pane of glass” for application ownership and health so our teams can focus on building products and features that help our customers invest for a prosperous future.
+
+{/* truncate */}
+
+At [Stash](https://www.stash.com), our mission is to give people the confidence to invest for a better life. Our app simplifies investing for the middle class who may be less experienced with traditional investing and retirement planning. Our customers trust us with their money, and with that, rely on us to provide a responsive and quality experience that works every time.
+
+It isn't revolutionary to say that monitoring the health of a software application is critical for ensuring its reliability and performance in service of customers' needs. However, in a distributed architecture like microservices, tracking ownership and monitoring application health across the system quickly becomes complex. The difficulties are further compounded when leveraging multiple SaaS products, which is common in modern development but specifically so for fintechs like Stash that integrate best-of-breed software in novel ways, as we do across our platform.
+
+What we found is that there are ways to make sense of these complex systems by tracking DevOps Research and Assessment (DORA) metrics for applications and leveraging SaaS products to create a central hub to understand the _true_ health of an application.
+
+In this post, I'll walk you through Stash's journey to create Elevate, our Internal Developer Portal (IDP) based on the open source [Backstage](https://backstage.io/) framework. Our portal increased visibility of application health metrics, prioritized cloud cost insights, and reduced the context switching required for teams to understand service ownership and the components that make up the entirety of Stash's world-class application systems.
+
+Elevate enables effective monitoring, streamlined incident response, improved overall application health, and most importantly, team health.
+
+# Setting the monitoring/DORA scene
+
+It seems counterintuitive, but trying to solve the problem of monitoring and tracking ownership with a traditional centralized approach and more SaaS monitoring tools will likely not solve the problem.
+
+Traditional centralized monitoring approaches may not suffice in a distributed architecture due to services that may act as pass-throughs or services that call many other services to aggregate data or tasks. In traditional monitoring, you will only see the error rates and request logging for individual services. That will only ever show you part of the puzzle as you'll still be unable to trace a request from a frontend application, through your many service layers to your data stores and back out.
+
+Utilizing multiple SaaS products for service monitoring and observability during development introduces additional complexity; each product may have its own dashboard and reporting tools. These implementation differences can make it difficult to consolidate and gain a holistic view of the application's health.
+
+Picking the right tool for the job can make developing quality products at speed and scale easier, but what we've learned is that utilizing each tool's context for application health as a piece of the puzzle has exponentially impacted our team's effectiveness.
+
+The team at Stash took an approach of enhanced monitoring which required introducing request tracing for services that a team owns (and the entire org) to get the full picture. We worked to distribute monitoring **_across_** services, capturing both customer-facing issues and internal process metrics that focus on service quality.
+
+We also took a hard look at our health metrics. Some attributes of healthy applications are high availability, HTTP 500 errors are minimal, CPU and memory usage are sustainable, and the “/health” endpoint returns the health of the application. However, to gain insights into the true health of an application and the teams supporting it, tracking DORA metrics is essential.
+
+We took four key DORA metrics — deployment frequency, lead time for changes, mean time to restore, and change failure rate — to process aspects of services and provide a comprehensive understanding of an application's overall health as well as the health of our team and organization.
+
+# Understanding complex systems at Stash with Backstage
+
+At Stash, we use a multitude of SaaS tools during the software development process, some of which provide varying degrees of built-in service catalogs. With many sources of truth and a lack of ability to combine data from multiple sources (eg. FireHydrant incident response with DataDog or DataDog Real User Monitoring data in PagerDuty, etc.) it was challenging to get a holistic view of the whole system..
+
+Additionally, as we created more and more microservices, it became challenging to determine ownership for each service. Microservice owners were finding it increasingly difficult to keep track of their various consumers to assure that contracts were being maintained as new changes were introduced. Ownership clarity was **_crucial_** to our goals for effective monitoring, issue resolution, and maintaining accountability.
+
+To consolidate application health data, simplify support and clarify ownership for those on development teams as well as for those in non-engineering roles, we implemented an instance of Backstage as an internal service catalog we call Elevate.
+
+Utilizing Backstage as a framework, Elevate aims to improve quality and domain expertise for all things code and process at Stash. The key to accomplishing this goal is to leverage the processes and integrations we already use at Stash, but centralize and surface the data in a way that is digestible for engineers and non-engineers alike.
+
+For the benefit of a self-managed internal service catalog to outweigh the change in processes and the cost of the catalog's infrastructure, it had to be easy to adopt and have an enlightening effect on teams.
+
+## Ownership visibility
+
+Elevate acts as a centralized hub for registering services, documenting ownership information, and establishing clear accountability. It provides a holistic view of distributed systems and the shared modules and libraries they use by making it easier to track ownership and ensure effective communication and collaboration.
+
+The Backstage [Software Catalog](https://backstage.io/docs/features/software-catalog/) model allows service-level tracking, as well as dashboards for Groups (teams or squads), Systems (business units or focus areas), Domains (organization units) or even company wide.
+
+### Easy adoption and catalog usage
+
+The Backstage open source plugins provide the nuts and bolts for our internal service catalog functionality. Backstage's community plugins assist with the basics of catalog management. They also allow for dynamically changing the type content based on which entry is being viewed in the catalog (library, service, API, team, etc.). Each view can be custom-tailored with the information for that type of entry, which allows for shared libraries to have an overview page focused on getting engineers to documentation; while the overview page for a deployed service can focus on the current incident status and on-call information as the most important thing. The plugin for searching allows for easy discovery of items or documentation throughout the catalog.
+
+###### Example catalog-info.yaml file to add service to Elevate
+
+```yaml
+apiVersion: backstage.io/v1alpha1
+kind: Component
+metadata:
+  name: your-service
+  description: Awesome service for awesome things
+  annotations:
+    backstage.io/kubernetes-namespace: your-service
+    datadoghq.com/site: datadoghq.com
+    datadoghq.com/dashboard-url: https://p.datadoghq.com/some-dashbaord
+    firehydrant.com/service-name: your-service
+    jira/project-key: your-jira-project
+    github.com/project-slug: 'your-org/your-service'
+    pagerduty.com/service-id: your-pagerduty-service-id
+  links:
+    - title: Team Slack Channel
+      url: https://your-company.slack.com/archives/your-slack-channel-id
+      type: Slack
+      icon: chat
+    - title: Getting started
+      url: https://github.com/your-org/your-service/blob/main/README.md
+      type: Readme
+      icon: github
+    - title: Confluence
+      url: https://your-company.atlassian.net/your-docs-page-url
+      type: Confluence
+      icon: docs
+spec:
+  type: service
+  lifecycle: production
+  owner: your-team
+  system: your-business-unit
+```
+
+### Connecting to subject matter experts
+
+Elevate leverages the CODEOWNERS integration to establish expertise of specific codebases within services and ensure accountability and clarity within the development teams. Codespace ownership is typically defined with required reviewers by code owners and admins that provide additional support, but the CODEOWNERS plugin allows for clarity into who the subject matter expert of the codebase is, not just the administrative owner. The plugin also displays recent changes that have been merged into the codebase, including the authors and approvers of the changes and other valuable metadata.
+
+This improved clarity into contributors and recent contributions can prevent developers and managers from playing telephone when effective communication is crucial to fixing a bug or resolving an incident.
+
+![service code owners](assets/2023-07-08/image5.png)
+
+![recent changes](assets/2023-07-08/image3.png)
+
+_CODEOWNER cards for service ownership and recent changes that appear on a service's overview page._
+
+## Integration with SaaS products
+
+Backstage offers a catalog of integrations with many popular SaaS products. With Elevate, we've integrated plugins for monitoring infrastructure and user experience, visualizing process backlog and bottlenecks, as well as giving insights into data that teams have not yet been able to see for services they support. These integrations allow for seamless data collection and aggregation, transforming Elevate into the centralized hub for application and team health data.
+
+The key to making your service catalog scalable is to ensure you aren't requiring the duplication of data away from its source; Elevate utilizes dashboards and charts to view the data stored in the remote sources. When aggregating DORA metrics we are able to leverage our SaaS tools API within Elevate's service layer to pull data and transform it for our custom dashboards.
+
+### Visible cohesive monitoring
+
+At Stash, we collect performance metrics, resource utilization, and proactive alerts with DataDog and Sentry; these tools can also monitor and track API errors and customer-facing issues that would normally go undetected. To deliver the best possible experience for Stash's customers, engineers need to be able to easily monitor errors on customer devices to solve issues before they are reported.
+
+Sentry's plugin easily surfaces uncaught errors within services. DataDog's plugin allows for plug-and-play visualizations of charts or graphs to help support services, teams and beyond. Elevate integrates these insights to monitor the overall health of the application.
+
+### Centralized incident management
+
+PagerDuty has been Stash's standard for on-call activities and paging while FireHydrant has more recently been adopted as a part of a more comprehensive incident management process. Together, we use these incident management platforms to establish incident response workflows and communication channels dedicated to each service.
+
+PagerDuty's plugin allows for quick reference to the individual who is actively on-call for a service while FireHydrant's plugin lets you track open incidents that may be impacting a service and even trigger new incidents directly from within the service overview page in Elevate. Integrating these plugins allows Elevate to serve as a centralized location for the incident management process, helping our engineers quickly gather the necessary context of an issue and drive faster resolution.
+
+![active incidents](assets/2023-07-08/image1.png)
+
+![pager duty](assets/2023-07-08/image8.png)
+
+_FireHydrant and PagerDuty cards that appear on a service's overview page._
+
+## Infrastructure cost insights across all systems
+
+It's difficult for teams to be more efficient with their infrastructure costs if they are unable to see the problem areas for the services they support, as well as references for effective resource management to model after. The AWS Cost Insights plugin allows Elevate to monitor cost-related metrics and ensure efficient resource allocation and budgeting.
+
+Due to the dynamic nature of how different companies may want to aggregate their cost data, the plugin is mostly frontend visualizations for displaying costs over time with drop-downs for filtering and grouping. In Elevate, we created a custom backend plugin to pull our costs data from AWS and group it properly for presentation to the visualizations.
+
+When we surface this data with the backend layer in Elevate, the frontend is able to surface our AWS cost data to people who previously didn't have access or who found it too difficult to use the more complex AWS Cost Explorer.
+
+In addition to these people now having access to AWS cost data, those with access now get to visualize our spend by AWS product and Stash service. These visualizations are available when looking at a single service, a team or business unit, and organization-wide.
+
+![aws breakdown](assets/2023-07-08/image6.png)
+
+_Breakdown of costs per AWS product for a service._
+
+![aws breakdown by project](assets/2023-07-08/image9.png)
+
+_Breakdown of total costs per service owned by a Team or Business Unit._
+
+![aws breakdown for org](assets/2023-07-08/image4.png)
+
+_Breakdown of total costs per service across the organization._
+
+For those that aren't regularly in AWS Cost Explorer, a benefit of implementing these visualizations is being able to easily see where we have some room for improvement when it comes to tagging our AWS resources. The company-wide breakdown shows all resources, whereas the sub-views rely on resource tagging for service name and team name, so discrepancies may arise which will help you close any gaps in tagging you may have. If resources are not properly tagged, reducing and managing your infrastructure costs will be more time consuming than necessary and much less effective.
+
+## Service, team and organizational health
+
+As mentioned above, gathering DORA metrics provides important insight into the health of applications and teams, but until we built Elevate, we didn't have a hub at Stash to aggregate and present that data in an easily digestible manner.
+
+Elevate's initial DORA metrics implementation reaches out to the source(s) of truth for each metric and groups and surfaces that in a manner similar to the AWS Cost Insights implementation.
+
+**Deployment Frequency** from DataDog “deployment” indicator for each service
+
+**Lead Time for Changes** from GitHub for each repo using commit sha's and releases
+
+**Mean Time to Restore** from FireHydrant using their MTTR API for each service
+
+**Change Failure Rate** from DataDog and FireHydrant for each service
+
+Elevate implemented the above data sources for our DORA metrics MVP as those have been determined as our best practices for where that information should be tracked, for now.
+
+![dora metrics](assets/2023-07-08/image10.png)
+
+_DORA metrics that display on the overview page for each service._
+
+Software development has an ever-changing SaaS landscape, so what serves as a best practice today, may not be in a week, a month or a year from now. The tools we use to facilitate a task or automate processes may change, but the metrics we want to track (DORA and others) are much more stable. Surfacing data in easily consumable views within Elevate has decoupled the tool we use to accomplish a task from where we monitor the health of our system and how that tool assists.
+
+![dora metrics typescript interface](assets/2023-07-08/image7.png)
+
+_An abstracted service layer that is agnostic of data source(s) allows for a stable integration for our frontend dashboards._
+
+![backend interface](assets/2023-07-08/image2.png)
+
+_Separate backend services by metric allow for easy updating for additional or new data sources in the future._
+
+# tl;dr
+
+Monitoring the health of a software application goes beyond surfacing API errors and customer-facing issues. It requires a comprehensive understanding of every facet of a service, including process metrics like DORA, as well as clear ownership of services and processes. By implementing Elevate as an internal developer portal, development teams now have better visibility of ownership in the distributed systems they work in. They also have the benefit of consolidated application health data and other metrics gained from the SaaS products they utilize everyday. This approach ensures a “single pane of glass” for application ownership and health so our teams can focus on building products and features that help our customers invest for a prosperous future.
@@ -0,0 +1,50 @@
+---
+title: 'Five common traits of successful Backstage adopters'
+author: Taras Mankovski, CXO, Frontside
+---
+
+![backstage header](assets/2023-07-28/header.png)
+
+At [Frontside](https://frontside.com/), our goal is to help cloud-native teams create cohesive development experiences. We've been at the Backstage party since the beginning helping companies adopt and extend Backstage to fit the needs of their unique ecosystems.
+
+Through our experience, we've uncovered five common traits of organizations that have improved developer experience through successful Backstage implementation and adoption. In this blog, we'll dive into these traits with some thoughts on how you can follow their blueprint.
+
+{/* truncate */}
+
+## **1) They take a product-centric approach**
+
+The biggest factor for successful adopters of Backstage is their approach. There is a high correlation of success within organizations that approach building a developer portal like they're building a product. Some organizations will jump straight into solutioning instead of taking their time to identify what the problems are, how they affect users, and how those issues can be addressed.
+
+The team building out Backstage should assess or work from existing insights on the core challenges that developers are facing in their organization — both qualitative and quantitative data counts here — and connect those issues to a product roadmap with initial use cases and adoption milestones marked. By doing their research in advance, successful orgs have a clear vision of what they want to accomplish with their Backstage instance. They know exactly what goals need to be met and have pressure-tested potential issues and barriers.
+
+If you've already started your Backstage adoption journey but haven't mapped a Product Requirements Document (or PRD), don't panic! There is always time to do the foundational knowledge-building necessary to deploy something successful.
+
+## **2) They tie Backstage to a larger platform journey**
+
+Platform engineering has emerged in response to the growing complexity of cloud-native software architecture. Backstage has a huge role to play in implementing a platform strategy but its part of a larger story. Having buy-in from both higher ups and the teams tasked with platform goals is an essential step in successful Backstage adoption. Without the support at the top, it can be difficult to implement platforming as a priority within your organization.
+
+And by "the top", we don't necessarily mean your CTO needs to rubber stamp your Backstage POC. But it's important that higher-level Platform goals have been set among VPs and directors with the understanding that a well-constructed developer portal can be the catalyst to achieving not only better developer experience but broader cultural shifts.
+
+Having this kind of executive buy-in means more than just getting stakeholders on board with a portal build or clearing pathways towards Backstage adoption; it also means ensuring they understand the realities of your organization's journey.
+
+## **3) They prioritize developer experience**
+
+Having a dedicated developer experience or DevOps team tasked not only with building out a Backstage instance — but with leading adoption — is another big factor to success.
+
+Competing platforms are very common at big companies, with many teams doing different things or serving different parts of a business. But developer experience teams usually have a very clear mandate and are often one of the only commonalities between these competing teams. This team should have the bandwidth available to oversee the adoption process from start to finish, and partner with the right folks (research, design, internal comms and marketing) to create an effective adoption plan tailored specifically for a company's needs.
+
+If you don't have ‌established developer experience resources in place, then the questions the team leading the Backstage work needs to ask are "what are the common problems to be solved at a platform level?" and "once we've proved our initial use cases, how are we internally evangelizing this amongst our competing teams?"
+
+## **4) They collaborate with other platform teams**
+
+A developer experience team can not single-handedly transform an organization's development structures, processes, and culture. It requires collaboration with teams responsible for other aspects of the platform. Successful adopters collaborate with other teams to bring them along on the journey of improving developer experience. They use Backstage as an opportunity to foster their inner-source contribution practice by allowing multiple platform teams to contribute plugins to their portal.
+
+The developer experience team takes on the role of host in that collaborative process. They support other teams in integrating their features into the portal, provide guidance on best practices, and advocate for the needs of developers.
+
+## **5) They engage, learn, and grow with the community**
+
+One of the key benefits of building a developer platform based off an open source framework is leveraging the contributions and best practices from the community. The Backstage community is the largest gathering of developer experience practitioners in the world. There are now [thousands of adopters](https://github.com/backstage/backstage/blob/63aa3a65ec05f638ba76c06878d6635194620b34/ADOPTERS.md#L4) with a wealth of experience and best practices to learn from — and they are excited to share!
+
+By participating in the community, developer experience leaders can learn from their peers at other companies about strategies that work and can keep up with the latest features of the ever-evolving Backstage platform. They're aware of what solutions exist within the open source framework and plugin marketplace as well as what they may need to build in-house.
+
+In short, successful Backstage adopters engage within the Backstage community and their peer group to find solutions that fit their common challenges as well as their unique needs.
@@ -0,0 +1,205 @@
+---
+title: 'Expedia Group shares Backstage proof of value metrics 2.0'
+author: Guillermo Manzo, Expedia Group
+authorURL: https://www.linkedin.com/in/guillermomanzo
+---
+
+![backstage header](assets/2023-08-17/header.png)
+
+_Editor's Note: In this post, Expedia Group provides a follow-up to their initial Q4 2021 [post on how they measure Backstage proof of value](https://backstage.spotify.com/blog/measuring-backstage-proof-of-value-at-expedia/).
+We're grateful to the Expedia Group team for sharing their processes, revised proof of value metrics, and adaptations to their approach over time in hopes of providing a successful framework for the rest of the Backstage community._
+
+[Expedia Group's](https://expediagroup.com) mission is to power global travel for everyone, everywhere.
+This vision is made possible through Expedia Group's massive platform, which connects 168 million loyalty members, 50 thousand B2B partners, 3 million properties and 500 airlines, car rentals and cruise lines across the globe. In short, the scale of our platform is enormous, which means that we need to scale our engineering capabilities as well so we can continue to provide seamless experiences to our travelers and partners.
+
+{/* truncate */}
+
+In August 2020, we adopted Backstage to enhance our foundational platform capabilities and reduce developer friction in the process. Its framework proved scalable for us and as EG's platform evolved, so did our application of Backstage. Since our [initial share about our Backstage deployment](https://backstage.spotify.com/blog/measuring-backstage-proof-of-value-at-expedia/), we've continued to follow our process of:
+
+- Syncing Expedia Group's internal Developer Journey phases by key DevOps processes and Software Delivery Life Cycle (SDLC) milestones (POC, Alpha, Beta, etc).
+- Identifying Developer Jobs to be Done (JTBD) by our Internal Developer Journey phases
+- Aligning developer JTBD's to proof of value (PoV) metrics.
+
+In the diagram below, you can see how we distilled these processes into Backstage PoV metrics.
+
+![backstage pov metrics](assets/2023-08-17/table.png)
+
+To ground ourselves in the evolving developer and Backstage landscape at Expedia Group, we constantly ask ourselves, "How can we continue to show the value of Backstage to our customers and the Developer Community?" To fully answer this question, we adapted our initial proof of value metrics to reinforce our alignment to the current landscape of the Expedia Group developer journey.
+
+## Expedia Group proof of value metrics 2.0
+
+We are excited to share our PoV metrics because it affirms our investment in Backstage for Expedia Group's Backstage users and provides a compelling metrics-based answer on why more organizations should consider adopting it.
+
+As our Backstage application matured, we updated our PoV metrics and aligned our 2023 roadmap to reflect these changes. Below, we highlight key wins from 2022 and outline our long-term vision for each metric.
+
+<table>
+  <thead>
+    <tr>
+      <th>PoV Metric</th>
+      <th>Description</th>
+      <th>2022 Key Win(s)</th>
+      <th>Long-Term Vision</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>"Ship on Day One" / onboarding metrics</td>
+      <td>
+        <p>
+          A metric used to determine an engineer's readiness to develop at EG
+          during their onboarding process.
+        </p>
+        <p>
+          It measures the time from first commit to deploying code in
+          production, using a "Hello World Template"
+        </p>
+      </td>
+      <td>
+        <ul>
+          <li>
+            850+ engineers went through the “Ship on Day One” Bootcamp when
+            first joining Expedia Group
+          </li>
+          <li>
+            We had a success rate of ~95% of engineers completing bootcamp on
+            first try
+          </li>
+          <li>7,000+ components created or onboarded</li>
+          <li>4-min average per app creation/onboarding</li>
+        </ul>
+      </td>
+      <td>
+        <ul>
+          <li>
+            Develop full onboarding curriculum coverage for all critical
+            capabilities offered within EG - Example: performance and quality
+            management, pipeline management, etc.
+          </li>
+          <li>
+            Create an end-to-end guided tour of the EG Developer Journey w/
+            functional training
+          </li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Reduce context switching through integration with core EG capabilities
+      </td>
+      <td>
+        Through plugins, tool integration, reduces context-switching as
+        engineers will not need to toggle between multiple tools
+      </td>
+      <td>
+        <ul>
+          <li>
+            15%+ of internal developer tools are integrated within Backstage,
+            reducing the amount of context-switching needed
+          </li>
+          <li>
+            4000+ unique users using Backstage for ~20 min on average a day.
+          </li>
+        </ul>
+      </td>
+      <td>
+        <ul>
+          <li>
+            End-to-end integration with EG paved road tools and Backstage to
+            support increased developer productivity
+          </li>
+          <li>
+            Drive broader adoption to have all EG employees using Backstage to
+            manage their SDLC and to build internal UIs using plugins
+          </li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>Improve search results relevance</td>
+      <td>
+        Intuitive search capabilities to surface relevant Backstage content like
+        TechDocs, entities, tools, etc.
+      </td>
+      <td>
+        <ul>
+          <li>Enabled global search functionality throughout Backstage</li>
+          <li>
+            <p>Contributed to the open source Backstage Search platform</p>
+          </li>
+        </ul>
+      </td>
+      <td>
+        <ul>
+          <li>Engine optimization/ranking improvement</li>
+          <li>Visualize key search metrics to support improvements</li>
+          <li>Chat + AI integration with chat-based interfaces</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>Technical documentation reach</td>
+      <td>
+        Number of developers leveraging TechDocs for all services within EG
+      </td>
+      <td>
+        <ul>
+          <li>500+ services tied with TechDocs</li>
+          <li>50,000+ average monthly TechDoc views</li>
+        </ul>
+      </td>
+      <td>
+        <ul>
+          <li>
+            All Backstage entities leveraging TechDocs to enable a centralized
+            documentation portal integrated with the Software Catalog
+          </li>
+          <li>
+            Quality/governance and gamification to support users and
+            contributors
+          </li>
+          <li>
+            More TechDocs and mkdocs add-ons to compliment the core capabilities
+            and drive usability of documentation on Backstage
+          </li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>Developer Experience community engagement</td>
+      <td>Enhance Backstage through community engagement</td>
+      <td>
+        <ul>
+          <li>
+            Diverse contributions to Backstage open source focused on search and
+            discovery - 10+
+          </li>
+          <li>Community engagement through internal case studies, and blogs</li>
+        </ul>
+      </td>
+      <td>
+        <ul>
+          <li>
+            Continuous contributions to open-source Backstage, focused on plugin
+            administration, driving documentation adoption, and improved UX
+            around core capabilities
+          </li>
+          <li>
+            Strategic community engagements to enhance the platform's usability
+            and long-term confidence in adopting Backstage
+          </li>
+          <li>
+            Event participation and storytelling around EG's Backstage journey
+          </li>
+        </ul>
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+## YMMV: Your Metrics May Vary!
+
+Measuring the value of Backstage will vary depending on your organization's needs and priorities. As an early adopter of Backstage, we hope the Expedia Group PoV metrics provide a helpful framework for understanding how Backstage can be used to improve developer productivity, collaboration, and knowledge sharing.
+
+We look forward to sharing future updates with the community as we continue to embrace a continuous improvement approach to Backstage. If you missed it, you can read about where we started in our [initial proof of value metrics](https://backstage.spotify.com/blog/measuring-backstage-proof-of-value-at-expedia/) back in 2021.
+
+_Read more about Expedia's tech journey on [their Medium Blog](https://medium.com/expedia-group-tech)_
@@ -0,0 +1,60 @@
+---
+title: 'Adopter Spotlight: How Chicago Trading Company saved 18 months of developer effort with Backstage'
+author: Tiffany Cox, Spotify
+---
+
+![backstage header](assets/2023-09-29/header.png)
+
+**_TL;DR [Chicago Trading Company](https://www.chicagotrading.com/) (CTC) adopted Backstage ten months ago to help reduce onboarding frictions with their new cloud-based DevOps Kubernetes platform. Through templatization and open feedback loops, the team has conservatively saved 18 months of developer time to date with Backstage. We spoke with CTC DevOps engineer [Scott Kausler](https://github.com/scott-kausler) who shared the details of their onboarding journey, lessons learned, and insights for other Backstage adopters._**
+
+{/* truncate */}
+
+## Templates or the cluster didn't happen
+
+While mid-activation on a new cloud-based DevOps Kubernetes platform, Scott's team received early feedback that it was difficult to onboard teams onto this platform due to the breadth of requirements and new tools developers needed — from dependency management tools (such as Gradle, Conan, and Conda) to Docker/Kubernetes, Helm/FluxCD, and Vault. Not only were CTC developers required to learn new systems to build, package, and deploy their apps, in several cases even the code needed to be changed. There were also significant modifications required to existing tools such as Jenkins.
+
+Scott's team quickly recognized that this friction could lead to lower adoption and longer onboarding times to the new platform. So he started investigating solutions that would allow him to templatize these new services and create turnkey onboarding with less reference knowledge required.
+
+After exploring several service routes from managed to in-house/owned, CTC opted to use Backstage — already in POC for use of the [Software Catalog](https://backstage.io/docs/features/software-catalog/) — due to the [Software Templates](https://backstage.io/docs/features/software-templates/) plugin form-based input, UI/json-schema-form abilities, and its extensibility. Scott's team felt Backstage provided the most sustainable solution for growth amongst the multiple developer portal and templation options vetted and would help bridge the gap between UI-driven deployment and GitOps.
+
+## Early wins on documentation and onboarding
+
+The CTC DevOps team created a small special interest group to champion the developer portal build and quickly delved into the big issues impacting their developer experience. From there, the team began creating tasks and templates within Backstage.
+
+To start, Scott worked with end-user teams outside DevOps early in the process of documenting migration to the new DevOps Kubernetes platform services. When Scott wrote the onboarding documentation, he made it a point to pair with a developer on another team that would be using it. This approach provided him with a quality sounding board, great instantaneous feedback, and a sort of "beta developer" to test V1 documentation clarity., A few weeks later, another colleague on the same end-user team followed the documentation and she didn't reach out to Scott at all.
+
+After this early win, the team was ready for broad distribution. Partnering with the senior leadership team, Scott's team began onboarding teams to the new DevOps Kubernetes platform using the templates his team created in Backstage. At CTC, their Backstage instance is set up to automatically scan for deployments in Kubernetes; so if you're in Kubernetes, you're onboarded to Backstage.
+
+"Backstage made onboarding [to the new DevOps platform] not scary,"" Scott said. "Because now — all of a sudden — you have this recipe for how to do it, you don't have to jump through these hoops, the templates are there and ready for you. You choose what you want based on these templates we have available, and you're off and running on your own.""
+
+Scott's team monitored progress against their onboarding goals partially by how often the DevOps team was getting pinged for support and found that it has made support smoother. They can easily refer people to templates and repo standards instead of making them create something ad hoc.
+
+"It's really been cool seeing how that progressed. I even have a few teams that didn't talk to DevOps at all. They used a [template] and they have a service ready. We were actually pretty excited about that, because that means now we have a scalable tool able to onboard others onto our platform."" said Scott.
+
+Another exciting win for CTC was template additions generated outside the initial toolkit, which has eased the burden substantially for the DevOps team. They were able to create new templates to deploy against best practices such as a template for creating a brand-new Terraform module and Git repo or — Scott's favorite — a template that creates a Java repository along with Jenkins jobs for CI and the Flux CD config for deployment.
+
+"The template builds and auto-deploys a Docker image, so if you make a change to your mainline branch, then it will automatically build a new Docker image and deploy it to a Kubernetes cluster."" Scott said. "So within basically 10 minutes of you filling out a form, you actually have something deployed out to a Kubernetes cluster.""
+
+This process eased flows for both end-user devs and DevOps teams overall.
+
+## Measuring Backstage impact at CTC
+
+To calculate the impact of Backstage, Scott began with reviewing template types and assigning a weighted value to each based upon their perceived workload.
+
+At CTC, some templates create a repo, some templates create a repo with some code, some templates even go as far as creating a repo with code and all the prerequisites to deploy to Flux and Jenkins jobs. To be conservative, the highest weight Scott assigned to a template would be saving three days of developer time. Even with that conservative estimate, the figure came out to be a savings of 18 months in developer effort since Backstage was deployed ten months ago.
+
+For CTC, the journey with Backstage has just begun. They're now looking to drive more Catalog adoption and determine what custom plugins they need to build to better support their workflows.
+
+## The power of partnership (and good docs!)
+
+When asked about advice he has for other Backstage adopters, Scott talked about the DevOps team's comms strategy and ensuring end-user developers had pathways to provide feedback. In addition to the focus on templates for the new services, having both a dedicated Slack channel and open-door communication with the DevOps team helped reduce onboarding friction to the DevOps Kubernetes platform.
+
+Outside of that, he believes the approach to documentation is paramount. "Write your documentation from the perspective of, 'Hey, you have this task assigned to you to write a template, here are the exact steps you have to follow.'"" Scott said. "Think of it as a recipe. Removing your familiarity bias will help make this tool more useful for less familiar teams.""
+
+Finally, don't be afraid to step outside the core use cases when it comes to the Backstage framework and finding solutions to meet your needs.
+
+"Backstage gives you a lot of really easy to use features right out of the box. And one of the great things about open source is you can look at the code and see exactly what the behavior is and work within that behavior. But we've also developed our own processes for custom tasks because — at the end of the day — our platform has some very custom aspects to it."" Scott said.
+
+Interested in more stories from Backstage adopters? Check out these recent posts from [Stash](https://backstage.io/blog/2023/07/08/stash-adopter-post) and [Expedia Group](https://backstage.io/blog/2023/08/17/expedia-proof-of-value-metrics-2).
+
+Want to learn more about Backstage? Join our weekly [Office Hours](https://info.backstage.spotify.com/office-hours) and bring your burning questions.
@@ -0,0 +1,71 @@
+---
+title: 'Wrap up: BackstageCon ‘23, KubeCon + Cloud Native NA'
+author: Jorge Lainfiesta, Spotify
+authorURL: https://www.linkedin.com/in/jrlainfiesta/
+authorImageURL: https://avatars.githubusercontent.com/u/4451393?v=4
+---
+
+![BackstageCon ‘23, KubeCon + Cloud Native NA](assets/23-11-15/00-cover.png)
+
+tl;dr BackstageCon North America is officially in the books! We had a blast in Chicago talking about Backstage non-stop throughout the week at both BackstageCon and KubeCon. If you weren't able to join us, the [BackstageCon talks are available](https://www.youtube.com/playlist?list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc) for replay on the CNCF YouTube channel.
+{/* truncate */}
+
+Obviously we're biased, but Backstage was definitely one of the big topics at [KubeCon + CloudNativeCon North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) this year. Recently, the CNCF announced that Backstage was the [third fastest-growing project](https://www.cncf.io/blog/2023/10/27/october-2023-where-we-are-with-velocity-of-cncf-lf-and-top-30-open-source-projects/) of the year (up from the fifth last year). And you could confirm it with your own eyes during BackstageCon and KubeCon: hundreds of people flocked through the event, talks, and the project booth sharing their enthusiasm and asking more questions about the project.
+
+### BackstageCon: A growing community 
+
+With a whopping peak attendance of 400+ people, the crowd nearly doubled from last year,[ taking the center stage of the conference](https://www.forbes.com/sites/janakirammsv/2023/11/14/backstage-project-takes-center-stage-at-kubecon-north-america-2023/?sh=1972303a6539), as reported by Forbes. For some, BackstageCon was their first entry point into the community, but the event also boasted lots of  familiar faces, mostly from some of the most mature adopters such as Dynatrace, Lunar, and US Bank. We also got to hear from new voices in the community like Comcast and Grafana Labs.
+
+We hear a lot of great questions such as:
+
+- How do I make more developers use my developer portal?
+
+- Will generative AI take my Backstage instance to the next level?
+
+- What's all the fuss around the upcoming Declarative Integration in Backstage?
+
+The community got together to discuss these and more questions with exciting talks and debates. The talks were all recorded and are [up on YouTube](https://www.youtube.com/playlist?list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc), so make sure to check them out.
+
+**Driving Backstage adoption**
+
+Growing adoption was top of mind during BackstageCon. David Tuite, CEO of Roadie, shared the lessons learned from interviewing 20 adopters, which revealed that the Scaffolder was a prime place to get started when adopting Backstage, as it lets stakeholders get an easily measurable ROI.
+
+![Panel of Backstage adopters](assets/23-11-15/10-panel.jpg)
+
+Helen Greul, Head of Engineering for Backstage at Spotify, hosted [a panel discussion](https://www.youtube.com/watch?v=Iti5glzYOG8&list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc&index=10) with four adopters that are using Backstage at scale: Twilio, Lunar Bank, US Bank, and Expedia. The crucial role of Backstage in fostering inner sourcing and simplifying new hires onboarding were a few of the subjects covered in the panel.
+
+How adopters are using Backstage was also a highlight of the day. B3, Brazil's Stock Exchange, shared [how they're building their developer portal](https://www.youtube.com/watch?v=FyWCKIVYO7g&list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc&index=14). And from Grafana Labs, we heard how they're using [Backstage along Crossplane to drive GitOps](https://www.youtube.com/watch?v=q-JUWob69Hw&list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc&index=10).
+
+**What's next with Backstage?**
+
+The discussion on how Backstage is evolving was featured in a few talks, through live demos that — remarkably — did not go wrong even once! Ben ([benjdlambert](https://github.com/benjdlambert)) and Patrik ([Rugvip](https://github.com/Rugvip)), core maintainers, presented an introduction to the plans around [Declarative Integration](https://www.youtube.com/watch?v=8hVMNMXXN44&list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc&index=8), which will allow people to install plugins without dealing with TypeScript or React. On the other hand, Djamaile and Mitch, from Spotify, [introduced the upcoming Quickstart](https://www.youtube.com/watch?v=bUdaO9NKXJY&list=PLj6h78yzYM2PxiInfZi2OKu1KluNfbLtc&index=12), a tool from Spotify in private-beta that will allow anyone to get started with Backstage through a GUI in a few steps.
+
+**A thriving community**
+
+People gathered outside the conference room where BackstageCon was happening to catch up with each other and learn from the event sponsors. It was great to connect with everyone and talk about how everyone is using Backstage.
+
+![KubeCon Attendees](assets/23-11-15/20-booth.jpg)
+
+![Spotify at BackstageCon](assets/23-11-15/30-spotify-kubecon.jpg)
+
+### Mom, Backstage is not a phase
+
+The interest from the cloud-native community in Backstage did not waver this year. Instead, the Backstage booth in the KubeCon Project Pavillion saw a nonstop flux of visitors asking more about the project. There were three talks featuring Backstage during KubeCon.
+
+**Backstage talks during KubeCon NA '23**
+
+The first talk touching on Backstage of the schedule was Tim Hansen's ([timbonicus](https://github.com/timbonicus)) "Everything Is Code: Embracing GitOps at Spotify," who achieved rockstar status thanks to his phenomenal insights. The queue to ask questions after the talk's questions was surreal!
+
+![KubeCon Attendees](assets/23-11-15/40-tim-talk.jpg)
+
+Backstage maintainers Ben and Patrik addressed a full-room during their talk “Simplifying Backstage - Breaking the Code Barrier” in which they explained Declarative Integration, how it works and the expected migration path. Declarative Integration will enable adopters to install the plugins they use—and even customize them—without dealing with TypeScript or React.
+
+![KubeCon Attendees](assets/23-11-15/50-patrik-ben-full.jpg)
+
+And to close the event, Ritesh Patel, Nirmata and David Murphy, Upbound, introduced the BACK Stack, which stands for Backstage, Argo, Crossplane, and Kyverno. These four tools make up a powerful combo that can enable self-service workflows secure and scalable. After a great demo, the speakers presented a reference architecture that can help guide an approach to using Backstage to build your platform.
+
+![KubeCon Attendees](assets/23-11-15/60-back-stack.jpg)
+
+### See you next year!
+
+The next KubeCon Europe is scheduled for March 18-22 in Paris. We're looking forward to meeting you all there! [KubeCon EU](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/) and[ BackstageCon EU](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/backstagecon/) are accepting CFPs, submit your proposal now!
@@ -0,0 +1,24 @@
+---
+title: 'CVE-2024-26150: Keeping Backstage safe and secure'
+author: Ben Lambert, Spotify & Sam Nixon, Roadie
+---
+
+**TL;DR**: For the Backstage maintainers, ensuring that the project is secure for every adopter and end user is one of our top priorities.
+With the recent discovery of [CVE-2024-26150](https://www.cve.org/CVERecord?id=CVE-2024-26150), we've shipped fixes for versions > v1.15.0.
+Please update your Backstage instance.
+
+![Backstage Security Audit & Updates](assets/22-08-23/backstage-security-audit.png)
+
+{/* truncate */}
+
+Last week we were notified by [Roadie](https://roadie.io/) of a potential security vulnerability in the scaffolder that they had discovered during a third-party security audit.
+Roadie are running their scaffolder tasks in an isolated, ephemeral container to mitigate these kinds of issues, but as good citizens of the Backstage community, they alerted the Backstage maintainer team to make sure a fix was applied to the upstream project.
+Upon further investigation, it turned out that this was a more widespread issue with the `resolveSafeChildPath` utility from the `@backstage/backend-common` package, which is used to prevent path traversal exploits.
+This issue has now been fixed, and also backported to cover releases up to almost a year old.
+
+Please make sure that you have updated your Backstage instance to the latest v.1.23.2, or that you are using `@backstage/backend-common` `v0.21.1`, `v0.19.10`, or `v0.20.2`.
+If you are building backend plugins for Backstage and do any local file operations, make sure you use the `resolveSafeChildPath` utility, as this check is quite tricky to implement correctly 😊
+
+Thanks to Roadie and the team for reporting this issue, and making the Backstage community safe!
+
+For more information you can check out the [security advisory](https://github.com/backstage/backstage/security/advisories/GHSA-2fc9-xpp8-2g9h).
@@ -0,0 +1,62 @@
+---
+title: 'Backstage in Paris: Wrapping up BackstageCon and KubeCon + CloudNativeCon Europe 2024'
+author: André Wanlin, Spotify
+authorURL: https://github.com/awanlin
+authorImageURL: https://avatars.githubusercontent.com/u/67169551?v=4
+---
+
+**tl;dr**: And with that the first BackstageCon Europe comes to an end! The City of Light was good to Backstage with many great conversations at both BackstageCon and KubeCon + CloudNativeCon Europe 2024. If you weren't able to join, the CNCF has a great playlist of all the [BackstageCon talks](https://www.youtube.com/playlist?list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8) ready to go on YouTube. Check out some of the highlights below — then grab your popcorn and settle in!
+
+{/* truncate */}
+
+## Celebrating Four Years of Backstage
+
+<iframe
+  src="https://www.youtube.com/embed/NgYrweEbFNE"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+Wow! Has it already been four years since we open sourced Backstage? What an amazing run it's been so far. We continue to see the rate of pull requests steadily increase, the attendance and number of [special interest groups](https://github.com/backstage/community/tree/main/sigs) (SIGs) has grown, and more people are dedicating their time to new [project areas](https://github.com/backstage/community/tree/main/project-areas)!
+
+## Day 1: BackstageCon arrives in Europe
+
+This was the third BackstageCon and the first to take place outside North America. As you can see, it started with a bang.
+
+![BackstageCon Europe 2024](assets/2024-03-27/backstagecon-europe-2024.jpg)
+Via [Cloud Native Computing Foundation](https://www.flickr.com/photos/143247548@N03/albums/72177720315561784/) on Flickr
+
+With hosts like [Balaji Sivasubramanian](https://www.linkedin.com/in/balajisiva) (Head of Product Management, Red Hat) and [Helen Greul](https://se.linkedin.com/in/elenagreul) (Head of Engineering for Backstage, Spotify) [kicking things off](https://www.youtube.com/watch?v=PwVUW8is_WY&list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8&index=2), how could BackstageCon Europe not be a smashing success!
+
+More highlights from the day:
+
+- **Happy alignment:** Do you know when teams really need to be aligned? When they're working at a bank. [Thomas Grønbæk](https://www.linkedin.com/in/thomas-grønbæk/) (Senior Manager, Bankdata) gave an exciting talk about how “[Backstage Made 500+ Developers Happy](https://www.youtube.com/playlist?list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8)” in the highly regulated banking industry.
+- **Scaling up:** On the topic of scaling Backstage — a frequent subject on our [Discord](https://discord.com/invite/backstage-687207715902193673) — [Vincenzo Scamporlino](https://se.linkedin.com/in/vincenzoscamporlino) (Senior Software Engineer, Spotify) gave us [his recommendations](https://www.youtube.com/playlist?list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8) that will be helpful for many adopters who want to bring their instance to the next level.
+- **Lightning round:** There were several awesome [lightning talks](https://www.youtube.com/playlist?list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8) on varying topics — dynamic plugins, accessibility, OpenAPI tooling, and localization — that left you running to your laptop to learn more!
+- **Bonus:** Next door at Platform Engineering Day, [Samantha Coffman](https://uk.linkedin.com/in/samanthacoffman) (Senior Product Manager, Spotify) was representing Backstage in her talk "[Boosting Developer Platform Teams with Product Thinking](https://www.youtube.com/watch?v=Z_KCOcoliLI&list=PLj6h78yzYM2Me-TpMQFvCphDu_xm71ed_&index=12)".
+
+Beyond the talks, it was great to meet so many different members of the community, both those who've been using Backstage since the beginning as well as people who are just learning about internal developer portals and the open source platform. I had so many great conversations, I started to lose my voice — and it was only the first day.
+
+## Day 2: Onward to KubeCon + CloudNativeCon
+
+Backstage also took the spotlight at KubeCon. On Wednesday, project maintainers [Patrik Oldsberg](https://github.com/Rugvip) (Senior Engineer, Spotify) and [Ben Lambert](https://github.com/benjdlambert) (Senior Engineer, Spotify) gave us a great overview on “[The State of Backstage in 2024](https://www.youtube.com/watch?v=jBf3g79xcf4)” to a packed audience. Highlights from their talk include:
+
+- **New project areas:** There are now project areas for Community Plugins, Notifications, and the Scaffolder
+- **BEPs (Backstage enhancement proposals):** This is a new formal proposal process that allows a more iterative approach then trying to use GitHub Issues as RFCs
+- **Core framework:** They gave updates on the new auth changes to be secure by default, as well as updates on the New Backend System and New Frontend System
+- **The future:** Dynamic features! This allows you to install new plugins without having to rebuild
+
+## Day 3: Community, community, community!
+
+To top things off, during his [CNCF Keynote](https://www.youtube.com/watch?v=MICHGBAe8gc&list=PLj6h78yzYM2N8nw1YcqqKveySH6_0VnI0&index=161) on Thursday morning, [Taylor Dolezal](https://www.cncf.io/people/staff/?p=taylor-dolezal) (Head of Ecosystem, The Linux Foundation) shared what should be an unsurprising stat for members of the community: Backstage is the top CNCF project by end user commits!
+
+![CNCF Keynote, KubeCon + CloudNativeCon Europe 2024](assets/2024-03-27/cncf-keynote-kubecon-2024.jpg)
+Top 10 CNCF Projects by Number of End User Commits
+
+## Day 4: Au revoir! See you at the next one!
+
+![BackstageCon and KubeCon + CloudNativeCon Europe 2024](assets/2024-03-27/backstagecon-kubecon-europe-2024.gif)
+
+You can catch up on all the talks from [BackstageCon](https://www.youtube.com/playlist?list=PLj6h78yzYM2P4KPyeDFexAVm6ZvfAWMU8) and the rest of the week on the [CNCF's YouTube channel](https://www.youtube.com/@cncf/playlists). See you in Salt Lake City in November at KubeCon + CloudNativeCon North America!
@@ -0,0 +1,279 @@
+---
+title: 'Introducing the Backstage Community Plugins Repository'
+author: Ben Lambert, Spotify
+authorURL: https://github.com/benjdlambert
+authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
+---
+
+**tl;dr**: We've set up the new [community plugins repository](https://github.com/backstage/community-plugins), and have migrated most of the packages in the `plugins` directory of the main Backstage repository to their new home!
+
+For those who depended on these plugins, migrating is as simple as `yarn backstage-cli versions:bump` then `yarn backstage-cli versions:migrate`. If you're already on `1.26.1`, then be sure to run `yarn backstage-cli versions:bump --skip-migrate` then `yarn backstage-cli versions:migrate` to take advantage of the code reference replacement helpers.
+
+{/* truncate */}
+
+## The community plugins repo
+
+Some of you who have been around a while, or have seen our [Maintainer Track talks](https://www.youtube.com/watch?v=ONMBYnhxnNU) at KubeCon, might have seen [this RFC](https://github.com/backstage/backstage/issues/20266) which outlines some issues with the scale of the `backstage/backstage` monorepo, and us as maintainers being the de facto owners of all plugins without a [project area](https://github.com/backstage/community/blob/main/GOVERNANCE.md#project-area) or [plugin maintainer](https://github.com/backstage/community/blob/main/GOVERNANCE.md#project-area-maintainer).
+
+There was some great discussion in this issue, and some great ideas. One of the ideas was to create a dedicated home for community plugins, with all the burden of release tooling and workspace tooling already set up, which is a pretty big barrier for people wanting to create plugins for Backstage in their own organization or personal account. These plugins would then have the ability to release independently of the main monorepo, and have their own release cadence, which is something that we've been looking at exploring for a while.
+
+With Red Hat wanting to join forces and help get this set up, this is the path that we picked, and the last few months have been a lot of hard work from both sides getting this repository in shape and coming up with a deprecation plan for these plugins in the main repository.
+
+Would also like to give a shoutout to all the [Community Plugins project area](https://github.com/backstage/backstage/blob/master/OWNERS.md#community-plugins) maintainers, who have been helping get us to this state! [@vinzscam](https://github.com/vinzscam) [@tudi2d](https://github.com/tudi2d) [@bethgriggs](https://github.com/BethGriggs) [@kadel](https://github.com/kadel) [@awanlin](https://github.com/awanlin) 👏
+
+And now with the release of `1.26.3` there's a large amount of plugins from the main monorepo that have been migrated over to the new [community plugins repository](https://github.com/backstage/community-plugins). :tada:
+
+## The migration
+
+With the moving of these plugins, we thought it would also be a good time to move the `npm` scope, so that end users can differentiate between Backstage packages, and community-maintained packages. So the `@backstage-community` namespace was born!
+
+This makes migration a little tricky for end users, as there's going to be code references and `package.json` dependencies pointing to the older packages which are no longer going to be published.
+
+We've added some tooling into the `@backstage/cli` which is going to smooth the transition here. The last versions which are published under the `@backstage/` scope from the monorepo, will have a special field in the `package.json` with a hint to the CLI as to what this package is now called.
+
+The CLI will then be able to replace these references inside the `./src` folder of your codebase, and update your `package.json` dependencies to the new `@backstage-community` scope.
+
+You can migrate today by running the following:
+
+```bash
+# < 1.26.1
+yarn backstage-cli versions:bump
+yarn backstage-cli versions:migrate
+
+# 1.26.1
+yarn backstage-cli versions:bump --skip-migrate
+yarn backstage-cli versions:migrate
+```
+
+From this latest `1.26.3` release and onwards, the `backstage-cli versions:bump` command will automatically check for moved packages, so you shouldn't have to worry about running this every time.
+
+## Help! My plugin has been moved!
+
+No stress! If you were a `CODEOWNER` of the code in the monorepo, these permissions will be migrated over to the [community plugins repository](https://github.com/backstage/community-plugins) so you should still have access to the code. And now you're in charge of releasing your own plugin! 🚀 You can do that by following the same flow from the monorepo, with changesets and merging the `Version Packages (My Plugin)` PR.
+
+Please reach out to us on [Discord](https://discord.com/invite/backstage-687207715902193673) if you have any issues! We're looking forward to working together in the new space!
+
+## What's moved?
+
+We've taken a pretty big chunk of the plugins from the main monorepo and moved them over to the new repository. There could be more plugins over time that are moved, or even ones that we promote back to the main monorepo.
+
+<details>
+  <summary>
+    Here's a list of plugins that have been moved with this release
+  </summary>
+
+- `@backstage/plugin-adr-backend`
+
+- `@backstage/plugin-adr-common`
+
+- `@backstage/plugin-adr`
+
+- `@backstage/plugin-airbrake-backend`
+
+- `@backstage/plugin-airbrake`
+
+- `@backstage/plugin-allure`
+
+- `@backstage/plugin-analytics-module-ga`
+
+- `@backstage/plugin-analytics-module-ga4`
+
+- `@backstage/plugin-analytics-module-newrelic-browser`
+
+- `@backstage/plugin-apache-airflow`
+
+- `@backstage/plugin-apollo-explorer`
+
+- `@backstage/plugin-azure-devops-backend`
+
+- `@backstage/plugin-azure-devops-common`
+
+- `@backstage/plugin-azure-devops`
+
+- `@backstage/plugin-azure-sites-backend`
+
+- `@backstage/plugin-azure-sites-common`
+
+- `@backstage/plugin-azure-sites`
+
+- `@backstage/plugin-badges-backend`
+
+- `@backstage/plugin-badges`
+
+- `@backstage/plugin-bazaar-backend`
+
+- `@backstage/plugin-bazaar`
+
+- `@backstage/plugin-bitrise`
+
+- `@backstage/plugin-cicd-statistics-module-gitlab`
+
+- `@backstage/plugin-cicd-statistics`
+
+- `@backstage/plugin-circleci`
+
+- `@backstage/plugin-cloudbuild`
+
+- `@backstage/plugin-code-climate`
+
+- `@backstage/plugin-code-coverage-backend`
+
+- `@backstage/plugin-code-coverage`
+
+- `@backstage/plugin-codescene`
+
+- `@backstage/plugin-cost-insights-common`
+
+- `@backstage/plugin-cost-insights`
+
+- `@backstage/plugin-dynatrace`
+
+- `@backstage/plugin-entity-feedback-backend`
+
+- `@backstage/plugin-entity-feedback-common`
+
+- `@backstage/plugin-entity-feedback`
+
+- `@backstage/plugin-entity-validation`
+
+- `@backstage/plugin-explore-backend`
+
+- `@backstage/plugin-explore-common`
+
+- `@backstage/plugin-explore-react`
+
+- `@backstage/plugin-explore`
+
+- `@backstage/plugin-firehydrant`
+
+- `@backstage/plugin-fossa`
+
+- `@backstage/plugin-gcalendar`
+
+- `@backstage/plugin-gcp-projects`
+
+- `@backstage/plugin-git-release-manager`
+
+- `@backstage/plugin-github-actions`
+
+- `@backstage/plugin-github-deployments`
+
+- `@backstage/plugin-github-issues`
+
+- `@backstage/plugin-github-pull-requests-board`
+
+- `@backstage/plugin-gitops-profiles`
+
+- `@backstage/plugin-gocd`
+
+- `@backstage/plugin-graphiql`
+
+- `@backstage/plugin-graphql-voyager`
+
+- `@backstage/plugin-ilert`
+
+- `@backstage/plugin-jenkins-backend`
+
+- `@backstage/plugin-jenkins-common`
+
+- `@backstage/plugin-jenkins`
+
+- `@backstage/plugin-kafka-backend`
+
+- `@backstage/plugin-kafka`
+
+- `@backstage/plugin-lighthouse-backend`
+
+- `@backstage/plugin-lighthouse-common`
+
+- `@backstage/plugin-lighthouse`
+
+- `@backstage/plugin-linguist`
+
+- `@backstage/plugin-linguist-common`
+
+- `@backstage/plugin-linguist-backend`
+
+- `@backstage/plugin-microsoft-calendar`
+
+- `@backstage/plugin-newrelic-dashboard`
+
+- `@backstage/plugin-newrelic`
+
+- `@backstage/plugin-nomad`
+
+- `@backstage/plugin-nomad-backend`
+
+- `@backstage/plugin-octopus-deploy`
+
+- `@backstage/plugin-opencost`
+
+- `@backstage/plugin-periskop-backend`
+
+- `@backstage/plugin-periskop`
+
+- `@backstage/plugin-playlist-backend`
+
+- `@backstage/plugin-playlist-common`
+
+- `@backstage/plugin-playlist`
+
+- `@backstage/plugin-puppetdb`
+
+- `@backstage/plugin-rollbar-backend`
+
+- `@backstage/plugin-rollbar`
+
+- `@backstage/plugin-sentry`
+
+- `@backstage/plugin-shortcuts`
+
+- `@backstage/plugin-sonarqube-backend`
+
+- `@backstage/plugin-sonarqube-react`
+
+- `@backstage/plugin-sonarqube`
+
+- `@backstage/plugin-splunk-on-call`
+
+- `@backstage/plugin-stack-overflow-backend`
+
+- `@backstage/plugin-stack-overflow`
+
+- `@backstage/plugin-stackstorm`
+
+- `@backstage/plugin-tech-insights-backend-module-jsonfc`
+
+- `@backstage/plugin-tech-insights-backend`
+
+- `@backstage/plugin-tech-insights-common`
+
+- `@backstage/plugin-tech-insights-node`
+
+- `@backstage/plugin-tech-insights`
+
+- `@backstage/plugin-tech-radar`
+
+- `@backstage/plugin-vault-backend`
+
+- `@backstage/plugin-vault-node`
+
+- `@backstage/plugin-vault`
+
+- `@backstage/plugin-xcmetrics`
+
+</details>
+
+## What's next?
+
+There's going to be a little bit of time now in this migration period where there's going to be issues and pull requests not in the right place, and we're going to do our best to transfer issues to the community plugins repository instead. We will shortly be removing the code for these plugins from the main monorepo as it now has a new home in the community plugins repository.
+
+We're also going to be looking at bringing in some more of the great tooling from the `backstage/backstage` monorepo into the community plugins repository to help out with more automation for dependency bumps, etc.
+
+## How can I get involved?
+
+If you're interested in getting involved with the community and helping us maintain this repository, please reach out either on [Discord](https://discord.com/invite/backstage-687207715902193673) or in an issue on the [community repository](https://github.com/backstage/community).
+
+If you're wanting to contribute some plugins to Backstage, the community plugin repository is open for business :tada: and we're looking forward to seeing what you come up with! Head over to the [community plugins docs](https://github.com/backstage/community-plugins/tree/main/README.md) to get started creating your own workspace!
+
+Thanks!
@@ -0,0 +1,134 @@
+---
+title: '1,186 days with Backstage: A journey through the eyes of a developer'
+author: Camila Loiola, Spotify
+authorURL: https://github.com/camilaibs
+authorImageURL: https://avatars.githubusercontent.com/u/6290749?v=4
+---
+
+**TL;DR** There is no shortage of content that discusses the benefits that Backstage brings to organizations (and if you want to read more on that, you can just click [here](https://engineering.atspotify.com/?c=backstage), [here](https://backstage.io/blog), or [here](https://backstage.spotify.com/discover/blog/)). But I want to share what it did for me, a developer here at Spotify. And not just what it did, but how I’ve used Backstage to help me achieve goals at each stage of my journey at Spotify — from my first day as a brand new employee to today, my 1,186th day as a contributor.
+
+![Backstage Engineer Journey](assets/2024-06-27/backstage-engineer-journey.svg)
+
+{/* truncate */}
+
+## A new joiner with a need to get up to speed
+
+My first six months after joining Spotify, I was eager and determined to get up to speed so that I’d be able to start contributing as soon as possible. I set goals for myself and developed concrete activities to reach those goals:
+
+### Goal 1: Learn the internal process to develop, test, secure, and publish applications.
+
+Understanding a company’s practices and technologies is absolutely essential to getting started, no matter what company you join.
+
+At Spotify, we use a Backstage plugin called [TechDocs](https://backstage.io/docs/features/techdocs/) to document [Golden Paths](https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/) — tutorials that teach us the development process for each role at the company — for web, backend, mobile, data science development, and so on.
+
+With Backstage, I had an understanding of how to put things into production, even before I had my first task. I used the web Golden Path to guide me on setting up my environment; creating and structuring projects; and building, publishing, and monitoring production applications.
+
+> **Reflection:**<br/>_“Is it easy for newly hired engineers to settle in and find information critical to getting started?”_
+
+With Backstage, new hires can quickly and easily understand the nuances of their particular positions and be ready to deliver their first task to production.
+
+### Goal 2: Find and read the documentation and source code of the products my team maintains.
+
+Having familiarized myself with the ways of working, it was a good time to understand my specific team’s business domain. This meant spending time reading through documentation and source code to find out the value we provide to our customers. In the past, I would spend time with colleagues for knowledge transfer as opposed to learning on my own and consult my colleagues if needed.
+
+With the [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/), I could easily browse the components my team owns, find the source repo and documentation.
+
+> **Reflection:**<br/>_“Are you able to accomplish this without asking a teammate for help?”_
+
+Use Backstage to get to know the products that you will be working on, and use your peers' time to ask contextualized clarifying questions instead.
+
+### Goal 3: Figure out where my team fits within the company and with other teams.
+
+It was also crucial for me to build a network from the beginning so that I could explore collaboration opportunities.
+
+At Spotify, we use a Backstage plugin called Band Manager which displays information about each team and allows employees to see not only their own teams but also those within the same product area and company domain.
+
+> **Reflection:**<br/>_“Are you going to need a one-on-one with your manager to ask this question?”_
+
+Backstage helped me find the teams close to mine, and I took the opportunity to develop my network and talk to members from those teams to understand our boundaries and gather ideas to contribute.
+
+It’s pretty likely that you can relate to one or more of these examples, so use Backstage to support your goals from the very beginning!
+
+Now let’s move on to the middle of the journey, between six months and two years into life at the company.
+
+## Two years in — from contributor to leader
+
+After about two years of contributing to my team’s products, I began to look for opportunities to actually lead initiatives and create a new project. One of my objectives was to ensure I was upholding Spotify’s standards and choosing Spotify-approved technologies.
+
+My goal has changed from being a contributor to being the driver, i.e., from doing what I was told to do to defining what needed to be done. I “started driving initiatives” and “supporting my peers” in order to position myself as a reference in my technical area.
+
+### Goal 1: Quickly spin up new projects using the most appropriate technology stack.
+
+At Spotify, we expect engineers to use technologies approved by our [Tech Radar](https://backstage.io/blog/2020/05/14/tech-radar-plugin/#what-is-tech-radar) and follow the best quality standards.
+
+To do so, we use a plugin called [Scaffolder](https://backstage.io/docs/reference/plugin-scaffolder) (aka Software Templates), which allows engineers to create templates for setting up new projects. Templates automate actions such as creating repositories, allocating resources, registering in the catalog, configuring deployments, and connecting to other internal systems.
+
+> **Reflection:**<br/>_“Do you need to create a ticket to get these things done before you even start coding? And is there a lot of time spent looking for boilerplate code to start a new project and connecting it to other internal systems?"_
+
+Backstage enabled me to quickly create and publish a new backend that can deploy code to production with just a few clicks, so I could focus on building solutions for the business. I could use Backstage to easily build the right thing. Instead of spending time scaffolding projects, I could spend my time writing code.
+
+### Goal 2: Create products that have a healthy operational state and are easy to evolve.
+
+Keeping track of vulnerabilities and letting my team know about technical debts were other parts of my routine.
+
+With the [Soundcheck plugin](https://backstage.spotify.com/marketplace/spotify/plugin/soundcheck/), developers can easily configure checks to verify component health, such as reliability and other development and operational standards. We also have an internal Vulnerabilities plugin that displays fragilities in our components, so we can continuously prevent security issues.
+
+> **Reflection:**<br/>_“Do you know which components owned by your team follows best practices and standards and which ones are lagging behind?”_
+
+Backstage helped me gather and better understand our technical debts, enabling me to effectively prioritize during our team’s planning, visualize which entities were compliant to our team’s best practices, and identify which ones needed improvement.
+
+### Goal 3: Respond effectively to incidents within our components or their dependencies.
+
+If you’ve been with a company for around two years, you might have had to manage incidents in one way or another — this was certainly the case for me. A typical problem was to determine if the issue is with the service that I own or a downstream dependency.
+
+Spotify has adopted [PagerDuty](https://backstage.spotify.com/marketplace/pagerduty/plugin/pagerduty/) to manage on-call rotation and to track incident resolutions. We integrated the PagerDuty plugin in Backstage, so we see who is on call and if there is an incident for a particular component.
+
+> **Reflection:**<br/>_“When a downstream dependency is failing, do you know who to contact?”_
+
+In the event that one of our components starts failing, I check whether any of the systems we rely on is experiencing an incident, and Backstage again makes it easy for me to see the dependencies between systems and the status of those dependencies.
+
+## Today and beyond!
+
+With three-plus years of experience at Spotify, I’m taking on more and more responsibility by embracing challenges outside my team’s scope, coordinating cross-team collaboration, attending and facilitating courses for personal development and growth, and mentoring my peers.
+
+Backstage has allowed me to drive my pursuit of growth in a multitude of ways.
+
+### Goal 1: Stay in the flow and optimize my time management practices.
+
+At this point, finding time to focus — with all that I have on my plate — while also making time to learn new concepts is both fundamental and challenging for me.
+
+Spotify encourages its developers to manage their time in order to stay in the flow and to turn to the tools that help them prioritize effectively and focus on their work.
+
+> **Reflection:**<br/>_“How do you surface the most important notifications and avoid non-emergency distractions?”_
+
+Backstage has been instrumental in helping me stay in the flow by surfacing the most critical notifications and call to actions related to cost spikes, security vulnerabilities in my homepage.
+
+### Goal 2: Platformize our solutions and reuse code to boost my productivity.
+
+Reinventing the wheel is a common problem in software development and Spotify is no different.
+
+Autonomous teams tend to prioritize speed over reuse and develop the same solutions in different places (1) as it unblocks the delivery for their team and (2) there is no easy way to discover if a particular functionality has been developed in another part of the company and if it can be reused for their requirement.
+
+> **Reflection:**<br/>_“Do you find yourself wondering if someone else already did it before starting a task?”_
+
+With the [Backstage Search plugin](https://backstage.io/docs/features/search/), I can discover solutions to reuse, find inspiration, and also share what I’ve built for other developers to discover and use.
+
+### Goal 3: Grow my career and take steps toward the next level.
+
+I began looking for opportunities to gain new experiences and responsibilities while expanding my knowledge.
+
+With Spotify’s [Skill Exchange plugin](https://backstage.spotify.com/marketplace/spotify/plugin/skill-exchange/) for Backstage, engineers temporarily embed with a different team, allowing them to partake in work outside their day-to-day. The plugin also helps engineers connect with mentees or mentors that align with their skills profiles.
+
+> **Reflection:**<br/>_“Are you able to find opportunities that match your current skill set?”_
+
+With Backstage, I've applied for an embed to experience working with another team and eventually make a permanent move to this new team, calling it my new home.
+
+I am passionate about teaching and eager to share my knowledge to help others. Through Skill Exchange, I found a mentee, a colleague transitioning into engineering, and I am helping them take their first steps.
+
+## What’s next?
+
+Backstage is highly customizable, and with its extensive plugin ecosystem, engineers can use it strategically to achieve their goals.
+
+No matter what point in your journey you are, you can find value with [Backstage](http://backstage.io). It was, after all, made by engineers for engineers. 💚
+
+Special thanks to [Stanley Nicholl](https://github.com/stanley-nicholl), [Patrik Oldsberg](https://github.com/Rugvip), [Vincenzo Scamporlino](https://github.com/vinzscam), [Mihai Tabara](https://github.com/MihaiTabara), [Emma Indal](https://github.com/emmaindal), [Raghunandan Balachandran](https://github.com/soapraj) for all of their support.
@@ -0,0 +1,95 @@
+---
+title: 'Adopter Spotlight: Level-up developer experience with observability and security in context'
+author: Johannes Bräuer, Dynatrace
+authorURL: https://github.com/johannes-b
+authorImageURL: https://avatars.githubusercontent.com/u/729071?v=4
+---
+
+**TL;DR**
+To enhance the developer experience, Dynatrace adopted Backstage as its central developer portal and enhances Backstage entities with real-time data. This decision, along with the symbiosis between the Dynatrace platform and Backstage, has unlocked two significant opportunities.
+
+- First, centralizing all development-related artifacts and democratizing ownership have reduced onboarding time for our teams.
+- Second, we enhanced the developer experience by integrating observability and security data into Backstage, offering seamless entry points to Dynatrace for in-depth analysis.
+
+![Dynatrace adopting Backstage](assets/2024-09-24/com0027.Dynatrace.Adopter.png)
+
+{/* truncate */}
+
+## Why and how Dynatrace rolled out Backstage
+
+A few years ago, Dynatrace developers worked with large monolithic repositories to develop functionality for our platform’s agent and server sides. The server component was particularly large, consisting of 260 Gradle projects in a single repository. This setup centralized development processes for the developers, making it easier for them to push the code while versioning, delivery, and hotfixes were handled automatically. However, maintaining the speed and manageability of these processes required a lot of effort.
+
+Dynatrace decided to move towards the current Dynatrace platform model as the next evolutionary step of our product. This decision led to an architectural change of splitting the monolithic repository into multiple projects. The platform is designed to enable the development of apps on top of platform capabilities to unlock faster innovations and decouple them from the release cycles of other components. Based on this decision, it became apparent that the number of platform components and individual apps would increase significantly, eliminating the option of a single repository to unify all processes. Besides, the risk of increasing cognitive load in software development was high due to development being spread across multiple touchpoints, a challenge discussed in research for years ([Sweller, 1988](<https://doi.org/10.1016/0364-0213(88)90023-7>), [Robert, 2008](https://dl.acm.org/doi/10.5555/1388398)). Consequently, the need to standardize project creation became crucial to ensure corporate governance and compliance even before the first commit was pushed.
+
+<!-- References:
+[^1]: John Sweller, Cognitive load during problem solving: Effects on learning, Cognitive Science, Volume 12, Issue 2, 1988, Pages 257-285, ISSN 0364-0213, https://doi.org/10.1016/0364-0213(88)90023-7.
+[^2]: Robert C. Martin Series, Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series), 2008, ISBN 9780132350884.
+-->
+
+Therefore, the Dynatrace Platform Engineering team initiated a project to standardize and simplify the process for starting service or application development. This effort was initially named “project initializer” and launched around the same time Backstage joined the CNCF. Although the platform engineering team saw initial success with the project initializer, we quickly realized that there was a greater demand for centralizing development activities and providing appropriate guidelines. For example, we noted that the complexity of integrating new code had shifted from the build phase to the deployment phase, transferring relatively complex integration tasks from continuous integration to continuous deployment. Overall, the main requirements and focal points were:
+
+- **Ownership**: Who is responsible for which service or app? Who owns infrastructure resources?
+- **Documentation**: Where is the documentation of a service or app?
+- **CI/CD view**: How does the build pipeline in GitHub/Jenkins progress, and what about the ArgoCD deployment?
+- **Dependency management**: Do we know which APIs are used?
+- **Observability and security**: Where is a service deployed, and is it healthy and secure?
+
+For more details on Dynatrace's adoption of Backstage, please watch the recording, [How We Made Backstage Improve Developer Efficiency of 1000+ Engineers](https://www.youtube.com/watch?v=0or5K_3HieA), BackstageCon, November 6, 2023 in Chicago. Illinois.
+
+## Quick wins with ownership democratization and self-service templates
+
+The discussion on whether to make, buy, or adopt led us to heavily favor Backstage as the chosen solution for our internal developer platform (IDP). We have successfully integrated Backstage within Dynatrace, marking our early wins. This was accomplished by linking it to our internal team management solution. Feeding this data into Backstage resolved the previously lacking transparency concerning the responsibilities and ownership of services and infrastructure. Furthermore, we have contextualized Stack Overflow and CI/CD solutions with entities monitored by Backstage to fulfill developers' requests for a unified view.
+
+Next to establishing a solid software catalog view, providing self-service templates for project and infrastructure creation—initially a focus of the original developer experience—has also been incorporated into Backstage. This enhancement allows the use of a comprehensive set of templates for bootstrapping platform services or applications across different tool stacks. Ultimately, developers can effortlessly use a template to create a ready-to-use repository with observability and security pre-configured.
+
+## Static model enrichment with real-time observability and security
+
+After addressing ownership, documentation, and a centralized CI/CD view, our developers highlighted the necessity of accessing real-time data about their services and applications within the Backstage service catalog. This need arose from the understanding that integrating a code change can be optimally evaluated on a deployed version of their service alongside related components. Specifically, the developers were interested in seeing at a high level:
+
+- Where specific versions of services are deployed,
+- How their services perform in the hardening phase and production environments,
+- Which inbound and outbound dependencies their service has,
+- Whether any problems, security vulnerabilities, or SLO breaches are related to their service, and
+- Which recent error logs have been collected.
+
+The open source community already developed a Backstage plugin capable of fetching Dynatrace problems and synthetics into Backstage. However, we chose to develop a new plugin that works with the new Dynatrace platform API. Additionally, it was necessary to support Kubernetes use cases by default to offer, for example, deployment overviews out-of-the-box. Based on the feedback from developers, we identified four essential requirements.
+
+### Coverage of the software development lifecycle
+
+Observing the software development lifecycle necessitates consolidating all development and delivery phases. In Dynatrace, monitoring the development stage is distinct from rolling out new versions to the hardening and production stages. Nonetheless, developers desire an end-to-end view from development to production. To support this, the plugin allows connections to multiple Dynatrace environments to retrieve data for the various rollout phases.
+
+### Kubernetes observability
+
+When using the Backstage Kubernetes plugin, an annotation is required to surface your Kubernetes components as part of an entity (for more information, please refer to [Backstage documentation](https://backstage.io/docs/features/kubernetes/configuration/#surfacing-your-kubernetes-components-as-part-of-an-entity)). The Dynatrace plugin utilizes this convention to automatically populate monitoring data from Kubernetes deployments into the deployment overview in Backstage. Therefore, additional configuration is unnecessary to enrich Backstage entities with real-time observability data from Kubernetes, as shown below. Additionally, deep links open Dynatrace analysis views for more contextual details.
+
+![Kubernetes deployment overview](assets/2024-09-24/backstage_dynatrace_plugin_K8s.png)
+
+### Reliability and security in context
+
+While Kubernetes observability was requested to be provided out of the box, we quickly realized that developers prefer to define the insights they want to see by themselves. To remain flexible and to reduce the customization effort required from the platform engineering teams, the plugin allows for the definition of custom queries within the `config.yaml` file. The Backstage `config.yaml` file requires special attention since platform teams use this file to standardize entity specifications, while developers use it to customize their Backstage views. After releasing this new functionality, we observed developers moving in two distinct directions:
+
+- Querying quality gate validation results of a new version they’re developing
+
+![Release validation overview](assets/2024-09-24/backstage_srg_validations.png)
+
+- Fetching runtime security vulnerability information across different stages
+
+![Security vulnerabilities in context](assets/2024-09-24/backstage_catalog_security_vulnerabilities.png)
+
+### Error logs at hand
+
+Developers love logs. Direct access to logs, especially error logs, was a crucial requirement for the plugin. Our developers want to see the current number of error logs accompanied by a direct link to the raw log line, which provides significant value in problem triaging and fixing. With the plugin, we offer a high-level overview of log statistics, with the rich analysis capabilities of Dynatrace available at a single click.
+
+## Conclusion
+
+To enhance the developer experience, Dynatrace adopted Backstage as its central developer portal and enhances Backstage entities with real-time data. This decision, along with the symbiosis between the Dynatrace platform and Backstage, has unlocked two significant opportunities.
+
+First, centralizing all development-related artifacts and democratizing ownership have reduced onboarding time for our teams. Although it might seem that onboarding time is only relevant for new developers, it is also important when developers move to a different team, pick up a service or application they haven’t worked on for a while, or replace their laptops. Moreover, a low onboarding time is crucial when quickly kicking off work on a new service or solution app. This became a necessity with the new Dynatrace platform.
+
+Second, we enhanced the developer experience by integrating observability and security data into Backstage, offering seamless entry points to Dynatrace for in-depth analysis. This improvement was crucial as we noted a shift in integration tasks from build to development time, necessitating insights into a later phase of the software lifecycle for our developers. In essence, end-to-end validation of code changes could no longer be accomplished with build pipelines—either in Jenkins or GitHub—but required deployment in production-like environments that facilitate real-world interaction with other components. Consequently, real-time observability data from these environments must be relayed to the developer.
+
+## What`s next?
+
+Backstage is a crucial element for Dynatrace's developer experience, providing out-of-the-box core functionality for every developer and supporting extensibility where needed. Our Backstage extension is maintained as an open-source project and is available for every Backstage user. Don't hesitate to utilize it or to contribute: https://github.com/Dynatrace/backstage-plugin
+
+If you have a great Backstage story to tell, please share your experience with us to the variety of use case areas.
@@ -0,0 +1,200 @@
+---
+title: 'Backstage in Salt Lake City: Highlights from BackstageCon and KubeCon + CloudNativeCon North America 2024'
+author: André Wanlin, Spotify & Camila Loiola, Spotify
+---
+
+![Beaver in front of snowcapped mountains peeking over a banner that reads BackstageCon and KubeCon + CloudNativeCon North America 2024, Salt Lake City](assets/2024-12-09/backstagecon-kubecon-2024-salt-lake-city.png)
+
+**tl;dr:** Salt Lake City did not disappoint! Backstage continues to be at the forefront of many conversations being had at BackstageCon and across KubeCon + CloudNativeCon. If you weren't able to join us, all the [BackstageCon talks][yt] are available for replay on YouTube. Read on for the highlights — plus, photos of super cute pups — as a treat! 🐕
+
+[yt]: https://www.youtube.com/playlist?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+{/* truncate */}
+
+## What everyone was talking about at BackstageCon🦫
+
+![Speakers on stage at BackstageCon North America 2024](assets/2024-12-09/kc24slc-spotify-backstagecon.jpg)
+
+[BackstageCon](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/co-located-events/backstagecon/) featured a day of talks tailored to the diverse Backstage community. Whether you were an evaluator, adopter, integrator, builder, or an innovator, there was something valuable for everyone. Here were the big themes from the day.
+
+### Evaluating Backstage ROI
+
+- Olivier (Avalia Systems) presented what makes digital portals [helpful to C-level executives][olivier].
+
+- Himanshu (Harness) shared strategies for adopting Backstage in ways that drive [meaningful value for engineers][himanshu].
+
+- Eric (Quantum Metric) explained [how startups can benefit][eric] from what big techies have been contributing to Backstage.
+
+- Tom (Spotify) shared how developer productivity furthers Spotify’s mission to [empower creators][tom] and what the future holds for Backstage.
+
+[olivier]: https://youtu.be/kb3F98fKvaQ?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[himanshu]: https://youtu.be/FACtDHQvNf0?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[eric]: https://youtu.be/9qPsuMSw_dM?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[tom]: https://youtu.be/AU9BwkRMmMY?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+### Sharing Backstage adoption journeys
+
+- A panel discussion — featuring practitioners from Adobe, American Airlines, JPMorgan Chase, Red Hat, and Roku — showcased [real-world adoption stories from large companies][panel], spanning various stages of Backstage usage. Hear how devs at American Airlines can use Scaffolder to get a new site provisioned and deployed on the .aa.com domain in 20 minutes. “I’ve done it in seven,” said Jay Cox, principal engineer. “It used to take a month.”
+
+- Lizzie (Booz Allen Hamilton) explored corporate barriers to Backstage adoption and lessons learned along the way, including how to navigate [cultural tensions][lizzie] and the importance of listening to your devs, in order to bring the latest advancements in developer experience to a government consulting company that’s going on “110 years young”.
+
+- Amber and Daniel (Liatrio) elaborated on why [automated governance][amber] belongs inside Backstage portals to facilitate centralized compliance — so your devs don't get held up from going to prod by unforeseen checks.
+
+[panel]: https://youtu.be/DAjhjS2Xg4Q?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[lizzie]: https://youtu.be/RTYVmMbkdNA?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[amber]: https://youtu.be/GaGbjMJCcRU?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+### Maintaining a Backstage instance
+
+- Djamaile and Mitch (Spotify) provided [actionable tips][djamaile] for managing Backstage instances, including how to keep them aligned with the latest open source features.
+
+- Ashna and Mesut (Booking.com) showed how to customize your instance to mirror your company's unique identity and how to leverage reusability for a [smoother user experience for your devs][ashna].
+
+- Paul (Red Hat) presented a [platform engineer’s POV][paul] of what it means to maintain a Backstage instance.
+
+- Yishai (Linear B) spoke about how to approach software engineering intelligence (SEI) and developer productivity metrics inside Backstage, including [do’s and don’ts][yishai].
+
+[djamaile]: https://youtu.be/dbLqwEVl52U?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[ashna]: https://youtu.be/QV40Yz2i3jQ?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[paul]: https://youtu.be/CtbfN--mJkE?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[yishai]: https://youtu.be/mxVW2AGoI3A?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+### Building with Backstage core features
+
+- Avantika and Emma (Spotify) walked us through the advantages of the new backend system, recommending [best practices for plugin development][tika] and showcasing why migrating to this updated version is an extensibility game changer.
+
+- Will and Ryan (Microsoft) shared how Software Catalog and Templates provide the model to [build visualizations][will] of your cloud native applications.
+
+[tika]: https://youtu.be/n7GUlLHN2tQ?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[will]: https://youtu.be/U2-Lo-yuvdc?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+### AI-powered Backstage plugins and modules
+
+Innovative use cases featuring AI integration took center stage.
+
+- Niall (Amazon Web Services) demonstrated how to [interact with plugin services][niall] using artificial intelligence prompts.
+
+- Ben (Red Hat) outlined [broader AI integrations][ben] to enhance Backstage, sparking exciting possibilities for the future.
+
+The sessions offered a wealth of knowledge and inspiration, underscoring the versatility and potential of Backstage for organizations at every level. The Backstage booth was hopping all day long as community members and cloud natives took advantage of being able to ask the experts questions and learn more about the project.
+
+[niall]: https://youtu.be/DCXzCrIDOAs?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+[ben]: https://youtu.be/cl6E0A5R_nI?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+## Backstage at the big show: KubeCon⎈ + CloudNativeCon☁️
+
+![A view of the crowd entering KubeCon as seen from the top of the convention center escalator](assets/2024-12-09/kc24slc-cncf-entrance.jpg)
+📸 _[See more KubeCon photos from the CNCF’s Flickr album](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/) →_
+
+My friends, what an intense conference!
+
+Over the course of three packed days, there were a bunch of activities, including talks, a kiosk, and a Contribfest, all centered around Backstage.
+
+### Maintainers take the stage
+
+![Backstage maintainers presenting in a ballroom](assets/2024-12-09/kc24slc-spotify-maintainers.jpg)
+
+This may be old hat for those who are regular KubeCon attendees, but it’s still pretty exciting to catch up on all the Backstage updates straight from the core maintainers. Spotify’s Ben Lambert and Patrik Oldsberg were in the spotlight in Ballroom C addressing an attentive crowd of Backstage adopters, users, and fans.
+
+Highlights of their maintainers talk include:
+
+- **Project updates:** Yarn 4 is now the default, the new built-in event bus has arrived, and the (New) Backend System is now 1.0!
+- **Security Audit:** Another security audit has been completed with the helpful support of the CNCF
+- **Scaffolder updates:** Addition of Form Decorators and support for Retries!
+- **New Frontend System:** Focus on the plugin builder experience!
+
+Watch their entire talk — “[How to Expand Your IDP: The New Building Blocks of Backstage](https://youtu.be/BzPCJMQH8tg?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X)” — for all the details.
+
+### Toyota and Akamai in the house
+
+![A packed ballroom with Backstage displayed on two large screens](assets/2024-12-09/kc24slc-cncf-toyota.jpg)
+📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/)
+
+There were great talks from Backstage adopters during KubeCon, too. Toyota and Akamai packed the rooms with their Backstage knowledge.
+
+- “[Shifting Gears: Leveraging CNCF Tools to Streamline Operations at Toyota Connected][toyota]”: Benson and Rob talk about failures and successes adopting CNCF tools (including ArgoCD and Backstage) to unify operations, streamline workflows, and enhance cross-team collaboration.
+
+- “[From Chaos to Calm: Building a Unified and Scalable CI/CD Pipeline at Akamai][akamai]”: Tomer dives into development efficiency and how you can “conquer cloud-native deployments by adding the right tools, such as Argo Rollouts and Backstage”.
+
+[toyota]: https://youtu.be/4w_AC81_GZM?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X&t=856
+[akamai]: https://youtu.be/RFVB9CEEn1I?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X
+
+### And the award goes to…
+
+![Adobe accepts the CNCF Top End User Award on the Keynote stage at KubeCon + CloudNativeCon North America 2024](assets/2024-12-09/kc24slc-cncf-adobe.jpg)
+
+📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/)
+
+Adobe gave a shoutout to Backstage from the Keynote mainstage on Thursday morning when they (spoiler alert) [accepted the CNCF’s Top End User Award][keynote], thanking the cloud native community and all the projects that they use.
+
+But Adobe isn’t just a Backstage adopter, they are a model citizen — giving back to the community through their example, having “developed a reference architecture for its IDP, built using Argo, Backstage, Helm, and Kubernetes, which other organizations can use as a template for designing and implementing their systems”.
+
+As Taylor Dolezal, head of ecosystem at the CNCF, [says][announcement]: “Their commitment to nurturing technological excellence and developer experience exemplifies what we hope to see in the end user ecosystem. It’s not just about tool adoption or code contributions — it’s about synthesizing these learnings into assets that empower others in their cloud native journeys.”
+
+Way to go, Adobe!
+
+[keynote]: https://youtu.be/p7J0lAU3AWo
+[announcement]: https://www.cncf.io/announcements/2024/11/14/cncf-presents-top-end-user-award-to-adobe/
+
+### A bustling CNCF project pavilion
+
+![A volunteer wearing an “Ask me about Backstage” T-shirt talks to a visitor at the project kiosk](assets/2024-12-09/kc24slc-cncf-kiosk.jpg)
+
+📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/)
+
+The CNCF Projects Pavilion was buzzing with activity all week, and the Backstage kiosk was a hub of excitement. Attendees stopped by with a mix of curiosity and enthusiasm, sparking conversations that highlighted the dynamic nature of our community.
+
+Curious visitors asked, “What is Backstage all about?”, while adopters sought personalized advice on customizing Backstage for their specific company needs. Contributors dropped in to say, “Hey, you reviewed my pull request!” And professionals proudly shared their achievements as Backstage experts — in fact, now there’s a way to make that expertise official — by becoming a [Certified Backstage Associate (CBA)](https://training.linuxfoundation.org/blog/just-launched-certified-backstage-associate-cba/), a new certification that was just launched by the CNCF and The Linux Foundation.
+
+Developers eager to give back to the community came to learn how to start contributing, and some of the kindest Backstage fans simply stopped by to say, “Thank you”. Their gratitude and encouragement are a powerful reminder of why we do what we do.
+
+Every interaction in person made the day special, and we wrapped up with a deep sense of fulfillment and pride in how far Backstage has come. Here's to building an even brighter future together!
+
+## Contribfest! It’s All About Community👩‍💻
+
+![Various developers and their laptops participating in the Backstage Contribfest](assets/2024-12-09/kc24slc-spotify-cncf-contribfest.gif)
+
+📸 Spotify, [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/)
+
+On Thursday, the first-ever Backstage Contribfest session took place — hosted by Yi Cai and Paul Schultz from Red Hat, and André Wanlin, Patrik Oldsberg, and Ben Lambert from Spotify.
+
+Participants who hadn't yet used or contributed to Backstage eagerly joined the project's contributors community and were eager to help. Together with the group, experienced Backstage engineers stepped in to assist attendees — whether troubleshooting environment setup or explaining how specific framework and plugin features are implemented. It was a great example of a community coming together to support learning and contribution.
+
+The energy in the room, with 60 enthusiastic participants, was absolutely electric! It was amazing to see ideas bouncing around, impromptu collaboration happening at every corner, and a shared passion for advancing the Backstage project.
+
+Among the great contributions to come out of this event are:
+
+- [Add Pagination to Tech Docs Table](https://github.com/backstage/backstage/pull/27694)
+- [Add Home Page Quick Start Card](https://github.com/backstage/backstage/pull/27705)
+- [Truncate commit message to first newline](https://github.com/backstage/community-plugins/pull/2012)
+
+A heartfelt thank you to everyone who joined us — it’s your talent and collaborative spirit that truly define the Backstage community. This event was a powerful reminder that it’s the people behind the project who make Backstage what it is today 💚.
+
+And if you missed out on the fun, it's never too late to join the Backstage community. Just follow along with the [Contribfest slide deck](https://static.sched.com/hosted_files/kccncna2024/53/KubeCon-ContribFest-Backstage-NA-2024.pdf) to get started with contributing!
+
+## Bonus pups!🐕
+
+Nothing improves developer experience like hanging out with some fluffy friends. So please enjoy these photos from KubeCon’s “[Pet A Pup](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/with/54155382123)” station.
+
+(All 📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720321905538/with/54155382123). Please note: the last pup is not a pup.)
+
+![A labrador retriever pup in the middle of three people calmly getting pets](assets/2024-12-09/kc24slc-cncf-bestpup1.jpg)
+The best labrador-retriever pup graciously accepting pets from the cloud native community.
+
+![A fluffy white pup staring at the camera surrounded by attendees](assets/2024-12-09/kc24slc-cncf-bestpup2.jpg)
+The best fluffy white pup surrounded by admirers.
+
+![A lanky racing pup getting pet on the face](assets/2024-12-09/kc24slc-cncf-bestpup3.jpg)
+The best racing-style pup getting face scritches.
+
+![A yellow pup squinting while getting pets from an attendee in a yellow shirt](assets/2024-12-09/kc24slc-cncf-bestpup4.jpg)
+The best yellow pup getting pets from his twinsie.
+
+![A fluffy cat getting pets.](assets/2024-12-09/kc24slc-cncf-bestpup5.jpg)
+See? Not a pup. But did get pets.
+
+[You, too, can give these pups some love](https://www.therapyanimalsutah.org).
+
+## Cheerio! We’ll see you in London!💂
+
+And that’s a wrap on Salt Lake City! [Join us in London](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) in April for more community-building fun at BackstageCon and KubeCon + CloudNativeCon Europe 2025!
@@ -0,0 +1,33 @@
+---
+title: The 2024 Backstage Security Audit
+author: Patrik Oldsberg, Spotify
+authorURL: https://github.com/Rugvip
+---
+
+**TL;DR** Backstage’s security posture remains strong! Today, we’re releasing the report from the second independent security audit of the Backstage project.
+
+![Backstage Security Audit & Updates](assets/22-08-23/backstage-security-audit.png)
+
+As an [Incubating project](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/) within the [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF), Backstage is fortunate enough to take advantage of sponsored continuous security audits. The [Open Source Technology Improvement Fund](https://ostif.org/) (OSTIF) sponsors the audits as part of its ongoing efforts to secure the open source software ecosystem, and the audit itself was performed by [X41 D-Sec](https://x41-dsec.de/), who also performed the first audit. Our goal with the audit was to re-evaluate and further improve Backstage’s security posture, focusing on the core Backstage framework and plugins.
+
+{/* truncate */}
+
+## Report Findings and Fixes
+
+The security audit and improvements concluded on October 16. The audit findings totalled three high and one medium severity vulnerability, alongside seven side findings with no direct security impact. All main findings were remedied in the [Backstage 1.31 release](https://backstage.io/docs/releases/v1.31.0), while the majority of the side findings were addressed by the [1.32 release](https://backstage.io/docs/releases/v1.32.0). For details on all findings, see the [full audit report](assets/2024-12-17/X41-Backstage-Audit-2024.pdf).
+
+We are happy to see that there are no repeated vulnerabilities, perhaps in part due to our new [secure coding practices](https://github.com/backstage/backstage/blob/master/SECURITY.md#coding-practices) following the previous audit, as well as the introduction of the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model). While there was a path traversal vulnerability that was discovered in the TechDocs backend, this was more specific and related to remote paths, rather than the local filesystem. We chose to handle this as an isolated fix as there are no other occurrences of this pattern that we are aware of.
+
+The [previous security audit](https://backstage.io/blog/2022/08/23/backstage-security-audit/) highlighted the need for Backstage to have its own built-in protection, to be secure by default. This, as well as the need for more robust service-to-service auth, was addressed earlier this year through the new auth system, in [1.24](https://backstage.io/docs/releases/v1.24.0#breaking-auth-improvements) and following releases. The new auth system was in scope for this new security audit, and no findings were made in that area.
+
+One area with findings in both audits is the way that the auth plugin backend handles sign-in of users. This is a complex area that can often be a source of friction for the adoption experience of Backstage. As part of this audit we have made several updates especially to the documentation for sign-in resolvers, but this remains an area where it is hard to find a solution that is both simple and secure. Of course we err on the side of caution and have updated our documentation to be more strict. We will continue to explore options for improvements to the sign-in system to keep it both simple and secure out of the box, but in the meantime be sure to read the documentation section [sign-in identity and resolver](https://backstage.io/docs/auth/identity-resolver) as you are setting up Backstage.
+
+We are happy with the results of this security audit, it is yet another way in which we see the continuing maturity of the Backstage projects. On behalf of the Backstage maintainers and community: thanks to the CNCF, OSTIF, and X41 D-Sec for the opportunity to improve the project.
+
+## Links and References
+
+- [X41 Blog Post](https://x41-dsec.de/security/research/job/news/2024/12/16/backstage-review-2024/)
+- [OSTIF Blog Post](https://ostif.org/backstage-audit-complete/)
+- [Full Audit Report](assets/2024-12-17/X41-Backstage-Audit-2024.pdf)
+- [Backstage Threat Model](https://backstage.io/docs/overview/threat-model)
+- [Backstage Security Policy](https://github.com/backstage/backstage/blob/master/SECURITY.md)
@@ -0,0 +1,176 @@
+---
+title: "Backstage Wrapped 2024: The year's Top 5 milestones and highlights"
+author: Patrik Oldsberg, Spotify & Ben Lambert, Spotify
+---
+
+![Bowie the Backstage Beaver in an astronaut outfit riding a firecracker surrounded by fireworks exploding with stats: 210+ open source plugins, 1.6k contributors, 60k total contributions](assets/2024-12-18/wrapped2024-top5.png)
+
+It was another banner year for everyone's favorite platform for improving developer experience — and we're closing 2024 out with a bang🧨🎆. To give you a snapshot of how the Backstage community is doing, we're counting down our Top 5 milestones for the year (plus a few other highlights sprinkled in). To start things off, let's see what you and your 1,616 fellow contributors were up to last year…
+
+{/* truncate */}
+
+---
+
+## 5️⃣: 60k+ Contributions from a Global Community of Very Busy Beavers🦫
+
+<iframe
+  src="https://www.youtube.com/embed/U0m3TJ-2cFw"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+_Behold! Every commit to the Backstage open source project this year — can you
+see your name in there?_
+
+As we shared last month when we kicked off [BackstageCon North America](https://youtu.be/OfavM6j4Z5o?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X&t=112), the Backstage community hit a new milestone this year — reaching 60,000 total contributions (discussions, issues, and pull requests) to the project since Spotify donated it to the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/projects/backstage/) in 2020. Busy Backstage beavers, indeed.
+
+And the community was as active as ever in 2024 — if you hit play on the visualization above, you can see all 12.3k commits from the year being made. (Though, instead of busy beavers, it's more like a giant cluster of space spiders shooting galactic laser webs. Pew pew!)
+
+### The most commits of any CNCF project, by a lot
+
+![Taylor Dolezal presenting a chart showing the Top 10 CNCF Projects by Number of End User Commits on the Keynote stage at KubeCon Europe 2024](assets/2024-03-27/cncf-keynote-kubecon-2024.jpg)
+
+Speaking of commits, rewinding back to [KubeCon + CloudNativeCon Europe](https://backstage.io/blog/2024/03/27/backstagecon-kubecon-24/) in March gives us another way to visualize the mightiness of the Backstage community.
+
+From the keynote stage in Paris, Taylor Dolezal, the head of ecosystem at The Linux Foundation, [presented a chart](https://www.youtube.com/watch?v=MICHGBAe8gc&list=PLj6h78yzYM2N8nw1YcqqKveySH6_0VnI0&index=161) showing the "Top CNCF Projects by Number of End User Commits", using data from the previous four months.
+
+At the top of the chart, a conspicuous blue bar — more than twice the length as the next longest one — had Taylor noting that, among CNCF projects, Backstage was "rocketing into the forefront when it comes to end user contributions".🚀🚀🚀
+
+### Our first Contribfest!
+
+![A room full of developers working together at the first Backstage Contribfest](assets/2024-12-18/wrapped2024-contribfest.jpg)
+
+What's better than ogling a nifty visualization or nerding out on a good bar graph? Feeling the buzz of those contributions in person.
+
+Just last month at KubeCon + CloudNativeCon North America, maintainers from Spotify and Red Hat cohosted the first-ever [Backstage Contribfest](https://backstage.io/blog/2024/12/09/kubecon-slc-24/#contribfest-its-all-about-community). We packed the room with engineers obsessed with developer experience and let them loose on a curated list of issues. The session was good, old-fashioned coding fun — devs sharing ideas and solving problems together — and we look forward to doing it again with all of you.
+
+If you missed it and want to get in on the action, just follow along with the [Contribfest slide deck](https://static.sched.com/hosted_files/kccncna2024/53/KubeCon-ContribFest-Backstage-NA-2024.pdf). Or meet us in 💂‍♂️London in April for [BackstageCon](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/backstagecon/) and [KubeCon + CloudNativeCon Europe 2025](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)!
+
+---
+
+## 4️⃣: 210+ Open Source Plugins (and Counting)🧩
+
+![Bowie the Backstage Beaver surrounded by icons for plugins: Argo CD, Datadog, GitHub Actions, Grafana, Jira, and Kubernetes](assets/2024-12-18/wrapped2024-4-plugins.gif)
+_Just a few of the plugins built by the Backstage community_
+
+### Plugins, plugins, plugins
+
+Everybody's building them, everywhere you look. We see official plugins from popular third-party service providers ([DX](https://backstage.spotify.com/marketplace/dx/plugin/dx/), [PagerDuty](https://pagerduty.github.io/backstage-plugin-docs/index.html), [Rootly](https://backstage.spotify.com/marketplace/rootly/plugin/rootly/)), in-house plugins going open source (like these from [DAZN](https://github.com/backstage/community-plugins/blob/main/workspaces/github-pull-requests-board/plugins/github-pull-requests-board/README.md), [Keyloop](https://github.com/backstage/community-plugins/blob/main/workspaces/azure-devops/plugins/azure-devops/README.md), and [SeatGeek](https://github.com/seatgeek/backstage-plugins)), essential plugins built and maintained by ecosystem champions and supporters ([AWS](https://github.com/awslabs/backstage-plugins-for-aws), [GCP](https://github.com/googlecloudplatform/google-cloud-backstage-plugins), [Roadie](https://roadie.io), [Spotify](https://backstage.spotify.com)), as well as creative and [useful](https://github.com/procore-oss/backstage-plugin-announcements) plugins from contributors and enthusiasts from all corners of the Backstage community.
+
+### A yearlong plugin party
+
+In 2024, the plugin ecosystem continued to expand — with about a hundred new plugins being introduced over the year and many others getting big updates.
+
+SeatGeek started the plugin party in February❄️ at a Backstage Community Session where they [demoed](https://www.youtube.com/watch?v=CRw0m3J11Bc&t=526s) five of the seven plugins they've open sourced, including their [Awards Plugin](https://github.com/seatgeek/backstage-plugins/tree/main/plugins/awards) and [Entity Scaffolder Plugin](https://github.com/seatgeek/backstage-plugins/tree/main/plugins/entity-scaffolder-content).
+
+By spring🌷, new plugins for [Linkerd](https://github.com/backstage/community-plugins/tree/main/workspaces/linkerd) and [Black Duck](https://github.com/backstage/community-plugins/tree/main/workspaces/blackduck/plugins/blackduck) had sprung onto the scene.
+
+During the summer☀️, the official [PagerDuty](https://pagerduty.github.io/backstage-plugin-docs/index.html) plugin received updates that made it a breeze to configure existing PagerDuty services and also added support for multiple PagerDuty accounts in the same Backstage instance.
+
+By fall🍁, some of the most-used plugins — including plugins for [Argo CD](https://www.npmjs.com/package/@roadiehq/backstage-plugin-argo-cd), [Datadog](https://www.npmjs.com/package/@roadiehq/backstage-plugin-datadog), [GitHub Actions](https://github.com/backstage/community-plugins/tree/main/workspaces/github-actions/plugins/github-actions), [Grafana](https://github.com/backstage/community-plugins/blob/main/workspaces/grafana/plugins/grafana/docs/index.md), [Jira](https://github.com/AxisCommunications/backstage-plugins/tree/main/plugins/jira-dashboard), [Kubernetes](https://backstage.io/docs/features/kubernetes/), and [Tech Radar](https://github.com/backstage/community-plugins/tree/main/workspaces/tech-radar/plugins/tech-radar) — had already been updated to support the very latest versions of the Backstage framework's [New Frontend System](https://backstage.io/docs/releases/v1.30.0) and [New Backend System](https://github.com/backstage/backstage/issues/24493). (Thanks to the teams at Roadie and Spotify for helping to kickstart a new era of easy-to-install-and-configure plugins!)
+
+And last but not least, AWS just released the [AWS Config catalog plugin for Backstage](https://github.com/awslabs/backstage-plugins-for-aws/blob/main/plugins/core/catalog-config/README.md) — a great new plugin that makes it easy for their customers to ingest AWS resources into the Backstage Software Catalog.
+
+Have a plugin you'd like to show off and share with the community? Sign up to demo it at one of our monthly [Backstage Community Sessions](https://github.com/backstage/community/tree/main/backstage-community-sessions#readme)!
+
+### A shiny new plugins repo
+
+Alongside all this plugin-building action, there was also plenty of plugin-migrating action. In April, community plugins moved to a repo they could call their own — the [Backstage Community Plugins Repository](https://backstage.io/blog/2024/04/19/community-plugins/).
+
+With release tooling, workspace tooling, and migration guide all included, [the new repo](https://github.com/backstage/community-plugins) gives plugin owners a leg up on building and shipping plugins. Now you can release independently of the main monorepo, at your own release cadence.
+
+Special thanks go to Red Hat as maintainers of the [community plugins project area](https://github.com/backstage/backstage/blob/master/OWNERS.md#community-plugins) and to everyone who provided feedback on the migration plan. With the new community plugins repo now established, it will be fascinating to see what new, innovative plugins we'll be talking about this time next year. [Go start building](https://backstage.io/docs/plugins/)!
+
+---
+
+## 3️⃣: 278 Companies Listed in ADOPTERS.md💚
+
+![Bowie the Backstage Beaver wearing a I heart Backstage T-shirt and hugging the ADOPTERS.md file](assets/2024-12-18/wrapped2024-3-adopters.gif)
+_We 💚 all our Backstage adopters_
+
+### One thing in common
+
+At the top level of the `backstage/backstage` GitHub repo is a little file called [ADOPTERS.md](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) that contains the names of hundreds of companies who have adopted Backstage and added themselves to the list.
+
+There are companies from all over the world on that list, of all shapes and sizes, including cloud natives and cloud newbies, brand new startups and fast-growing scale-ups, airlines, banks, and healthcare companies, along with online retailers, gaming studios, digital entertainment platforms, and hundred-year-old government consulting firms.
+
+But no matter how different their industries, their business models, their engineering cultures, or their tech stacks, when they join that list of public Backstage adopters, they all share one thing in common: their commitment to improving developer experience as the surest path to innovation. So while the file is just a simple table, it's also an invitation for other companies to join in that commitment.
+
+This year, the following companies added themselves to ADOPTERS.md, bringing the total to 278 public Backstage adopters — let's give a big welcome to: [Anuclei](https://anuclei.com), [Fortnox](https://www.fortnox.se), [Wefox](https://www.wefox.com), [Aurora Innovation](https://aurorainnovation.com), [ENSEK](https://ensek.com/), [OP Financial Group](https://www.op.fi/op-financial-group), [Scania](https://www.scania.com), [Senora.dev](https://senora.dev), [Covestro](https://www.covestro.com), [Grupo OLX](https://www.olx.com.br/), [DPG Media](https://www.dpgmediagroup.com), [Baloise](https://www.baloise.ch), [Cigna](https://www.cigna.com/), [Evernorth](https://www.evernorth.com/), [Infobip](https://www.infobip.com/), [CloudScript](https://www.cloudscript.com.br/), [Alauda](https://www.alauda.io/), [New10](https://www.new10.com/), [Tele2 Kazakhstan](https://tele2.kz/), [Altel Digital](https://digital.altel.kz/), and [Axelerant](https://www.axelerant.com/).
+
+### Plus, thousands more in the wild
+
+The companies on that list represent just a fraction of the active Backstage adopters out there — we know there are thousands more of you. How do we know?
+
+We've seen your [amazing talks](https://backstage.io/blog/2024/12/09/kubecon-slc-24/#toyota-and-akamai-in-the-house). We've read your [insightful blog posts](https://backstage.io/blog/2024/09/24/dynatrace-adopter-spotlight/). We've heard your [engaging adoption journeys](https://www.youtube.com/watch?v=nZuEMojNi9A&t=565s). We've enjoyed your [automation workshops](https://philips-labs.github.io/automation-workshop/). And we've celebrated your [well-deserved awards](https://backstage.io/blog/2024/12/09/kubecon-slc-24/#and-the-award-goes-to).
+
+There are so many different kinds of adopters out there, and so many different ways to share with the community — and we love to see it all.
+
+### Support the community! Add yourself to ADOPTERS.md
+
+If you work somewhere that's using Backstage, don't be shy. Jump into 2025 by [adding your company](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) to the public adopters list. We love to see you there, and it's a simple but meaningful way to contribute back to the community.🙏
+
+---
+
+## 2️⃣: 2 Legit 2 Quit: The Official Backstage Certification Launches🎓
+
+![Bowie the Backstage Beaver wearing glasses and holding a book pointing at the badge for Certified Backstage Associate](assets/2024-12-18/wrapped2024-2-cba.gif)
+_Time to make it official_
+
+With the Backstage community growing across so many companies, the need for Backstage experts grows, as well. Now there's an easy way to spot 'em.
+
+### Become a Certified Backstage Associate (CBA)
+
+Last month, the CNCF and Linux Foundation Education [announced](https://training.linuxfoundation.org/blog/just-launched-certified-backstage-associate-cba/) the launch of a new certification: [Certified Backstage Associate (CBA)](https://training.linuxfoundation.org/certification/certified-backstage-associate-cba/). So now you can make your expertise for "building on top of the most popular open source IDP" official:
+
+> Designed for IT engineers, developers, platform engineers, and other IT professionals, the CBA proves you have the mindset and skills to work in and build Backstage tools that improve performance and drive innovation benefiting your career, your team and your organization.
+
+It's a huge help for Backstage experts and practitioners, as well as all those Backstage adopters (and future adopters) who prioritize developer experience and productivity amid the increasing complexity of modern software development.
+
+As Pia Nilsson, head of platform developer experience at Spotify, says in the announcement, "With the CNCF's Certified Backstage Associate program, companies now have a way to identify and tap into that expertise, while helping to contribute back to the growing Backstage community."
+
+### Enroll today!
+
+The program to become a Certified Backstage Associate is live, so you can [enroll today](https://training.linuxfoundation.org/certification/certified-backstage-associate-cba/)!
+
+And if you want to see what domains the 90-minute, multiple-choice CBA exam covers — and hear more about how "earning a Backstage certification can be a career game-changer for developers and IT engineer's careers" — makes sure to read the full announcement on the [The Linux Foundation Education blog](https://training.linuxfoundation.org/blog/just-launched-certified-backstage-associate-cba/).
+
+---
+
+## 1️⃣: Version 1.0 of the Future of Backstage🎉
+
+![The top half of Bowie the Backstage Beaver sticking out of the top of a portal, the beaver's bottom half sticking out of the bottom of another portal, with Backend System 1.0! written in between the floating halves](assets/2024-12-18/wrapped2024-1-backend.gif)
+_And the number one milestone of 2024 is…Backend System 1.0!_
+
+As we saw in the video visualizing a year's worth of commits, there were a lot of changes to Backstage in 2024 — including improved documentation, the introduction of the Framework SIG ([join a Backstage special interest group](https://github.com/backstage/community/tree/main/sigs#sig)!), Yarn 4 as the default, our second security audit, a built-in event bus, major new features to the Scaffolder UI (form decorators and retries — shout-out to [Bogdan Nechyporenko](https://github.com/backstage/backstage/blob/master/OWNERS.md#scaffolder) from Bol.com!), big strides in the plugin-building experience in the [New Frontend System](https://youtu.be/BzPCJMQH8tg?list=PL8iP9yIjU0Q3UUDXdAoCaTC4Ci8asWg-X) — and much, much more. And that was just in the last six months.
+
+But the 1.0 release of the New Backend System was the biggie of the year.
+
+### The "New Backend System" becomes _the_ backend system
+
+After months of testing, feedback, and improvements with the community, the New Backend System landed as a [stable v.1.0 release](https://backstage.io/docs/releases/v1.31.0/) in September — marking the beginning of a new era for building for Backstage.
+
+The New Backend System (which shall henceforth be known as "_the_ backend system") brings a host of improvements to the way that backends and their features are constructed. Instead of the old convention-based structure that could lead to migration pains, features now fit together with dependency injection, like a jigsaw puzzle, while leveraging powerful core services and extending each other dynamically with additional behaviors.
+
+And this is just scratching the surface of it. To see what else is new in the backend system — check out [the docs](https://backstage.io/docs/backend-system/)!
+
+We are very excited about this important milestone after a long period of development and refinement together with our passionate community, and hope that you will find it as refreshing and simple yet powerful as it was envisioned to be. This also lays the foundation for us being able to continue iterating at a high pace without incurring undue end user breakages during upgrades.
+
+### How to migrate your backends and plugins
+
+We have documentation for both [migrating backends](https://backstage.io/docs/backend-system/building-backends/migrating) and [migrating plugins](https://backstage.io/docs/backend-system/building-plugins-and-modules/migrating). If you haven't migrated already, we encourage you to do so as soon as possible, so that all adopters and end users can begin to unlock the benefits of the new system!
+
+And keep the feedback coming, either on the community [Discord](https://discord.gg/backstage-687207715902193673) or through [issues](https://github.com/backstage/backstage/issues/new/choose) on GitHub. If you're looking for a way to help, take a look at these open issues in the [backstage](https://github.com/backstage/backstage/issues/26353) and [community plugins](https://github.com/backstage/community-plugins/issues/1176) repos about deprecating old backend capabilities of already migrated plugins. To the future we go!
+
+---
+
+## We won! Hooray to the community! 🏆
+
+![Bowie the Backstage Beaver standing bashfully on a podium with 2024 flashing behind in big letters](assets/2024-12-18/wrapped2024-infoworld.gif)
+
+To cap off the year, last week Backstage won the "[InfoWorld 2024 Technology of the Year Award for Software Development: Platforms](https://www.linkedin.com/posts/backstage-from-spotify_infoworlds-2024-technology-of-the-year-award-activity-7273338824561246208-KY-w/)"!
+
+Congrats to [all the project maintainers](https://github.com/backstage/backstage/blob/master/OWNERS.md), the CNCF, and everyone in the Backstage community — including all our contributors, adopters, partners, and end users. It's great to see developer experience recognized for the critical role it plays in innovation.
+
+Let's do it again next year!
@@ -0,0 +1,118 @@
+---
+title: 'Backstage in London: Highlights from BackstageCon and KubeCon + CloudNativeCon Europe 2025'
+author: André Wanlin, Spotify
+authorURL: https://github.com/awanlin
+authorImageURL: https://avatars.githubusercontent.com/u/67169551?v=4
+---
+
+![Highlights from BackstageCon and KubeCon + CloudNativeCon Europe 2025, including scenes from London and links to recordings of all the Backstage sessions.](assets/2025-04-29/backstagecon-kubecon-2025-london.png)
+
+Wow, London sure didn't hold back! [Five years][birthday] after the open source framework was released, Backstage was clearly on people's minds — from those new to internal developer portals to those who have been contributing since the earliest days. Conversations about Backstage spanned from BackstageCon to the rest of KubeCon + CloudNativeCon Europe, which had a record-setting attendance of nearly 13,000 people. But if you couldn't make it, then settle in, prepare a spot of tea, and read on for highlights. Then head over to the Backstage Community's YouTube channel to [catch up on all the great Backstage talks][playlist] you missed.
+
+[birthday]: https://www.youtube.com/watch?v=74ayHL1WHiE&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+[playlist]: https://www.youtube.com/playlist?list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+{/* truncate */}
+
+## London called — the Backstage Community answered
+
+![The crowds at KubeCon + CloudNativeCon Europe 2025 set a new record for attendance](assets/2025-04-29/kc25london-crowds-entering.jpg)
+📸 _[CNCF][flickr]_
+
+## Scenes from BackstageCon
+
+![Thank you to our BackstageCon sponsors: Red Hat, Roadie, Spotify, Port](assets/2025-04-29/kc25london-sponsors.jpg)
+📸 _[CNCF][flickr]_
+
+Kicking the week off was the fifth-ever BackstageCon — a full day of talks featuring voices and perspectives from across the community. Here are just a few of the highlights from the day.
+
+### #1: [Unlocking Backstage's Potential: Driving Adoption and Maturity With Your Developer Community][1]
+
+![Stanley Nicholl from Spotify presents at BackstageCon Europe 2025](assets/2025-04-29/kc25london-spotify.png)
+
+Learn how to bridge the gap between the lofty ROI numbers you've read about and your own experiences. Spotify's Stanley Nicholl shares his insights for how to unlock internal Backstage adoption by tapping into your greatest resource: your internal developer community.
+
+[1]: https://www.youtube.com/watch?v=Rg3ANYLyFoM&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### #2: [Panel: What Do Cars, Clothes, Wardrobes and MRI Machines Have in Common?][2]
+
+![Philips, H&M Group, IKEA, and Volvo Cars formed a super-panel of Backstage adopters at BackstageCon Europe 2025](assets/2025-04-29/kc25london-panel.jpg)
+📸 _[CNCF][flickr]_
+
+If that riddle of a title doesn't pull you in, I'm not sure what else to say! This panel — featuring Scott Guymer (Philips), Remi Higuchi & Tina Vincent (H&M Group), Jan Magnusson (IKEA), and Martin Wänerskär (Volvo Cars) — brings a diverse group of Backstage adopters together. It's well worth hearing their different impact and success stories, and comparing their perspectives on the business case for developer portals.
+
+[2]: https://www.youtube.com/watch?v=h6BgF9dQDNo&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### #3: [Lightning Talk: We Built a Unified AI Asset Catalog in Backstage][3]
+
+![John Collier from Red Hat presents at BackstageCon Europe 2025](assets/2025-04-29/kc25london-redhat.jpg)
+📸 _[CNCF][flickr]_
+
+With all the various AI tools out there, it's becoming hard to keep track of them all. But with the Catalog in Backstage, this becomes much easier. John Collier from Red Hat walks through how they approached this problem space internally as their inventory of AI tools — inference servers, models, and API gateways — grew and grew.
+
+[3]: https://www.youtube.com/watch?v=tUR_2Nk0v4E&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### #4: [Exemplar-y Backstage Templates][4]
+
+![Brent Swish from ITHAKA presents at BackstageCon Europe 2025](assets/2025-04-29/kc25london-ithaka.png)
+
+The heart of offering your platform in a self-service way is to use Software Templates. What if you could make the templates themselves easier to update and contribute to? Brent Swisher from educational nonprofit ITHAKA walks through how they came up with a technique called “exemplar” templates to speed up the process of creating and updating templates, making them more accessible to other devs and easier to maintain.
+
+[4]: https://www.youtube.com/watch?v=xY7fVOVsK_A&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### #5: [From Click To Chaos: Linking Argo Workflows and Backstage for Automated Testing][5]
+
+![Chris Heisz and Luke Beamish from Neo4j presents at BackstageCon Europe 2025](assets/2025-04-29/kc25london-neo4j.png)
+
+This talk by Chris Heisz and Luke Beamish from graph technology specialists, Neo4j, is a great showcase of how you can use the Scaffolder along with Argo Workflows to offer self-service integration and chaos testing. See how they ensure thousands of Kubernetes clusters are stable and performant. (You'll be OK, little guy!)
+
+[5]: https://www.youtube.com/watch?v=qukwR1RDrFg&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### Watch all the recordings
+
+But that's just the start! There were so many more insights shared by the community. To see recordings of all the sessions, check out the full [BackstageCon playlist][playlist].
+
+## Breaking through the bustle at KubeCon + CloudNativeCon
+
+![Crowds of attendees at KubeCon + CloudNativeCon Europe 2025](assets/2025-04-29/kc25london-crowds-from-above.jpg)
+📸 _[CNCF][flickr]_
+
+KubeCon was also a great showcase for Backstage, grabbing the interests of both current and potential adopters.
+
+### Standing-room only for the State of Backstage
+
+![The Backstage core maintainers packed the room with people and insights](assets/2025-04-29/kc25london-maintainers-talk.jpg)
+📸 _Spotify_
+
+It was standing room only for the core maintainers talk — [The State of Backstage in 2025][state] — where they covered the past few months of accomplishments and outlined what they have in store for the rest of the year, including a demo of the latest features in the New Frontend System.
+
+[state]: https://www.youtube.com/watch?v=anqWhSnN7sA&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+
+### Big birthday energy on the big stage
+
+![Bowie the Backstage Beaver on screen as the Keynote audience wishes the Backstage project a happy 5th birthday](assets/2025-04-29/kc25london-keynote.jpg)
+📸 _[CNCF][flickr]_
+
+With the project just turning five, [Backstage got a nice Happy Birthday][keynote] from the Keynote main stage! Tyson Singer, Spotify's head of technology and platforms, outlined the journey Backstage took to get where it is now.
+
+[keynote]: https://www.youtube.com/watch?v=JqG1wey7-Ao&t=563s
+
+### Backstage Contribfest goes across the pond!
+
+![A room full of Backstage contributors addressing issues and building plugins](assets/2025-04-29/kc25london-contribfest.jpg)
+_(Hey, that's me! Thanks for all the great pics, 📸 [CNCF][flickr])_
+
+After a successful appearance last year in [Salt Lake City][slc], Backstage ContribFest made its European debut. The community came out — with laptops in tow — for this session all about contributing to Backstage and the Community Plugins. Excited first-timers got to sit down with experienced contributors as well as core maintainers to work through a list of issues or to build plugins together. Keep your eyes on the release notes — some of those features might just have started here!
+
+[slc]: https://backstage.io/blog/2024/12/09/kubecon-slc-24
+
+## Cheerio, London! What's up, ATLiens!
+
+![A brigade of Beefeaters blow brass instruments in front of the entrance to the Solutions Showcase exhibition hall](assets/2025-04-29/kc25london-beefeaters.jpg)
+📸 _[CNCF][flickr]_
+
+What a jam-packed conference week! As I was walking out of the Excel London conference center, I swear I spotted Bowie in a low-riding, candy-red Cadillac saying something about needing to see [his cousins and his mama, too][spotify]? Guess we'll find out [in Atlanta this November][na]!
+
+[spotify]: https://open.spotify.com/track/2oLwDI8tZUOh6SmTMRRfKs?si=61b5e96260c34592
+[na]: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
+[flickr]: https://www.flickr.com/photos/143247548@N03/albums/72177720324566471
@@ -0,0 +1,63 @@
+---
+title: 'From Zero to Maintainer: My Open Source Journey with Backstage'
+author: Kashish Mittal, Red Hat
+authorURL: https://github.com/04kash
+authorImageURL: https://avatars.githubusercontent.com/u/113269381?v=4
+---
+
+My path to becoming a maintainer in the Backstage project wasn’t paved with years of prior open source experience. As a student interning at Red Hat, I started with a relatively fresh perspective. This is the story of that journey – how I navigated the complexities of Backstage, with the support of its community, allowing me to grow and learn, and how open source can empower anyone to do the same. Whether you’re new to open source or a seasoned developer, I believe you’ll find something valuable here. For those just starting out, I hope this inspires you to take that first step. And for experienced developers, I hope this offers a fresh perspective – a look at how a new contributor navigates a complex project, and perhaps, a reminder of our own beginnings.
+This journey wasn’t made in a single leap, but through a series of progressive stages. I’ll walk you through these stages, highlighting the key learnings and contributions along the way.
+
+![The Stages of my Journey](assets/2025-05-12/stages.png)
+{/* truncate */}
+
+## Stage 1: Laying the foundation
+
+![Getting Familiar with the Backstage Tech Stack](assets/2025-05-12/tech_stack.png)
+
+When I first encountered Backstage, I wasn’t deeply familiar with the tech stack it relied on — Node.js, TypeScript, and React. My only exposure previously had been through hackathons, where the focus is speed over deep understanding. Another major hurdle was Git. Up until that point, I had mainly used GitHub Desktop, rarely venturing into the command line or advanced Git concepts. Realizing that effective contribution required a deeper understanding, I dedicated a week to intensively reviewing these core technologies.
+
+But that wasn’t all. I wanted to see Backstage in action, to really grasp what it was all about. That’s when I came across the [Spotify Learning Path for Backstage](https://backstage.spotify.com/learn/). Specifically, the [“Standing up Backstage”](https://backstage.spotify.com/learn/standing-up-backstage/) section was incredibly useful. It walked me through setting up a local running instance with a Postgres database and GitHub authentication. From there, I explored the Backstage documentation and experimented with adding features to my local instance. Honestly, for me, this stage was all about building confidence. It was about facing my knowledge gaps head-on and taking the time to learn.
+
+## Stage 2: First contributions
+
+![First contributions to Backstage: learning the process and connecting with the community](assets/2025-05-12/first_contributions.png)
+
+With my foundational skills in place, it was time to take the leap and make my first contributions to Backstage. [My first pull request](https://github.com/backstage/community-plugins/pull/497) (PR) was quite simple — fixing broken links in the documentation. This seemingly minor fix was my first step, and it paved the way for more substantial contributions. It helped me to get comfortable with the contributing process, learn how to submit a PR, and understand the review workflow. After that, I started looking for open issues in the [community-plugins repository](https://github.com/backstage/community-plugins). I found an issue about [linking npm releases of plugins to specific Git commits](https://github.com/backstage/community-plugins/issues/489) — a task that pushed me outside my comfort zone once again. At the time, I knew very little about GitHub Actions and workflows. Learning on the fly, I relied heavily on guidance from maintainers who were incredibly welcoming.
+This experience was really helpful, not just for the task itself, but also because it introduced me to key community resources like the [Backstage Discord](https://discord.com/invite/backstage-687207715902193673) and [Special Interest Groups](https://github.com/backstage/community/tree/main/sigs) (or SIGs for short). While the content of the pull requests in this stage was certainly useful, the real value came from learning the project’s workflows and community processes.
+
+## Stage 3: Making substantial contributions
+
+As my confidence grew, so did the complexity of the contributions that I took on. Two of my first feature-related contributions were related to Catalog Permissions and the LDAP Processor.
+First, with Catalog Permissions, I noticed that two endpoints in the Catalog plugin, `/analyze-location` and `/validate-entity` weren’t restricted by permissions, posing a security risk. To address this, I needed a deep understanding of Backstage’s permissions system. I spent a lot of time reading through documentation and existing code, and asking questions on Discord. When I had [a PR](https://github.com/backstage/backstage/pull/25924) ready, I went to the Framework SIG meetings to discuss my implementation and to make sure that I was on the same page as the maintainers. Following this process, my PR was successfully merged!
+Shortly after, I tackled an open issue with the [LDAP processor](https://github.com/backstage/backstage/issues/26225). This issue highlighted a problem where Backstage couldn’t correctly map user-group relationships with certain LDAP server configurations that used attribute names that were different from the ones hardcoded within the plugin. I implemented [a solution](https://github.com/backstage/backstage/pull/26511) that allowed users to override these default values. Testing against a real LDAP instance wasn’t something I could do locally, but the original issue reporter stepped in, validating my changes in their environment. It was a beautiful example of open source collaboration in action.
+
+![My first commits in the backstage CHANGELOG](assets/2025-05-12/changelog.png)
+_My first commits in the backstage CHANGELOG_
+
+These two tasks were a significant step up from my initial contributions. They required a deeper understanding of Backstage’s architecture and a greater level of problem-solving. Seeing my commits in the [CHANGELOG](https://backstage.io/docs/releases/v1.31.0/#new-catalog-permissions) was an accomplishment I was proud of, and it solidified my confidence so I could take on even more substantial roles within the Backstage community.
+
+## Stage 4: Becoming an active community member
+
+![Engaging with the Open Source Community at the CNCF meetup in Toronto](assets/2025-05-12/cncf_1.jpeg)
+_(Source: https://www.linkedin.com/posts/mwijay_you-totally-missed-last-nights-first-cncf-ugcPost-7311005210628235264-8BES)_
+
+![Engaging with the Open Source Community at the CNCF meetup in Toronto](assets/2025-05-12/cncf_2.png)
+_Engaging with the Open Source Community at the CNCF meetup in Toronto (Source: https://community.cncf.io/events/details/cncf-cloud-native-toronto-presents-cncf-2025-kickoff-at-shopify/)_
+
+One of the ways I got more involved was by helping with the maintenance of the [community-plugins repository](https://github.com/backstage/community-plugins). For instance, I helped address a security vulnerability — specifically, that the `@backstage/backend-common package` relied on a vulnerable version of `jsonpath-plus` through `@kubernetes/client-node`. I proactively removed this vulnerable dependency from eight plugins, effectively safeguarding those plugins from potential risks. I also focused on improving dependency management by implementing Knip reports. These reports help us identify and remove unused dependencies, keeping the repository clean and efficient.
+
+Beyond repository maintenance, I also began focusing on community engagement. I began reviewing pull requests regularly, helping maintain code quality and lightening the load on other maintainers. This not only deepened my understanding of the codebase but also exposed me to new features and patterns across the ecosystem. I actively participated in SIG meetings and offered guidance to fellow contributors on Discord.
+
+This marked a turning point in my journey, as I transitioned from a contributor to an active community member. Eventually, this growing involvement led to me becoming a maintainer for the community-plugins repository. It was a fulfilling step forward, and it felt rewarding to be trusted with more responsibility in guiding the project.
+
+## What’s next: future steps as a maintainer
+
+![Presenting "From Zero to Contributor: My Open Source Journey with Backstage" at the CNCF 2025 Kickoff event at Shopify, Toronto](assets/2025-05-12/cncf_3.jpeg)
+_Presenting "From Zero to Contributor: My Open Source Journey with Backstage" at the CNCF 2025 Kickoff event at Shopify, Toronto (Source: https://www.linkedin.com/posts/mwijay_you-totally-missed-last-nights-first-cncf-ugcPost-7311005210628235264-8BES)_
+
+As a maintainer, my focus is on supporting others in their open source journey and improving the overall contributor experience. I actively review PRs, guide new contributors through constructive reviews, and point them to good first issues to help them get started.
+Furthermore, I aim to actively contribute to the community-plugins SIG meetings, offering suggestions and participating in discussions to help guide the project’s direction.
+Ultimately, my goal is to help the community-plugins repository thrive and become an even more valuable resource for the Backstage community. I’m excited to collaborate with fellow maintainers and contributors to achieve this vision.
+
+My journey with Backstage has been incredibly rewarding, and I’m grateful for the opportunities, support, and growth the community has given me. I’m excited to continue contributing and to see where this journey takes me next.
@@ -0,0 +1,74 @@
+---
+title: 'Get ready for Backstage ContribFest at KubeCon!'
+author: André Wanlin, Spotify
+authorURL: https://github.com/awanlin
+authorImageURL: https://avatars.githubusercontent.com/u/67169551?v=4
+---
+
+![Get ready for Backstage ContribFest at KubeCon!](assets/2025-10-15/backstage-contribfest-kubecon-guide-header.png)
+
+Pack your laptop and mark your calendars! Backstage will once again be taking part in the ContribFest track at KubeCon! Join us at KubeCon 2025 North America in Atlanta on Monday, November 13. Feel free to [bookmark it on your schedule](https://kccncna2025.sched.com/event/27Nl6/contribfest-level-up-your-open-source-journey-hands-on-backstage-contributions-andre-wanlin-patrik-oldsberg-emma-indal-spotify-aramis-sennyey-doordash-kurt-king-procore). Then read on to get yourself prepared for the session beforehand to maximize your time working with other contributors and Backstage experts during the session.
+
+{/* truncate */}
+
+## Contrib-what?
+
+Before we dive into preparation for the Backstage ContribFest session we should probably take a detour and answer the question: What the heck is ContribFest?
+
+ContribFest is a track at KubeCon where various CNCF projects will host hands-on sessions working with their respective communities on contributions towards their projects. You don't have to be a past contributor to participate — new community members are encouraged to join!
+
+These sessions are 75 minutes long and take place in a room with roughly a dozen circular tables that seat about eight people making it easy to work and collaborate. They usually lead off with some getting started steps and then give attendees the rest of the time to work on their contributions with the aid of experts from the project.
+
+## What to prepare before you get there
+
+For the Backstage ContribFest session, there are some preparation steps you can complete on your own well before the session. Let's cover those now:
+
+### 1. Fork the repos
+
+You'll have the option to contribute to the Backstage repo or the Backstage Community Plugins repo. To get those onto your system, you need to follow the GitHub ["Forking a repository"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo#forking-a-repository) guide and fork these:
+
+- Backstage: [https://github.com/backstage/backstage](https://github.com/backstage/backstage)
+- Backstage Community Plugins: [https://github.com/backstage/community-plugins](https://github.com/backstage/community-plugins)
+
+### 2. Update Node.js and Yarn
+
+Backstage has [a few prerequisites](https://backstage.io/docs/getting-started/#prerequisites) that you'll need to have in place before you can run Backstage or the various Backstage Community Plugins. Here's what you need:
+
+- Backstage uses Node.js — you'll want to install version 22 for the session.
+  - To make this easier, we recommend you use Node Version Manager nvm, you can [follow these instructions to install it](https://github.com/nvm-sh/nvm#install--update-script).
+  - Once you have nvm installed, you can run this command to get Node 22 installed and activated: `nvm install 22`
+- Yarn is the package manager used by Backstage — you'll want to install it as well.
+
+  - Simply run `corepack enable` to do so.
+
+### 3. Test your setups
+
+Now let's do a quick test to confirm that everything is working.
+
+First, let's check that you can run the Backstage codebase:
+
+1. Navigate to your cloned fork of the Backstage repo
+2. From the root, run `yarn install`
+3. Then run `yarn tsc`
+4. Finally run `yarn start`
+5. Backstage will open in a new browser window or tab
+
+Now, let's check the Backstage Community Plugins:
+
+1. Navigate to your your cloned fork of the Backstage Community Plugins repo
+2. This repo is structured in a way where there are many plugins that live in their own dedicated workspace — for this test, we'll use the `linguist` workspace. From the root, run `cd workspaces/linguist`
+3. From here run `yarn install`
+4. Then run `yarn tsc`
+5. Finally run `yarn start`
+6. An example Backstage app will open in a new browser window or tab
+
+### Bonus: Check out the contribution guides
+
+At this point, you have all the prerequisites in place and are ready to take part in the Backstage ContribFest session. From here, we recommend you take some time to read the contributions guides as that will get you more familiar with the overall process. Here they are:
+
+- [Backstage Contribution Guide](https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md)
+- [Backstage Community Plugins Contribution Guide](https://github.com/backstage/community-plugins/blob/main/CONTRIBUTING.md)
+
+## 👋 See you in Atlanta!
+
+On behalf of myself and the other co-hosts of Backstage ContribFest, thanks for following along! We look forward to seeing you in Atlanta and working with you on your contributions. Make sure to say hello!
@@ -0,0 +1,93 @@
+---
+title: 'Backstage in Atlanta: Highlights from BackstageCon and KubeCon + CloudNativeCon North America 2025'
+author: Kate Klymkovska, Spotify & André Wanlin, Spotify
+---
+
+![Backstage in Atlanta: Highlights from BackstageCon and KubeCon + CloudNativeCon North America 2025](assets/2025-11-25/backstagecon-kubecon-na-2025-header.png)
+
+Cancelled flights and wonky Wi-Fi couldn't hold us back from having an amazing time in the Big Peach! It was great to head south and commune with the community in person at [BackstageCon](https://colocatedeventsna2025.sched.com/overview/type/BackstageCon) and [KubeCon + CloudNativeCon North America 2025](https://kccncna2025.sched.com) in Atlanta. We gave talks, shared insights, chatted without having to type into little text boxes, and tackled issues elbow-to-elbow during [ContribFest](https://backstage.io/blog/2025/10/15/backstage-contribfest-kubecon-guide). The week was capped off with the [Backstage maintainers talk](https://www.youtube.com/watch?v=evmmr-uxNsc&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) where we celebrated a year of milestones, the release of the adoption-ready New Frontend System, and work towards an AI-Native Backstage. Catch up with recordings of [all the Backstage talks](https://www.youtube.com/playlist?list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) and check out highlights from our week in the Big A below.
+
+{/* truncate */}
+
+## Scenes from BackstageCon (and beyond)
+
+![Scenes from BackstageCon and KubeCon + CloudNativeCon NA 2025](assets/2025-11-25/kcon25-atl-slideshow.gif)  
+_📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720330018728/)_
+
+Brrr…it was a cold start with “Hot 'Lanta” bringing a serious autumn chill on Monday morning. But all the spicy DevEx insights would soon heat things up in the halls of the Georgia World Conference Center. Throughout the day, we heard discussions around how organizations adopt Backstage and scale it for productivity, as well as practical lessons on governance, deployment models, change management, and standardizing best practices around Backstage.
+
+And despite an unfortunate amount of flight disruptions waylaying some of the speakers, the organizers were able to work around all the last-minute issues for a day full of presentations, demos, lightning talks, and keynotes. Check out our community YouTube channel to watch recordings of [all the Backstage talks](https://www.youtube.com/playlist?list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) from Atlanta. Not sure where to start?
+
+### A few personal picks
+
+Here are six BackstageCon talks that we attended and thought were worth sharing. They feature Backstage adopters across a range of industries — from finance and healthcare, to networking, automotive experiences, and beyond — all sharing use cases that relate to almost any engineering org:
+
+- 🏦 [Supercharging Backstage Scaffolder for Workflows](https://www.youtube.com/watch?v=0m94ERF0k4Q&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): Jonathan Chan and Francis Hackenberger, engineers from the Royal Bank of Canada's cloud team, talk about how they scale up the power of Backstage Software Templates at one of Canada's largest banks.
+
+- 🩺 [From Friction to Flow: How Backstage Transformed Our Security Experience](https://www.youtube.com/watch?v=ZCM9i1zD364&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): In this lightning talk, Christopher Diaz, principal engineer at RVO Health, squeezes three years' worth of Backstage learnings into a 10-minute lightning talk — including how Backstage has unlocked an inner source culture within their org, with teams building custom plugins to extend their instance (“That's what makes it so much fun to build on Backstage: everything you need to solve a problem is literally just a pull request away” 🙌).
+
+- 📶 [How Ericsson Scaled Developer Experience with Backstage](https://www.youtube.com/watch?v=1mDEkiN4NTs&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): Ericsson principal engineer Damien O'Toole and engineering manager Kieran Egan share what they learned on the way to scaling internal Backstage adoption to over 1,260 users and over 4,073 weekly visits.
+
+- 🚗 [Cruising the AI Highway: Standardized MCP Deployment and Governance with Backstage](https://www.youtube.com/watch?v=pFSSpDHB2rU&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): Engineers from Toyota Connected — “recovering system administrator” Rob Heckel and platform engineer Tyler Rothenberg — share how they deploy MCP servers across their org in an easy, secure, and sustainable way, covering everything from the basics of MCP to deploying MCP servers using cloud native tools and integrating them with Backstage.
+
+- 📊 [Lego Bricks for Developers: Turning Insights into Golden Paths at Neo4j](https://www.youtube.com/watch?v=IdLXeK8motg&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): Developer advocate Jeremy Adams (stepping in for a waylayed Chris Heisz) joins engineer Luke Beamish to talk about how they use Golden Paths at Neo4j, a leader in graph technology whose tech is used for cancer research, GenAI, and NASA's mission to Mars.
+
+- 🔔 [Driving Adoption by Generating High Value Notifications in Backstage](https://www.youtube.com/watch?v=N4gCLbhxTHA&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU): How do notifications work in Backstage and what makes them such a powerful way to drive Backstage adoption within your org? Watch this talk by Spotify engineering manager Avantika Iyer and customer success engineer/Backstage community maintainer André Wanlin. [Hey, that's me! Seriously, tho, notifications are the jam. — AW]
+
+### Backstage at KubeCon
+
+The Backstage-related talks continued throughout the week during KubeCon + CloudNativeCon, including:
+
+- 🚀 [The Journey of Deploying Backstage in a Large Organization](https://www.youtube.com/watch?v=l7OQdrUkoVI&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU), as told by engineers Mathieu Girard and Teddy Poingt from Beneva, Canada's largest mutual insurance company.
+
+- 📚 [Build Your Internal Developer Platform with the Experts](https://www.youtube.com/watch?v=eqxKB6Gq7oc&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) in this hands-on workshop led by CNCF ambassadors and project maintainers.
+
+- 🎵 [Harmonizing Strategy and Engineering: Lessons Learnt in Building a Platform Plugin for Diverse Users](https://www.youtube.com/watch?v=2t_Pdiu3B1E&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) from Spotify senior product manager Sri Chandrasekaran and senior engineer Kate Klymkovska. [Hey, that's me! What André said, except product vision instead of notifications. — KK]
+
+### Watch 'em all!
+
+📺 There's much more to explore and dive into. Head over to the Backstage Community YouTube channel to [watch all the Backstage talks](https://www.youtube.com/playlist?list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) from BackstageCon and KubeCon.
+
+## Our third Backstage ContribFest
+
+![Backstage ContribFest at KubeCon + CloudNativeCon NA 2025!](assets/2025-11-25/kcon25-atl-contribfest.jpg)
+
+We talked about Backstage a ton, but we also invited attendees to help us build it. In Atlanta, we co-hosted our third [Backstage Contribfest](https://backstage.io/blog/2025/10/15/backstage-contribfest-kubecon-guide) with participants of all experience and skill levels diving into the Backstage repos to tackle issues together — and with plenty of Backstage maintainers and contributors close at hand to help out.
+
+A few ContribFest-fueled pull requests have already popped up in the repos:
+
+- fix(ui): render html in gfm mode in MarkdownContent component ([#31770](https://github.com/backstage/backstage/pull/31770))
+- catalog-react: OwnerEntityPicker case insensitive ([#31756](https://github.com/backstage/backstage/pull/31756))
+- fix: making the github urls case insensitive ([#31754](https://github.com/backstage/backstage/pull/31754))
+- fix: success announcements should be transient ([#6041](https://github.com/backstage/community-plugins/pull/6041) — ✅ merged!)
+
+Many thanks to all the participants and to our fellow hosts — Kurt King from Procore and Aramis Sennyey from DoorDash!🙏
+
+🛠️ If you haven't yet joined our worldwide community of contributors, [there's no time like the present](https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md)!
+
+## Maintainers talk: Stable foundations, MCP innovations
+
+![Backstage Maintainers Track at KubeCon + CloudNativeCon NA 2025!](assets/2025-11-25/kcon25-atl-maintainers.gif)
+
+As always, the main event for the community is the Maintainers Track session. Backstage core maintainers Ben Lambert and Patrik Oldsberg closed out the week celebrating a year of milestones — including contributions big and small from the community — while looking ahead to what's next for the framework.
+
+In their talk, [Backstage Celebrations: Stable Foundations and MCP Innovations](https://www.youtube.com/watch?v=evmmr-uxNsc&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU), they shared:
+
+- **Project Updates:** Adopters, plugins, and stars — and all the other ways the Backstage community continues to grow, including in the community-plugins repo. Plus, improvements to issue handling and more.
+
+- **Project Maturity:** With the new backend ([released as a stable 1.0 last year](https://backstage.io/docs/releases/v1.31.0/)) and new frontend ([adoption-ready as of this year](https://backstage.io/docs/releases/v1.42.0)) now both in place, the Backstage framework has modern foundations built for the future. With more emphasis on declarative integration (and less TypeScript code), Backstage is more accessible and easier to maintain — and plugins are simpler than ever to build and integrate. Make sure to watch the demo to see how quickly you can install plugins into a fresh Backstage instance.
+
+- **New Stuff ✨:** MCP, MCP, MCP, and MCP: What happens when you combine your AI tools with your engineering source of truth? Learn about Backstage + MCP, the latest improvements to the Backstage Actions Registry, authorization via new dynamic client registration and CLI authentication, and a live demo. Plus, all the latest on the framework's new design system, [Backstage UI](https://ui.backstage.io) (BUI).
+
+- **Roadmap:** Looking ahead to what's next for the New Frontend System, the Backstage UI rollout, the plugin ecosystem, MCP, CLI, and the release process.
+
+📺 Watch the entire [Backstage maintainers talk](https://www.youtube.com/watch?v=evmmr-uxNsc&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU) to dig into the past, present, and future of the framework, including live demos showcasing the newest features and capabilities.
+
+## See you in 🌷Amsterdam!
+
+![Cloud native puppies improving developer experience at KubeCon + CloudNativeCon NA 2025!](assets/2025-11-25/kcon25-atl-puppies.gif)  
+_Cloud native puppies improving developer experience in Atlanta. 📸 [CNCF](https://www.flickr.com/photos/143247548@N03/albums/72177720330018728/)_
+
+And that's a wrap for Atlanta! We say goodbye to the home of 🎤 trap music and get ready to say hello to a [stroopwafel](https://en.wikipedia.org/wiki/Stroopwafel) fika 🧇.
+
+See you next year at [BackstageCon](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/backstagecon/) and [KubeCon + CloudNativeCon Europe 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) in Amsterdam!
@@ -0,0 +1,115 @@
+---
+title: 'Backstage Wrapped 2025: Celebrating a mature framework with modern foundations'
+author: Vincenzo Scamporlino, Spotify
+authorURL: https://github.com/vinzscam
+authorImageURL: https://avatars.githubusercontent.com/u/8433119?v=8
+---
+
+![Let's blast into the New Year with a quick look back at all the big hits — backend, frontend, AI, UI, and more! See how today's Backstage is ready to build the future of developer experience.](assets/2025-12-30/wrapped2025.png)
+
+This year was another big one for Backstage and our worldwide community of adopters, contributors, and partners. Backstage turned five, the New Frontend System became adoption-ready, and your favorite platform for developer experience gained AI superpowers with the introduction of the Actions Registry and MCP server support. Let's blast into the New Year with a quick look back, along with a peek around the corner at what's coming next.
+
+{/* truncate */}
+
+---
+
+## Busy beavers here, there, and everywhere
+
+As in years past, we've visualized how our vibrant global community lights up the Backstage open source repo with enthusiasm, creativity, and commits. This year, we're visualizing contributions to the Community Plugins repo, too. Can you spot your name in the videos below?
+
+<iframe
+  src="https://www.youtube.com/embed/-D8PGN1tPn8"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+_All 7.7k commits to `backstage/backstage` in 2025_
+
+<iframe
+  src="https://www.youtube.com/embed/Vaz0AbOJdi0"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+_All 3.3k commits to `backstage/community-plugins` in 2025_
+
+Couldn't spot your name in the videos? Here's one more chance — every contributor who helped shape Backstage in 2025, all in one picture.
+
+![Backstage 2025 contributors](assets/2025-12-30/contributors-wrapped-2025.png)
+
+## Mature for a five-year-old
+
+![Backstage community stats: 3.4k+ adopters, 1,8k contributors, 15k Discord members, 7k project forks, 68k total contributions, 250+ open source plugins, 31k stars](assets/2025-12-30/wrapped2025-stats.png)
+_The growing Backstage ecosystem, by the numbers_
+
+Earlier this year, the Backstage project [celebrated its 5th birthday][bday] on the main stage at [KubeCon + CloudNativeCon in London][kcon-eu].
+
+While the framework still isn't old enough to shave, it's matured into the industry standard for internal developer portals (IDPs). According to [this DX survey][dx] released in March:
+
+> Backstage is dominating the IDP market, holding an impressive 89% market share compared to SaaS competitors and achieving a remarkable 67% overall market penetration. These percentages are even higher for enterprise companies.
+
+As you can see above in the [latest project stats][video], the Backstage ecosystem continues to expand, growing in adopters and contributors, as well as plugins and third-party service providers.
+
+Want to dive into more Backstage stats? Check out the project's health scores and more on the relaunched [LFX Insights][lfx] site.
+
+[bday]: https://www.youtube.com/watch?v=JqG1wey7-Ao&t=563s&list=PL8iP9yIjU0Q3K8LV_a9CcFmhvvNTAUzL1
+[kcon-eu]: https://backstage.io/blog/2025/04/29/backstagecon-kubecon-25-london#big-birthday-energy-on-the-big-stage
+[dx]: https://newsletter.getdx.com/p/backstage-and-the-developer-portal-market
+[video]: https://www.youtube.com/watch?v=Wih0a1v1Et0&list=PL8iP9yIjU0Q33vpSaBlAvIhgDb-9smXUU
+[lfx]: https://insights.linuxfoundation.org/project/backstage
+
+## Building the future on modern foundations
+
+Just because Backstage has cemented its place as the standard for IDPs doesn't mean it's sitting still. From backend to frontend, from AI to UI, the technical foundations of the platform have been modernized, updated, and revamped — this is why today's Backstage is ready to build the future of developer experience.
+
+Top 2025 highlights:
+
+- Goodbye to the old backend system
+- New Frontend System is adoption-ready
+- Hello to the Actions Registry + MCP server support
+- Introducing a new design system with Backstage UI
+
+With the [New Backend System][backend] released as a stable 1.0 last year and the [New Frontend System][frontend] becoming [adoption-ready][1-42] this year, Backstage is easier than ever to use, maintain, and build on — making it both more accessible and more capable for adopters, old and new.
+
+This year also saw the debut of the [Actions Registry][actions] and MCP server support — so now Backstage can empower both your human developers and their AI helpers.
+
+And [Backstage UI][ui] is coming! The alpha release of the upcoming design system made huge strides in 2025, preparing the way for a new level of usability throughout the Backstage experience.
+
+Catch up on a whole year's worth of improvements — and see where Backstage is heading next — in the recordings below.
+
+[backend]: https://backstage.io/docs/backend-system/
+[frontend]: https://backstage.io/docs/frontend-system/
+[1-42]: https://backstage.io/docs/releases/v1.42.0
+[actions]: https://backstage.io/docs/backend-system/core-services/actions-registry
+[ui]: https://ui.backstage.io/
+
+<iframe
+  src="https://www.youtube.com/embed/anqWhSnN7sA"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+
+_Watch the Backstage maintainers' talk at [KubeCon in London][lon], where they demoed the New Frontend System and introduced the Actions Registry._
+
+<iframe
+  src="https://www.youtube.com/embed/evmmr-uxNsc"
+  width="100%"
+  height="440"
+  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
+  allowFullScreen
+></iframe>
+_Watch the maintainers' talk at [KubeCon in Atlanta][atl], where they shared
+work towards an AI-Native Backstage, progress on Backstage UI, and more._
+
+[lon]: https://backstage.io/blog/2025/04/29/backstagecon-kubecon-25-london
+[atl]: https://backstage.io/blog/2025/11/25/backstagecon-kubecon-25-atlanta
+
+## See you in 2026!
+
+Happy New Year, Backstage Community! See you in the repos!
--- a/Show More
+++ b/Show More