Amsterdam delivered. From the moment BackstageCon opened its doors on March 23, the Backstage community was in full force — long-time contributors comparing notes with teams who had only just started their IDP journey. Across four days of BackstageCon and KubeCon + CloudNativeCon Europe 2026, there was a lot to take in: an energetic day of community talks, a documentary premiere, a standing room–only maintainers session, a live demo on the Keynote mainstage, and a ContribFest that turned issues into pull requests in real time. Read on for the highlights — and catch up on all the BackstageCon talks in the full recordings playlist.

BackstageCon: What the community is building​

📸 CNCF

BackstageCon kicked off the week with a full day of talks organized by the community, for the community — emceed by Balaji Sivasubramanian (Red Hat) and André Wanlin (Spotify). The full schedule had something for every stage of the Backstage journey, but a few themes stood out across the day.

On the engineering side, Booking.com's Symbat Nurbay and Xicu Piñera shared how they're working toward a unified developer experience across a large, complex organization — a relatable challenge for many in the room. Krzysztof Janota and Dusan Askovic from ING Bank N.V. went deep on how to keep a Backstage deployment healthy and collaborative in a big institution, covering the governance patterns that make it scale without fragmenting. On the catalog and tooling side, Sebastian Poxhofer from N26 showed how adding a platform CLI on top of the Backstage catalog can open up new workflows and make the catalog more actionable for platform teams.

One of the day's surprises came from the lightning talk slot: Mathilde Ançay from HEIG-VD took an unexpected angle, tracing an unlikely path from philosophy to a Backstage plugin — it's the kind of talk that's hard to summarize, so just watch it.

And the buzziest moment of the day? The panel — Building a Healthy Backstage Plugins Ecosystem — with Paul Schultz and Hope Hadfield (Red Hat), Heikki Hellgren (OP Financial Group), Peter Macdonald (VodafoneZiggo), and Aramis Sennyey (DoorDash). The conversation was wide-ranging and the Q&A spilled past the scheduled time, which felt like a good sign.

📺 Those are just a few picks — there's plenty more to explore in the full BackstageCon playlist.

Now playing: The Backstage story, on film​

📸 CNCF

One of the week's most memorable moments had nothing to do with a slide deck. The Backstage Documentary made its world premiere at KubeCon Amsterdam, and the room filled up with community members eager to watch the story of how Backstage evolved from an internal tool at Spotify into one of the most widely adopted and active open source projects in the cloud native ecosystem. The film surfaces voices from across the project's history — including some perspectives that even long-time contributors hadn't heard before. If you haven't watched it yet, grab a snack and set aside 30 minutes to see the past, present, and future of Backstage.

Standing room only: The State of Backstage in 2026​

The State of Backstage talk has become one of the community's most anticipated events at every KubeCon. In Amsterdam, that anticipation was on full display: over 600 people were seated, close to 1,000 had registered, and more were turned away at the door. Core maintainers Ben Lambert and Patrik Oldsberg covered the full breadth of what's been happening across the project — contributions, ecosystem growth, the New Frontend System now that it's adoption-ready, and the work underway on MCP support and an AI-native Backstage direction.

A demo on the big stage​

📸 CNCF

On Thursday morning, the core maintainers stepped up for something a little different: a live demo on the KubeCon Keynote mainstage. In front of over 1,500 attendees, they showcased some of Backstage's newest capabilities — including the MCP and AI-related features covered in the maintainers talk the day before. It's one thing to hear about new features in a talk; seeing them demonstrated live in a keynote setting, to an audience that large, is a different kind of moment for our open source project.

ContribFest: Open source, live​

Rounding out the week was the fourth-ever Backstage ContribFest, co-hosted by André Wanlin and Emma Indal (Spotify), Heikki Hellgren (OP Financial Group), and Elaine Bezerra (DB Systel GmbH). Around 50 attendees showed up ready to contribute — some experienced, some brand new to the project — and spent the session working through real issues in the Backstage and Community Plugins repositories alongside core maintainers and community contributors.

Not every contribution makes it into a merged PR on the day, but ContribFest is often where the work starts. Keep an eye on the release notes — some of what was kicked off in Amsterdam may already be on its way to a future release.

Want to see what came out of Amsterdam and past ContribFests? Head over to the ContribFest web app to browse the full history of contributions from every session.

Tot ziens, Amsterdam! 🌷​

📸 CNCF

What a week. BackstageCon, a documentary debut, a packed maintainers room, a keynote demo, and a ContribFest — Amsterdam showed that the open source Backstage community has a lot of momentum and a lot to say. Catch up on everything you missed in the BackstageCon playlist, and watch the Backstage Documentary and Keynote Demo if you haven't already.

See you in Salt Lake City 🏔️ at BackstageCon and KubeCon + CloudNativeCon North America, November 9-12, 2026!

Become a Contrib Champ and join us at ContribFest, where commits become legendary!

We are once again hosting ContribFest at KubeCon + CloudNativeCon. This time around, it's taking place in Amsterdam on March 26, 2026, at 13:45 CET — make sure to add it to your schedule. Learn more about what to expect below and get started now by exploring the new ContribFest web app.

Introducing the ContribFest web app​

We're excited to announce the new ContribFest web app: https://contribfest.backstage.io/. The app simplifies local setup and helps you quickly find good issues to work on from the curated list pre-selected by your ContribFest co-hosts.

You'll see that the app is broken down into five sections:

• Welcome: This is where you'll find links to all the things, including the session's slide deck, assignment sheet, the Backstage and Community Plugins repositories, and their respective contribution guides.
• Getting Started: Whether you are new to Backstage or an old hat, use this handy checklist to help you get your local environment set up for contributing, including all the commands. (Make sure you check all the boxes, you never know what might happen! 😉)
• Curated Issues: This is what you come to the session for: finding an issue that speaks to you and contributing towards it. This section has a list of issues that we've curated — and filters, so you can slice and dice the list to find the perfect issue to work on.
• Contrib Champs: We've hosted three other ContribFests in the past — this is where you'll find merged PRs from those sessions, a place to celebrate contributions. Make sure to tag your PRs with “ContribFest”, and maybe your name will show up here one day, too! 🏆
• Hall of Hosts: ContribFest would not take place without the various community members who have stepped up to help co-host the sessions. This is where you'll see an honor roll of past co-hosts. 🙏

About those Contrib Champs​

The goals of the Backstage ContribFest sessions are many — foster community, work with experts, etc. — but it's pretty obvious that contributions are the most important. It's in the name after all. Here are a few past contributions that we wanted to share to give you an idea of what that looks like:

• #27694 by hyb175 — Add Pagination to Tech Docs Table: for those with lots of entities with TechDocs, this is a massive performance improvement.
• #29470 by ioboi — Openshift Auth provider: this allows those using OpenShift to use it to sign into their Backstage instance.
• #31770 by theZMC — Render HTML in GitHub-flavored Markdown: with this change in place, HTML will now render correctly in the MarkdownContent component when you are using the GitHub-flavored Markdown mode.

Check out the Contrib Champs page to see the full list!

Using Dev Containers​

Along with the new ContribFest web app, we are also looking to use Dev Containers this time around to help streamline the session for those who'd like to use that option to get started. On the Getting Started page, pick the Dev Containers radio button and then follow the checklist. To give you a quick preview, you'll need to have the following installed:

• Git, you'll need this to be able to pull down the code
• Docker Desktop (or Docker Engine on Linux)
• VS Code with the Dev Containers extension or IntelliJ IDEA Ultimate

Check out our Dev Containers tutorial for a deeper dive into the subject.

Amsterdam, here we come!​

On behalf of the Backstage ContribFest co-host team, thank you for following along. We're looking forward to meeting you in Amsterdam and working together on your contributions. Please be sure to introduce yourself!

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.

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?

All 7.7k commits to backstage/backstage in 2025

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.

Mature for a five-year-old​

The growing Backstage ecosystem, by the numbers

Earlier this year, the Backstage project celebrated its 5th birthday on the main stage at KubeCon + CloudNativeCon in London.

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 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, 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 site.

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 released as a stable 1.0 last year and the New Frontend System becoming adoption-ready 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 and MCP server support — so now Backstage can empower both your human developers and their AI helpers.

And Backstage 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.

Watch the Backstage maintainers' talk at KubeCon in London, where they demoed the New Frontend System and introduced the Actions Registry.

Watch the maintainers' talk at KubeCon in Atlanta, where they shared work towards an AI-Native Backstage, progress on Backstage UI, and more.

See you in 2026!​

Happy New Year, Backstage Community! See you in the repos!

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 and KubeCon + CloudNativeCon North America 2025 in Atlanta. We gave talks, shared insights, chatted without having to type into little text boxes, and tackled issues elbow-to-elbow during ContribFest. The week was capped off with the Backstage maintainers talk 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 and check out highlights from our week in the Big A below.

Scenes from BackstageCon (and beyond)​

📸 CNCF

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 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: 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: 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: 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: 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: 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: 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, 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 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 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 from BackstageCon and KubeCon.

Our third Backstage ContribFest​

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 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)
• catalog-react: OwnerEntityPicker case insensitive (#31756)
• fix: making the github urls case insensitive (#31754)
• fix: success announcements should be transient (#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!

Maintainers talk: Stable foundations, MCP innovations​

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, 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) and new frontend (adoption-ready as of this year) 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 (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 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 in Atlanta. 📸 CNCF

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 fika 🧇.

See you next year at BackstageCon and KubeCon + CloudNativeCon Europe 2026 in Amsterdam!

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. 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.

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" guide and fork these:

• Backstage: https://github.com/backstage/backstage
• Backstage Community Plugins: https://github.com/backstage/community-plugins

2. Update Node.js and Yarn​

Backstage has a few 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.
  • 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
• Backstage Community Plugins Contribution Guide

👋 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!

Why and How a Modern Developer Portal Was Rolled Out​

Historically, many organizations utilized internally built software tools for managing their service inventories. While these tools served their purpose, there's a growing need for more robust service catalogues that require less maintenance and reduce over-engineered tooling. Frameworks like Backstage have emerged as powerful solutions.

The decision is often made to establish a single source of truth for services and engineering teams. The vision is typically for reliability or platform teams to envision a world where every software development team, regardless of size or domain, can efficiently manage projects, access tools and resources, and foster a collaborative culture. A modern developer portal aims to become the go-to platform for developers, infrastructure teams, and product managers to collaborate, accelerate development cycles, and deliver high-quality software. It serves as a centralized hub, consolidating all necessary information, tools, and services that developers require throughout the software development lifecycle.

Internal Services Landscape​

In large organizations, it's common to manage thousands of GitHub repositories, encompassing a wide array of assets such as front end web applications, backend web services, mobile applications, and APIs. For instance, a typical enterprise might have:

• Hundreds or thousands of APIs
• Hundreds or thousands Services
• Dozens of Web applications
• Various libraries, infrastructure components, etc.

Migrating these internal services from various engineering teams requires a systematic approach to retrieve the existing service definitions and transform them into a format compatible with the new developer portal. This often involves automated scripts to ensure efficient ingestion. For example, successfully migrating hundreds of services into a new portal is a common achievement in such initiatives.

GitHub Requests Architecture for Migration​

Using an Entity Provider and a Scripted Migration

In our Backstage setup, we took a hybrid approach: we used an automated script to generate and submit catalog-info.yaml files to service repositories, and relied on the GitHub Entity Provider defined in our app-config.yaml to ingest them into the catalog. This gave us the best of both worlds.

The script handled the heavy lifting of migrating metadata from for example legacy (.appcatalog.yaml) files, transforming them into the modern format expected by Backstage. It also empowered teams by submitting pull requests they could review and enrich adding ownership metadata, documentation links, or system context before merging. Once merged, the GitHub Entity Provider took over, ingesting the files on a scheduled basis and ensuring Backstage stayed up to date. This pattern reduced manual overhead, maintained decentralization, and eliminated the need for a persistent integration with the legacy system. Since the old catalog was being decommissioned, this also aligned with our goal of moving forward cleanly without syncing two sources of truth.

Several technical steps are typically involved in retrieving existing service definition files (e.g., appcatalog.yaml), an example yaml file, and then converting them into the modern developer portal's preferred format (e.g.catalog-info.yaml for Backstage). Rather than manually creating new definition files, an automated Python script can be developed to generate and add them to the respective repositories or services. Without creating and using these automated scripts, doing these tasks manually can take several hours and could become extremely tedious. For example, in the case of Backstage, it would mean having to explicitly create the catalog-info.yaml hundreds of times in hundreds of repositories which can also result in hundreds of errors and manual lift.

Requirement One: GitHub Apps

A dedicated GitHub App can be utilized to extend functionality, granting the necessary permissions to submit pull requests across multiple repositories. GitHub Apps are integrations that extend GitHub's functionality and can automate tasks, interacting with and extending GitHub's features.

A private key (.pem) is retrieved for the GitHub App, and a JSON Web Token (JWT) is created. These two keys are combined to generate an Authentication Token, which is an encoded JSON Web Token.

Requirement Two: An Access Token and Bearer Token

The Authentication Token (encoded JWT) is used to make a GET request to the GitHub API endpoint /app/installations at api.github.com. This request retrieves an access token URL. Once that access token URL is received, another request is made to this URL to obtain the Bearer token. This Bearer token is then used for major requests to GitHub API endpoints, such as https://api.github.com/repos/{owner}/{repo}/contents/{path}.

Base64 and YAML Processing

With the Bearer token, a request can be made to retrieve the contents of GitHub repositories containing the legacy service definition files (e.g. .appcatalog.yaml). GitHub typically returns these contents in Base64 format, a binary-to-text encoding scheme that converts binary data into an ASCII string, often used for secure data transmission over HTTP.

Upon receiving the encoded Base64 content, it must be decoded to YAML. The decoded YAML is then compared to the desired key-value pairings for the new catalog-info.yaml file. This is where a custom Mapper comes into play. A template for catalog-info.yaml is created following the developer portal's guidelines. The key-value pairs from this template are then mapped to the values received from the legacy service definition file. For example:

results['metadata']['title'] = data['appInfo']['appName']
# In the new format: metadata.title
# From the legacy file: appInfo.appName

After the comparisons and correct mapping for the new format, the data is dumped into the catalog-info.yaml file and finally encoded back to Base64 for submission to the GitHub repository.

An example excerpt code of encoding YAML file to base64

def encode_to_base64(file):
    catalog_info_data = load_yaml(file)
    print(catalog_info_data) #json
    catalog_yaml  = yaml.dump_all(catalog_info_data) #yaml
    print('\n')
    print(catalog_yaml)

    logger({'data': catalog_yaml,'method':'encode_to_base64','level': 'debug'})

    #yaml k:v (dict) to string
    dict_to_string = str(catalog_yaml)
    encoded =  base64.b64encode(bytes(dict_to_string, 'utf-8')) # bytes
    print("\n")
    #decode to convert into to explicit string and remove b prefix in encoded
    enc_dec = encoded.decode('utf-8')
    print(enc_dec)
    return enc_dec

Submitting Changes to the GitHub Repository Submitting the file back to the GitHub repository involves a few more steps. A GET request is made to the Git branches endpoint, /repos/{owner}/{repo}/branches/{branch}, to check if a new branch (e.g. update/developer-portal-opt-in) already exists.

If the branch does not exist, it is created from the main or master branch, depending on which one is present in the repository, using refs/heads/{branch_name}\'.format(\*\*locals()). Finally, the pull request with the encoded Base64 YAML is submitted to the branch using the GitHub endpoint /repos/{owner}/{repo}/pulls.

Adoption and Impact​

Initially, the adoption of a new developer portal can face challenges for several reasons:

• Engineering teams may be hesitant to merge unfamiliar pull requests into their repositories or services.
• Some teams or engineers might lack a robust understanding of the new portal's purpose or value.
• The new tooling might not be a strictly defined, top-down mandated requirement from leadership.
• Access requests might still be required, even for a centralized portal.
• Customer adoption can be slow, sometimes requiring individual demonstrations even after widespread presentations.
• Some individuals might understand what the portal is but not its full capabilities or limitations.

Gaining Traction and Growth

Despite initial hurdles, a new developer portal can gain immense traction and adoption after numerous pitches to various teams. A key factor in widespread adoption often includes contributions from various engineering teams beyond the initial implementation group.

The transformation can primarily be driven by a concerted effort to understand team needs, strategically "sell" the platform's value, and address early friction points. The key to this success lies in demonstrating tangible benefits and integrating features that directly solved developer pain points.

Understanding Team Needs​

During the discovery and initial implementation phases, it became clear what capabilities teams truly desired from a developer portal:

• Visibility into Ownership and Relationships: Teams were highly interested in features like a dependency graph or organizational chart. They wanted clear visibility into service ownership and relationships between different services, enabling them to quickly identify whom to contact for specific issues or collaborations.
• Service Discoverability: Once they grasped the concept and value of having their services represented in a central catalogue, teams actively sought to have their services migrated or ingested using the scaffolder. Their motivation was clear: they wanted other engineers to easily find and understand their services within the portal.

Strategies for Selling the Idea​

A combined approach was crucial to effectively "sell" the developer portal idea to various teams:

1. Clear Roadmap: Presenting a comprehensive roadmap that outlined the portal's current state and its future potential helped teams envision its long-term value.
2. Engaging Presentations and RFCs: Conducting engineering presentations to numerous teams and sharing Requests for Comments (RFCs) allowed for broader review, gathered valuable insights, and fostered a sense of community involvement.
3. Highlighting Discoverability: Emphasizing that their services would be easily discoverable by other teams and that the portal would serve as a single source of truth for all component information related to their services was a powerful selling point.
4. Personalized Demos: Conducting 1:1 Slack huddles with individual engineers to demo the platform provided a personalized experience and allowed for direct addressing of questions.
5. Visual Aids: Utilizing diagrams of various components and illustrating their benefits helped simplify complex concepts and showcase the portal's advantages.
6. Addressing Codebase Concerns: When submitting the automated pull requests with the migration script, it was crucial to explain to teams that these changes would not result in any loss of functionality, nor would they have any adverse effects or modifications to their existing codebase.

Addressing Early Friction​

Despite these efforts, initial friction was inevitable:

1. Pushback on Automated PRs: There was initial pushback regarding the automated pull requests submitted to their repositories.
2. Reluctance to Merge: Engineering teams were hesitant to merge a "random" PR into their repositories, especially without a full understanding of its purpose.
3. Lack of Understanding: Some teams simply didn't have a robust understanding of what the portal was or its value, leading them to either not merge the catalog-info.yaml PR or, in some cases, even delete it.

Through persistent engagement, clear communication, and demonstrating tangible value, these initial resistances can be gradually overcome. The strategic addition of features and the active involvement of other engineering teams, particularly those focused on reliability platforms and SRE, proved instrumental in demonstrating the platform's utility and appeal.

Feature Additions Driving Adoption​

The addition of components like a Tech Radar can significantly increase engineer interest. A Tech Radar is typically implemented to help engineers and cross-functional teams understand the "paved road" technology stack, what should be used for new systems andwhat existing systems should aspire to move towards. Thoughtworks created this system and can be seen here: https://www.thoughtworks.com/en-us/radar

Some other plugins that can increase widespread adoption of a developer portal:

1. Q/A Plugin
2. Groups or teams plugins
3. Kubernetes plugin
4. Managing External services

A critical component that contributes to widespread adoption is the linter plugin. For developers migrating services to the new developer portal, ensuring the catalog-info.yaml. file is correct and accurate is paramount. The linter plugin, often integrated with an external API, provides an invaluable and accurate way to validate these files, making the process of creating and maintaining them much easier and less error-prone for developers. One of the most accurate ways to implement the linter plugin is making a request to Entity validator to make sure it is correct.

Complementing this, a Scaffolder feature also plays a vital role. The Scaffolder allows developers to generate new service or component catalog-info.yaml files (and often entire project structures) from pre-defined templates. This capability effectively eliminates the need for developers to manually create these files from scratch or worry about linting them, as the generated output is inherently compliant with the portal's schema.

Ultimately, such efforts can successfully ingest hundreds of services, leading to a significant number of components residing within the new developer portal.

Conclusion​

The migration of legacy internal services to a modern developer portal like Backstage represents a significant leap forward in standardizing and streamlining developer experiences. By transitioning from an internally maintained "App Catalogue" to a centralized, community-driven "Developer Portal," organizations can lay the groundwork for enhanced collaboration, improved resource accessibility, and accelerated development cycles. Despite initial adoption challenges, the strategic implementation of features like the Tech Radar and the linter plugin, coupled with persistent outreach and contributions from various engineering teams, proves instrumental in demonstrating the inherent value of such a platform. The successful ingestion of hundreds of services stands as a testament to the effectiveness of automated migration scripts and the dedication of the teams involved. This endeavor not only provides a robust and less over-engineered service catalogue but also fosters a culture of shared ownership and continuous improvement within the engineering organization.

What's Next​

My involvement as a software engineer with open source tools and developer portal projects like Backstage, including implementation and service migration, has provided me valuable opportunities to contribute to their open-source documentation and repositories. This can be seen in contributions such as Update app-custom-theme.md and Update getting-started.md, which deepen understanding of custom themes and style components. I’m now looking at future efforts focusing on contributing more to the open-source project (e.g., Model context protocol with A.I (MCP) at RFC: Distributed Actions with MCP in Backstage) and continuing to improve and scale this critical developer portal for engineers across the world.

Stage 1: Laying the foundation​

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. Specifically, the “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​

With my foundational skills in place, it was time to take the leap and make my first contributions to Backstage. My first pull request (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. I found an issue about linking npm releases of plugins to specific Git commits — 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 and Special Interest Groups (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 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. 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 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

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 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​

(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 (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. 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 (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.

Wow, London sure didn't hold back! Five years 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 you missed.

London called — the Backstage Community answered​

📸 CNCF

Scenes from BackstageCon​

📸 CNCF

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​

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.

#2: Panel: What Do Cars, Clothes, Wardrobes and MRI Machines Have in Common?​

📸 CNCF

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.

#3: Lightning Talk: We Built a Unified AI Asset Catalog in Backstage​

📸 CNCF

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.

#4: Exemplar-y Backstage Templates​

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.

#5: From Click To Chaos: Linking Argo Workflows and Backstage for Automated Testing​

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!)

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.

Breaking through the bustle at KubeCon + CloudNativeCon​

📸 CNCF

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​

📸 Spotify

It was standing room only for the core maintainers talk — The State of Backstage in 2025 — 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.

Big birthday energy on the big stage​

📸 CNCF

With the project just turning five, Backstage got a nice Happy Birthday 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.

Backstage Contribfest goes across the pond!​

(Hey, that's me! Thanks for all the great pics, 📸 CNCF)

After a successful appearance last year in Salt Lake City, 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!

Cheerio, London! What's up, ATLiens!​

📸 CNCF

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? Guess we'll find out in Atlanta this November!

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…

5️⃣: 60k+ Contributions from a Global Community of Very Busy Beavers🦫​

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, 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) 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​

Speaking of commits, rewinding back to KubeCon + CloudNativeCon Europe 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 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!​

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. 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. Or meet us in 💂‍♂️London in April for BackstageCon and KubeCon + CloudNativeCon Europe 2025!

4️⃣: 210+ Open Source Plugins (and Counting)🧩​

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, PagerDuty, Rootly), in-house plugins going open source (like these from DAZN, Keyloop, and SeatGeek), essential plugins built and maintained by ecosystem champions and supporters (AWS, GCP, Roadie, Spotify), as well as creative and useful 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 five of the seven plugins they've open sourced, including their Awards Plugin and Entity Scaffolder Plugin.

By spring🌷, new plugins for Linkerd and Black Duck had sprung onto the scene.

During the summer☀️, the official PagerDuty 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, Datadog, GitHub Actions, Grafana, Jira, Kubernetes, and Tech Radar — had already been updated to support the very latest versions of the Backstage framework's New Frontend System and New Backend System. (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 — 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!

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.

With release tooling, workspace tooling, and migration guide all included, the new repo 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 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!

3️⃣: 278 Companies Listed in ADOPTERS.md💚​

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 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, Fortnox, Wefox, Aurora Innovation, ENSEK, OP Financial Group, Scania, Senora.dev, Covestro, Grupo OLX, DPG Media, Baloise, Cigna, Evernorth, Infobip, CloudScript, Alauda, New10, Tele2 Kazakhstan, Altel Digital, and Axelerant.

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. We've read your insightful blog posts. We've heard your engaging adoption journeys. We've enjoyed your automation workshops. And we've celebrated your well-deserved awards.

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 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🎓​

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 the launch of a new 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!

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.

1️⃣: Version 1.0 of the Future of Backstage🎉​

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!), 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 from Bol.com!), big strides in the plugin-building experience in the New Frontend System — 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 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!

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 and migrating plugins. 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 or through issues on GitHub. If you're looking for a way to help, take a look at these open issues in the backstage and community plugins repos about deprecating old backend capabilities of already migrated plugins. To the future we go!

We won! Hooray to the community! 🏆​

To cap off the year, last week Backstage won the "InfoWorld 2024 Technology of the Year Award for Software Development: Platforms"!

Congrats to all the project maintainers, 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!

As an Incubating project within the Cloud Native Computing Foundation (CNCF), Backstage is fortunate enough to take advantage of sponsored continuous security audits. The Open Source Technology Improvement Fund (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, 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.

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, while the majority of the side findings were addressed by the 1.32 release. For details on all findings, see the full audit report.

We are happy to see that there are no repeated vulnerabilities, perhaps in part due to our new secure coding practices following the previous audit, as well as the introduction of the Backstage 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 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 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 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
• OSTIF Blog Post
• Full Audit Report
• Backstage Threat Model
• Backstage Security Policy

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 are available for replay on YouTube. Read on for the highlights — plus, photos of super cute pups — as a treat! 🐕

What everyone was talking about at BackstageCon🦫​

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.

• Himanshu (Harness) shared strategies for adopting Backstage in ways that drive meaningful value for engineers.

• Eric (Quantum Metric) explained how startups can benefit from what big techies have been contributing to Backstage.

• Tom (Spotify) shared how developer productivity furthers Spotify’s mission to empower creators and what the future holds for Backstage.

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, 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 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 belongs inside Backstage portals to facilitate centralized compliance — so your devs don't get held up from going to prod by unforeseen checks.

Maintaining a Backstage instance​

• Djamaile and Mitch (Spotify) provided actionable tips 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.

• Paul (Red Hat) presented a platform engineer’s POV 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.

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 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 of your cloud native applications.

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 using artificial intelligence prompts.

• Ben (Red Hat) outlined broader AI integrations 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.

Backstage at the big show: KubeCon⎈ + CloudNativeCon☁️​

📸 See more KubeCon photos from the CNCF’s Flickr album →

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​

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” — for all the details.

Toyota and Akamai in the house​

📸 CNCF

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”: 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”: Tomer dives into development efficiency and how you can “conquer cloud-native deployments by adding the right tools, such as Argo Rollouts and Backstage”.

And the award goes to…​

📸 CNCF

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, 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: “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!

A bustling CNCF project pavilion​

📸 CNCF

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), 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👩‍💻​

📸 Spotify, CNCF

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
• Add Home Page Quick Start Card
• Truncate commit message to first newline

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 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” station.

(All 📸 CNCF. Please note: the last pup is not a pup.)

The best labrador-retriever pup graciously accepting pets from the cloud native community.

The best fluffy white pup surrounded by admirers.

The best racing-style pup getting face scritches.

The best yellow pup getting pets from his twinsie.

See? Not a pup. But did get pets.

You, too, can give these pups some love.

Cheerio! We’ll see you in London!💂​

And that’s a wrap on Salt Lake City! Join us in London in April for more community-building fun at BackstageCon and KubeCon + CloudNativeCon Europe 2025!

• 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.

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, Robert, 2008). Consequently, the need to standardize project creation became crucial to ensure corporate governance and compliance even before the first commit was pushed.

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, 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). 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.

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

• Fetching runtime security vulnerability information across different stages

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.

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 to document Golden Paths — 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:
“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, I could easily browse the components my team owns, find the source repo and documentation.

Reflection:
“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:
“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 and follow the best quality standards.

To do so, we use a plugin called 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:
“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, 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:
“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 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:
“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:
“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:
“Do you find yourself wondering if someone else already did it before starting a task?”

With the Backstage Search plugin, 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 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:
“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. It was, after all, made by engineers for engineers. 💚

Special thanks to Stanley Nicholl, Patrik Oldsberg, Vincenzo Scamporlino, Mihai Tabara, Emma Indal, Raghunandan Balachandran for all of their support.

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.

The community plugins repo​

Some of you who have been around a while, or have seen our Maintainer Track talks at KubeCon, might have seen this RFC 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 or plugin 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 maintainers, who have been helping get us to this state! @vinzscam @tudi2d @bethgriggs @kadel @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. 🎉

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:

# < 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 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 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.

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 or in an issue on the community repository.

If you're wanting to contribute some plugins to Backstage, the community plugin repository is open for business 🎉 and we're looking forward to seeing what you come up with! Head over to the community plugins docs to get started creating your own workspace!

Thanks!

Celebrating Four Years of Backstage​

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 (SIGs) has grown, and more people are dedicating their time to new 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.

Via Cloud Native Computing Foundation on Flickr

With hosts like Balaji Sivasubramanian (Head of Product Management, Red Hat) and Helen Greul (Head of Engineering for Backstage, Spotify) kicking things off, 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 (Senior Manager, Bankdata) gave an exciting talk about how “Backstage Made 500+ Developers Happy” in the highly regulated banking industry.
• Scaling up: On the topic of scaling Backstage — a frequent subject on our Discord — Vincenzo Scamporlino (Senior Software Engineer, Spotify) gave us his recommendations 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 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 (Senior Product Manager, Spotify) was representing Backstage in her talk "Boosting Developer Platform Teams with Product Thinking".

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 (Senior Engineer, Spotify) and Ben Lambert (Senior Engineer, Spotify) gave us a great overview on “The State of Backstage in 2024” 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 on Thursday morning, 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!

Top 10 CNCF Projects by Number of End User Commits

Day 4: Au revoir! See you at the next one!​

You can catch up on all the talks from BackstageCon and the rest of the week on the CNCF's YouTube channel. See you in Salt Lake City in November at KubeCon + CloudNativeCon North America!

Last week we were notified by Roadie 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.

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 for replay on the CNCF YouTube channel.

Obviously we're biased, but Backstage was definitely one of the big topics at KubeCon + CloudNativeCon North America this year. Recently, the CNCF announced that Backstage was the third fastest-growing project 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, 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, 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.

Helen Greul, Head of Engineering for Backstage at Spotify, hosted a panel discussion 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. And from Grafana Labs, we heard how they're using Backstage along Crossplane to drive GitOps.

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) and Patrik (Rugvip), core maintainers, presented an introduction to the plans around Declarative Integration, 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, 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.

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) "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!

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.

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.

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 and BackstageCon EU are accepting CFPs, submit your proposal now!

TL;DR Chicago Trading Company (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 who shared the details of their onboarding journey, lessons learned, and insights for other Backstage adopters.

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 — due to the 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 and Expedia Group.

Want to learn more about Backstage? Join our weekly Office Hours and bring your burning questions.

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. 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 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.

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, 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.

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.

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 back in 2021.

Read more about Expedia's tech journey on their Medium Blog

At Frontside, 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.

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 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.