Top 4 Backstage alternatives for 2025

This post was updated on 19 November 2024 to address changes in the competitive landscape for internal developer portals. Port updates posts regularly to provide the highest-quality information possible to our readers.

{{cta-demo}}

If you’ve heard of internal developer portals, chances are you recognize the name Backstage. Backstage is an open-source framework from Spotify for building internal developer portals. It pioneered the idea of internal developer portals, sparking interest in platform engineering. In March 2020, Backstage was open-sourced and contributed to the Cloud Native Computing Foundation (CNCF). 

What problems does Backstage.io solve?

Backstage provides a framework for building a portal that aims to better manage infrastructure and enable teams to ship high-quality code quickly. It aims to do this by:

• Providing autonomy to development teams to ensure that teams can maintain their speed even with complex software ecosystems
• Centralizing and standardizing tooling, so that engineers can be freed from infrastructure complexity
• Provide better visibility and discovery of an organization’s software and services
• Making it easier to access documentation through direct integration with the development workflow
• Standardizing the creation of new services and components
• Improving the management of an organization’s infrastructure
• Offering customization options

When these features are combined, the portal enables faster software development, which boosts developer satisfaction and efficiency. 

What are the challenges with Backstage?

Despite its pioneering status, organizations implementing Backstage face significant challenges, particularly with development effort, time, and maintainability. Backstage can take longer to set up and launch than organizations anticipate: Gartner has previously said it sees organizations mistakenly believe that Backstage is a ready-to-use portal that requires no additional work. This rude awakening during implementation can lead to disillusionment, and the project either being put on hold or abandoned altogether. In more recent research, Gartner said that a custom internal developer portal like Backstage requires more time, effort and development skills than many platform engineering leaders expect. 

This is partly because Backstage is a React framework and many of these leaders are more proficient in backend tools —  using a front-end tool can be daunting for them. Gartner says organizations should expect to dedicate two to five engineers on Backstage for several years, but this is a conservative estimate, with many organizations dedicating far more than this.

In addition to a significant front-end cost, a project or product manager is required to manage Backstage. Without one, teams may spend up to a year developing their portal without seeing tangible results. 

Additional features such as scorecards and RBAC come at a cost, too. The solution-agnostic online community www.internaldeveloperplatform.org estimates that Backstage’s true cost of ownership is around $150,000 per 20 developers. So while it is free in theory, the hidden cost is so high that in the end people look for more effective commercial alternatives. 

Despite Spotify recently announcing a SaaS version in beta, called Spotify Portal for Backstage which competes with other ‘managed Backstage’ alternatives — the sheer amount of resources required  remains a key issue. Setting it up requires a lot of work, substantial customization and developer resources. Even when those investments are made, it is challenging to maintain, both as an open source project and also due to some of its limitations, which include:

‍Custom development plugins are a must for developing Backstage because every organization is unique. However, the Backstage community plugins do not have ongoing support or maintenance because they are developed by independent open-source engineers. This can introduce security vulnerabilities to your project — in fact, there are only ~20 Spotify ‘vetted’ plugins, and hundreds of ‘non-vetted’ plugins for Backstage - they openly state that the plugins haven’t been fully vetted by the core Backstage team. 

Another example is that populating the software catalog involves asking developers to manually create static YAML files, which presents an almost immediate barrier to adoption, as developers need to do something before they get any value from Backstage.  

Moreover, the fixed data model of the service catalog in Backstage limits flexibility and customizability, and real-time data integration is not supported, complicating tasks like incident management and API monitoring. Maintaining Backstage can be burdensome due to its reliance on static configurations that need constant updates. This can lead to regular breaking changes, outdated information and operational inefficiencies.

Backstage Software Templates are not very effective for performing a wide variety of self-service actions. Tasks like deploying services, rolling back changes, triggering incidents, creating cloud resources, toggling feature flags, adding secrets, obtaining temporary database permissions, and setting up development environments are almost impossible to execute directly through Backstage because it lacks built-in support for these functions. As a result, while developers can create new service templates using Backstage, it falls short in supporting more critical day-2 operations tasks.

A common fallacy with regards to Backstage is that its plugins can fix many of the issues above. In real life, both the fixed data model and manual ingestion cannot be solved with plugins. This is because the software catalog doesn’t use a central metadata store, and therefore plugin data can’t be searched. This makes it impossible to answer questions such as “which services have open incidents?” because it’s incredibly difficult to adjust the level of plugin data abstraction to show more or less detail or display it differently.  The plugins also don't allow for querying data or creating scorecards, limiting their value significantly. 

While Spotify reported a voluntary 99% portal adoption rate internally for Backstage, other engineering organizations that tried to implement it reported an average adoption rate of around 10%. This could be the result of the lack of flexibility, functionality and slower than expected rollout.  

{{reading-box-backstage-vs-port}}

Top Backstage.io alternatives

Open internal developer portals

Port

Port is an open commercial platform for building your own internal developer portal with no-code or low-code abilities. It offers numerous features out-of-the-box, rapid deployment, and swift iterations for fast time to value compared with other portals. It also provides a high level of flexibility and functionality, which differentiate it from both the rigid commercial portals on the market, as well as Backstage offerings. Port is flexible, meaning that you can make it fit your opinionated internal developer platform. This allows developer autonomy, standards compliance, and engineering excellence in exactly the way you need.

Port provides an end-to-end developer experience in one centralized hub. This way, developers can use the portal to find everything they need to know and do: from planning their day and development processes to shipping features and post-production operations. Developers will also be able to immediately know what’s required of them in terms of standards compliance, giving managers the visibility and peace of mind that this is taken care of.

The platform comes equipped with a flexible data model, which means you can change the entity types and customize the metadata model to evolve the portal as requirements change, enabling you to cover current and future use cases easily, as well as changes in the organization. You can integrate with the tools you’re already using, while adding context to your data; you can see all of the data in context in one centralized metadata store, meaning you can query and search for anything SDLC-related in one place. 

The plugins — which cover a broader range than open source portal tools — are secure, on-premise exporters that are maintained and vetted. They are also community-driven through Port’s Ocean framework, meaning no coding is required. However, for builders that want to make additions, Port welcomes coding.  

‍Port’s self-service actions support both synchronous and asynchronous actions. It can trigger workflows either with a webhook, or preset existing invocation types such as GitHub, Kafka, etc., with no need to set up an endpoint. In addition, unlike alternatives, it offers many day-2 operations as self-service actions to:

• Rollback services
• Restart running services
• Add a secret
• Change the ownership of a service
• Provision ephemeral environments

Port aims to provide an end-to-end experience for developers, helping them to adhere to standards with easy-to-establish and follow golden paths. It aims to help the team reach its wider objectives, such as improving developer productivity or optimizing costs.

You can drive compliance and standards with scorecards and initiatives — unlike other portals, Port supports custom scorecards and can show ripple effects of service degradation with detailed entity dependency graphs. Any user can create scorecards, and they can be evaluated in real-time for immediate insights. 

Platform engineers can drive adoption with user-centric experiences, with views and actions for teams, roles, and personas within the organization. They can use granular RBAC, customizable dashboards, and folders. They can also send announcements directly from the portal, keeping everyone in the loop and engaged across the organization. In addition, Port enables teams to perform surveys, gather developer feedback, and collect feature requests directly within the portal.  

Port is API-first, meaning all of its functionalities and data can be exposed through APIs, promoting interoperability and automation with other platform tooling. 

Examples of Port’s flexibility include:

• Full support for configuring the portal using Infrastructure as Code (IaC) frameworks such as Terraform, Pulumi, or Crossplane, enabling seamless integration with DevOps workflows.
• A fully customizable and extensible data model where users can define their own entity types (e.g., services, resources, teams) without restrictions.
• Highly flexible self-service actions with support for custom configurations, asynchronous processes, API-triggered actions, TTL settings, and manual approvals for workflows.
• Advanced schema support allows custom properties to be displayed in catalog tables or dashboards, enabling SRE teams to automatically generate resources like monitoring dashboard URLs based on service names.
• Complete customization of UI components and dashboards to match specific organizational needs and branding.
• Dynamic and granular permission controls to support varying levels of access for different user roles.
• The ability to track long-running processes and provide detailed logs for developers to debug or monitor workflows effectively.
• Notification and alerting capabilities to ensure timely updates and communication.
• Support for ingestion and full-text search of Markdown files, enhancing documentation accessibility and discoverability.
• A framework that allows users to build their own integrations with external systems and tools.
• Seamless integration with cost management tools to provide insights into cloud or infrastructure spending.
• Built-in tools for surveys, feedback gathering, and feature request collection to improve collaboration and product development.

{{cta-demo-baner}}

Home-grown internal developer portal or tooling

The first step many organizations take is to offer full or partial portal functionality to their developers.  This can be delivered through:

• A self-service interface, usually a CI tool like Jenkins.
• A service catalog of sorts to help discover information and see it in context, through a spreadsheet, a CMDB, or some other tool. 
• A solution to ensure standards are met — typically production readiness but also AppSec and cost.
  

Sometimes organizations combine these and build a full in-house internal developer portal. This is more typical of very large engineering organizations with multiple DevOps or platform engineers. 

In our experience, these in-house, hyper-customized portals work well at the outset but are difficult to maintain over time, since the organization’s requirements evolve as time passes. Portals are part of broader platform engineering initiatives. As patterns change, CI/CD is added, and processes  or tech stacks change, so do the requirements of the portal. Each of these changes may present a breaking point for the portal or require a large and unexpected development effort.

While the choice to build your own portal may have made sense at some point in an organization’s software development journey, there will come a time when the engineering manager has to consider investing further effort in such a portal, or ignoring the sunk costs and moving forward with a suitable alternative. Typically, commercial portals that are flexible enough can replicate the functionality of an in-house portal and then immediately offer a broader feature set that will drive better personalization, automations, dashboards, and developer experiences to portal users, at what typically ends up being a fraction of the cost of maintaining a team to evolve the original in-house portal.

Managed Backstage 

Managed Backstage offerings such as the Spotify Portal for Backstage and Roadie provide Backstage-as-a-service. The aim of managed offerings is to eliminate the overhead of using open source software and to add features and capabilities. 

Spotify Portal for Backstage aims to provide an easier installation process for Backstage, with built-in features. It enables users to manage plugin configuration through a UI and requires less coding than building and managing a custom Backstage instance. 

Roadie aims to overcome the issues of standing up and maintaining Backstage by providing a single-tenant SaaS instance, with regular automated updates, SSO, and dedicated infrastructure. Roadie enables you to deploy your own Backstage plugins into your instance, and also provides custom API renders, Kubernetes integration, and a paid add-on for scorecards.

While managed Backstage offerings enhance existing Backstage implementations, making it simpler to use and providing more features, if you’re starting to build a portal from scratch, you’ll encounter many of the same problems as you would with open-source Backstage, such as the rigid data model and the lack of self-service actions for day-2 operations. 

Though managed solutions offer more features than open-source Backstage, they still provide less value out of the box than other alternatives. Indeed, as with Backstage, Roadie and Spotify Portal for Backstage will cost more in the long-run than the initial outlay, due to resources (both human and financial), paid plugins, and because the underlying product still lacks significant flexibility and functionality, meaning it will not fit an organization’s specific DNA in the long-term. 

The release of Spotify Portal for Backstage indicates that the company acknowledges that using Backstage to build a portal requires far too much investment, technical know-how and resources, without providing the same value as alternatives. It also means a switch for the company from leading an open-source project to becoming a vendor in its own right, altering Backstage’s perception in the platform engineering and developer community. 

Rigid internal developer portals 

Cortex

Cortex is a commercial internal developer portal that has its merits in comparison to Backstage; it suggests a lower total cost of ownership (TCO), faster setup, and easier extensibility. Its origins are a tool for managers to enforce standards, but with a lesser focus on flexibility and developer self-service. As a result, user adoption can be challenging. 

Many of the features it touts rest on rigid, inflexible foundations (despite recent announcements aimed at making the data model for the catalog more flexible). For instance, Cortex’s self-service actions lack a dynamic range of role-based access control (RBAC) and day-2 capabilities. This means that, for instance, you can’t set a rule that grants automatic temporary permissions to someone that’s on-call, or ephemeral environments with a TTL that terminates automatically. What’s more, the number of use cases for its workflow feature are limited; there are far more use cases for portals that enable users to create advanced workflows from any change in the catalog. 

Other examples of inflexibility include:

• Not being able to configure the portal using an IaC framework (Terraform, Pulumi, Crossplane, etc.) 
• Having a semi-flexible data model where there are several fixed entity types that cannot be changed (services, resources, teams)
• Rigid self-service actions (i.e., no customization, lack of support for asynchronous actions). The self-service actions use HTTP webhook, requiring endpoint setup. You can’t trigger actions via API, and there’s no TTL support, or manual approvals.
• Only supports basic JSON schema, meaning custom properties are not displayed in catalog tables or dashboards, meaning for example, an SRE team cannot automatically generate monitoring dashboard URLs based on service names.
• Inability to fully customize the UI or dashboards.
• No support for dynamic or granular permissions. 
• Cannot reflect the process of long-running actions or provide logs to developers
• Lack of support for notifications or alerts
• Cannot ingest or search Markdown files
• Does not allow users to create their own integrations
• Does not integrate with cost management tools
• No support for surveys, feedback gathering, or feature request collection

Despite being a portal focused primarily on standards, its scorecards are limited by:

• A lack of customization, meaning you can’t show the ripple effects of service degradation with detailed entity dependency graphs), dashboards and homepages. 
• An inability to create an elaborated ownership model both on the catalog and on scorecards and scorecard rules.
• Not being able to extend scorecards and rules with any data and base experiences on it (such as due dates, SLAs, categories, URLs and descriptions).
• An inability to trigger actions and automations based on a scorecard result, and create elaborated workflows.
• Evaluation of scorecards is carried out every 4 hours, leading to delays.

Crucially, Cortex’s catalog only supports real-time ingestion for a few data sources; others update hourly or weekly. Cortex’s portal only supports a Kubernetes catalog for services, meaning there is no K8s object visibility, making it more difficult for devs to understand their services without prior Kubernetes knowledge. It also does not provide TechDocs. 

OpsLevel

OpsLevel is another commercial internal developer portal that provides extensive functionality out of the box, meaning it can provide faster time to value than alternatives such as Backstage. It provides a good UI for search, and supports TechDocs. 

However, its faster time to value comes at a cost; OpsLevel offers little in the shape of customization, restricting organizations with an opinionated data model that has fixed entities, which limits the number of use cases for the portal. It doesn’t support customizable views such as flexible dashboards or forms, meaning that it’s impossible to create required abstractions for developers and managers, and has limited permission-based personalization.  

With regards to self-service actions that can be triggered from the portal, OpsLevel only supports synchronous actions with an HTTP webhook, requiring endpoint setup. You can’t trigger actions via API, and there’s no TTL support or manual approvals. In general, these actions require considerable effort to fully integrate. There is no support for workflow automation — either to update the portal or for machine interactions in CI. There is no support for API-first development, meaning that users can’t, for instance, create a CI/CD software catalog.

While plugins exist, there is no extensibility framework to extend the portal with your environment’s data from products, business units, user certifications, feature flag databases, and more. Basic service metadata is saved using YAML, which creates overhead for developers, and means that the catalog isn’t as reliable because it is not updated in real time with DevOps tools as a source of truth. This can erode trust with users and impact adoption, just as is the case with Backstage. 

Like Cortex, OpsLevel only supports a Kubernetes catalog for services, meaning there is no K8s object visibility. This makes it more difficult for devs to understand their services without prior Kubernetes experience. OpsLevel offers a basic audit log where users aren’t able to track entity changes or ingestions by source, and it offers basic RBAC. 

Atlassian Compass 

Atlassian Compass is a lightweight internal developer portal that may interest engineering teams that already rely heavily on Atlassian’s other products such as Jira, Confluence, and Bitbucket.

The portal, which it calls an ‘internal developer platform’, includes a catalog, scorecards, engineering metrics, and templates. 

The Compass catalog enables teams to add components manually, via API or by importing them from an SCM tool. Users can see the list of components and search them through various fields. Admins can also announce changes about components to relevant teams. However, Compass relies on a rigid data model, meaning it cannot incorporate cloud resource data, or add parameters and relations between services. Its lack of identity provider data means that assigning ownership information for service catalog entities is more complex. 

Compass’ integrations with other Atlassian products may prove useful, but the portal lacks other integrations and has no extensibility framework. This means users cannot extend their portal with data on products, business units, user certifications or feature flags, among many other items. 

While users can store component metadata that is relevant to them, Compass lacks the ability to customize views for different personas, and while permissions are also not supported, this means admins cannot provide restricted views to users. 

While Atlassian is striving to deliver a better developer experience with Compass, it only partially solves many of the friction points that developers face day-to-day. For instance, its templates feature only caters to scaffolding a new service — it does not support any action, including day-2 operations, meaning it is harder to define and enforce a golden path for developers. 

Compass does not support working with any backend services, meaning that users cannot trigger any actions such as interacting with IaC, a CI pipeline, or internal tools. There is also no support for automations to trigger pipelines or changes in the catalog, which means that, for instance, users cannot create an automation to request temporary permissions and automatically set them to expire after 48 hours.

Despite Kubernetes being an integral part of organizations’ SDLCs, Compass does not support a comprehensive Kubernetes catalog, meaning that developers cannot see their services in Kubernetes without in-depth knowledge of the platform.

Maintainability is also a challenge for managers of Compass. Data ingestion is carried out by maintaining YAML files, which causes a significant overhead for developers, as the data is not as reliable because it is not updated in real time. It does not support functionality or exposing data via APIs, and also does not support configuration changes using IaC tools such as Terraform and Pulumi. 

Best of both worlds

Backstage with Port’s plugin

It’s understandable that organizations that have invested heavily in Backstage will want to make their custom Backstage instance a success, and therefore they may be reluctant to shift to an alternative. However, there is now a way to cut down their development time.

‍Port’s new plugin for Backstage enables teams to implement Backstage faster. Installed like any other Backstage plugin with a SaaS portion, the Port SDK is integrated directly into Backstage. It provides a data engine equipped with a catalog builder, scorecards, self-service actions, and more. 

Port sits between an engineering team’s data sources and the Backstage UI, enabling the team to shape and control their own data model. By connecting Port’s engine to Backstage through an API, teams can replace multiple isolated plugins with one integration, reducing the amount of plugins required and the need to open up a number of integrations out-of-the-box (e.g., Jira, GitHub, ArgoCD). 

Port’s Backstage plugin also minimizes the need for custom plugin development, reducing overall development time and boosting efficiency. New integrations are simpler to configure as they don’t require developers to use the React framework. 

The plugin supports Backstage as a source of truth by pulling initial data from Backstage, enriching the data within Port, and pushing the data back to Backstage so that the information is up-to-date. There’s also the option for Port to serve as the primary source of truth for data.

The Port plugin for Backstage enables teams to create scorecards with minimal coding, build self-service actions quickly, utilize RBAC, and more. 

{{port-for-backstage}}

Summarizing your options

It’s difficult to know where to start when comparing portals. Here are some of the things you should consider:

• Low TCO and fast time to value: Choose a portal that requires minimal coding and resources for setup, allowing for a quick launch, MVP, and measurable benefits.
  
  
• End-to-end experiences: Ensure the portal supports the complete software delivery lifecycle.
  
  
• Flexible and future-proof: Opt for a portal that supports your organization’s unique processes and can evolve over time.
  
  
• Personalization and abstractions: Tailor the portal to fit different user roles and needs, providing the right information to the right users.
  
  
• Maintainability: Ensure the portal remains current and easy to maintain, with capabilities for auto-discovery and real-time updates.
  
  
• Easy integrations: The portal should integrate seamlessly with third-party tools, making data functional and accessible.
  
  
• Automations: A portal should be able to leverage automations for process orchestration, improving efficiency and reducing manual intervention.
  
  
• Security by design: Robust security measures should protect both the portal and the development environment.
  
  
• Enterprise-ready: Ensure the portal meets security, compliance, and reliability standards for large enterprises.

{{cta-demo-baner}}