Top 5 Backstage plugins for 2025

December 10, 2024

Top 5 Backstage plugins for 2025

Ready to start?

Introduction

Internal developer portals were first widely introduced in 2020, with the release of Spotify’s Backstage. In the same year, Backstage announced a plugin ecosystem and invited developers to create plugins to enable better portal development and extensibility. 

Most internal developer portals offer plugins to integrate with your tech stack, which is how they offer value. The portal takes the data from each platform and presents it to you in a single UI, where you can build self-service actions for developers, streamlined system monitoring by service, and dashboards for leadership.

Backstage’s community plugins typically offer more flexibility and specificity than the core set of Backstage plugins. In this article, we’ll discuss some of the best Backstage plugins and how they can offer additional features and insights to your development teams.

What are Backstage plugins?

Backstage offers a directory of open-source plugins, some developed by the Spotify team and others by its community of developers. Each plugin offers additional functionality to your Backstage portal, from authentication/authorization to productivity management and chaos engineering. 

Backstage separates its plugins into two categories: core features, which are developed by the Backstage team, and their larger plugins catalog, which includes paid plugins from Roadie, the paid version of Backstage, and others throughout the software industry. 

Though Backstage is free and offers many plugins, this does not mean that Backstage doesn’t cost anything to configure and implement successfully. It also does not mean that the plugins work together as soon as they are installed — Backstage’s plugin architecture has been designed to stand alone, which makes them difficult to configure to work with other plugins.

According to InternalDeveloperPlatform.org, an out-of-the-box instance of Backstage can require up to $150,000 of routine investment in maintenance time, including the time of up to 20 engineers who participate solely in maintaining and optimizing the portal. Plugins help add necessary features and make Backstage development easier. 

Top 5 Backstage plugins

Since there are many Backstage plugins, we’ve gathered five together to review their features and highlight their value to your internal developer portal. What we’ve chosen will help streamline your data modeling needs and enable platform engineers to build great portal experiences.

Port <> Backstage plugin

One of the biggest challenges developers face with Backstage is its lack of a centralized, flexible catalog. This limits your ability to unify insights from across your software development pipeline — the plugins aren’t able to share data, so they can’t be used to answer questions like, “Do I have a Snyk vulnerability in production?” without using multiple tools, or developing additional plugins to do this work. This challenge usually results in additional investment of development time and resources, not only to build and configure plugins, but to test and maintain them as they scale.

Port’s Backstage plugin is a data engine that consolidates your entire tech stack into a single place while requiring significantly less development time. Port sits between all your data sources — like Jira, PagerDuty, and AWS — and the Backstage UI, and compiles that data into a software catalog builder, which enables scorecards, self-service actions, dashboards, and more. 

By connecting to Port’s engine through the API within Backstage, you can replace multiple isolated plugins with one cohesive integration, eliminating plugin sprawl and streamlining your setup into a focused, developer-friendly portal. You can also connect Port to a Backstage instance with existing plugins to unify data from their sources.

Port’s software catalog is also unopinionated, which means it can bend to your specific technical needs and make it possible for you to overcome Backstage’s fixed data model. Controlling your own data model is important, because it enables you to:

  • Address developer productivity by reducing or eliminating points of friction
  • Create reliable engineering metrics to track goals
  • Develop a scalable internal developer portal developers actually want to use

Using Backstage with Port gives you more flexibility to fully support your portal use cases, business objectives, and development team. You can learn more about Port by clicking the button below.

{{port-for-backstage}}

RAG AI Backend

The RAG AI Backend plugin is fairly straightforward — it enables the seamless integration of a Retrieval Augmented Generation backend into your Backstage instance. The plugin is built by Roadie, which is a paid internal developer portal built on top of Backstage. You don’t need to pay for Roadie to access this plugin.  

The RAG AI plugin allows you to prompt your own database and software systems using LLM prompts that use the contextual data from your Backstage catalog to deliver insights on your entire software pipeline:

 

A graphical representation of the data flow when querying your RAG AI instance. Image courtesy of Roadie

You can find the RAG AI Backend package, including configuration instructions, details about setting up vector embeddings, and more on npm.

Backstage DevTools

Backstage DevTools is an official Backstage plugin that helps you visualize the data in your Backstage instance in a front-end UI. Platform engineers will appreciate its ability to display data like external dependencies, unprocessed entities, and the running versions of each dependency, such as Node.js and Backstage itself.

Typically in a portal environment, the developer tools would be focused on self-serving different aspects of the development and deployment pipeline. The name “Backstage DevTools” is a bit misleading, as the tools are more geared towards engineering managers, team leads, and platform engineers instead of developers. Visualizing this data makes it easier to troubleshoot issues, review progress toward business goals, and monitor the quality and reliability of your running entities.

An info panel in Backstage DevTools. Image courtesy of Backstage

Backstage DevTools are developed by the Backstage team, which means that installing this plugin should be a quick way to gain insights into your software development pipeline. You can find the Backstage DevTools plugin on GitHub.

Feedback plugin

The Feedback plugin is a Backstage community plugin that allows you to solicit feedback from your team on specific entities in your service catalog. Essentially, it’s a brief survey tool that can be helpful in gathering anecdotal information about your software catalog while developers are actively using them. 

The Feedback plugin also integrates with Jira, so that if you notice bugs or fixes are needed for a specific service, you can create tickets to add them to your backlog or prioritize a hotfix. Below is the panel for the feedback on an example entity page:

Feedback gathered using the Feedback plugin for an example entity page. Image courtesy of the Feedback team.

These feedback tickets can also be helpful for addressing issues with your internal developer portal itself — developers who interact with various self-service actions, dashboards, or catalog entities can use the Feedback plugin forms to submit feedback on how these operations work, suggest improvements, and offer insights for how to improve the portal. 

You can find the Feedback plugin here on GitHub.

GitHub Actions plugin

The GitHub Actions plugin for Backstage is a community plugin that allows you to take more control of your GitHub Actions runs from within your internal developer portal. The GitHub Actions plugin integrates with Backstage to give you additional flexibility from within the portal, reducing your need to switch between the contexts of different tools. 

The GitHub Actions plugin offers the following features and functionality from directly within your portal:

List workflow runs for a specific project, which helps you with monitoring for issues or failures in deployment pipelines

  • Dive into one run to see a job steps and logs, which helps you drill down to any potential issues
  • Retry runs that failed

Though an internal developer portal can usually help you visualize many of these same things, the GitHub Actions plugin makes it much easier to visualize and troubleshoot from within Backstage, which can be difficult and more time-consuming to achieve without plugins. 

Operating in Backstage vs. other internal developer portals

Since Backstage was initially released in 2020, the internal developer portal landscape has matured significantly, with many other options emerging on the market with new features, different plugins, and smoother UIs. As the industry matured, Backstage received some criticism for its actual time to value. 

Despite Backstage being free and open-source, the actual cost to implement Backstage requires significant development time and investment. And while Backstage’s large plugin ecosystem makes the platform more extensible, it also requires significant development resources to construct according to your organization’s needs and tech stack.

One of the reasons Backstage implementation is time-consuming is because its data model is fixed, which makes it much more difficult to represent all of your important entities in the portal. Most Backstage plugins don’t really address this, as we detailed in a previous article about Backstage’s technical disadvantages. But these issues with the data model can’t be fixed with plugins, which limits the usefulness of your portal. 

Alternatives to Backstage

There are many alternatives to Backstage, as we’ve discussed in more detail in this blog post. Each option provides you with slightly different features and plugin options, and may be better suited to your specific needs. 

The Port plugin for Backstage is also a solution to some of the issues we discussed in the section above: because you can use Port’s UI to model Backstage data, you gain significant flexibility and better visual representation of all of your entities. Rather than exporting all of your data from Backstage into Port, you can use both together as a combined tool that is more user-friendly in Port, but reflects the data in Backstage. This reduces development time, and brings your overall time to value down.

Wrapping up

Backstage offers many other plugins besides the ones we’ve discussed in this post, though the ones we list here make significant improvements over Backstage as it comes out of the box. Though each plugin requires development time to implement within Backstage, the value they provide in terms of improving developer productivity, observability, and integrated ticket management.

Aside from the Port plugin for Backstage, Port itself is also a fully-fledged alternative to Backstage. Port is an open internal developer portal that provides you with a well-rounded UI and an unopinionated data model that gives you all the flexibility you need right out of the box. Learn more about Port here or sign up for a demo.

{{cta_5}}

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start