Top 4 Backstage alternatives for 2024

If you’ve heard of internal developer portals, the 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 both autonomy to development teams - to ensure that teams can maintain their speed even with complex software ecosystems, and by centralizing and standardizing tooling, so that engineers can be freed from infrastructure complexity.

Backstage strives to provide better visibility and discovery of an organization’s software and services, easier access to documentation through direct integration with the development workflow, a form of standardization to create new services and components, better management of an organization’s infrastructure, as well as offering customization of the portal. 

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 recently said it sees organizations mistakenly believing Backstage is a ready-to-use portal that requires no additional work, and that this can lead to disillusionment, with the project being put on hold or abandoned altogether.

Despite Backstage recently announcing a SaaS version in beta, this remains a key issue with Backstage. 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.

For example, 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 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 - making it impossible to answer questions such as “which services have open incidents?” - and because it’s incredibly difficult to adjust the level of plugin data abstraction - showing more or less detail - or displaying it differently.  The plugins also don't allow for querying data or creating scorecards, limiting their value significantly. Another issue with Backstage plugins is that there is no ongoing support or maintenance, which can introduce security vulnerabilities; in fact there are only ~20 Spotify ‘vetted’ plugins, and 120 ‘non-vetted’ plugins for Backstage. 

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.  

Further reading:
Read: What are the technical disadvantages of Backstage? 

Top Backstage.io alternatives

Open internal developer portals

Port

Port is a commercial platform for open internal developer portals; offering numerous features out-of-the-box, rapid deployment, no-code and swift iterations for fast time to value compared with other portals, while also providing 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 the day and development 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 knowledge 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. 

Port’s self-service actions support both synchronous and asynchronous actions. It uses webhooks and can trigger an existing CI job with no need to set up an endpoint. In addition, unlike alternatives, it offers day-2 operations as self-service actions, enabling you to rollback services, restart running services, add a secret, change ownership of a service, and so much more - providing an end-to-end experience for developers, and helping them to adhere to standards/provide them with a golden path, and achieve the team’s 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.

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. 

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

Home grown internal developer portals or tooling

Build your own

The first step many organizations take is to offer full or partial portal functionality to their developers. 

• This can be delivered through the use of a self-service interface, a CI tool in some cases (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. 

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 and 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 been made at some point in an organization’s software development journey, there will be a time when the engineering manager has to consider further investing 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 a cost that may be a fraction of the costs maintaining a team to evolve the original in-house portal.

Managed Backstage 

Managed Backstage offerings such as 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. 

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 Backstage, such as the rigid data model and the lack of self-service actions for day-2 operations. And while managed solutions offer more in terms of features than Backstage, they still provide less out of the box than other alternatives. Indeed, as with Backstage, Roadie will cost more in the long-run than the initial outlay, due to resources (both human and financial), paid plugins, and the product still lacks significant flexibility and functionality, meaning it will not fit an organization’s specific DNA in the long-term. 

Rigid internal developer portals 

‍Cortex

Cortex is a commercial internal developer portal that has its merits in comparison to Backstage; it suggests a lower 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 (ie. 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.
• Inability to fully customize the UI
• No support for dynamic permissions 
• Limited customization for scorecards (meaning you can’t show the ripple effects of service degradation with detailed entity dependency graphs), dashboards and homepages. 

Crucially, Cortex’s catalog does not synchronize data in real time. 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, limiting 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 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, 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. Service basic metadata is saved using YAML, which causes overhead for developers, and means that the catalog isn’t as reliable, nor is it 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, making 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. 

‍Configure8

Configure8 is a commercial internal developer portal that aims to help developers become more efficient by enabling self-service access to the information and tools they need. 

The company’s portal features a software catalog, scorecards, self-service actions, and cost management. What it touts as its ‘universal catalog’, is a very rigid software catalog that provides views in one large table of services, environments, applications and cloud resources. This isn’t the ideal format for developers to get the information they need quickly and easily. 

The self-service actions, which the company heavily focuses on, only support synchronous actions with HTTP webhook, requiring endpoint setup (which can take a lot of time). Actions can’t be triggered via an API, and there’s no TTL support or manual approvals. 

There is no integration with Kubernetes, and therefore you can’t benefit from a Kubernetes catalog, nor is there any workflow automation. There is a basic API that allows interactions with catalog entities so that users can create, update and delete. However, these are not API-first, meaning users can’t define the permissions and page configuration (or any other configuration) via the API.

Configure8 does not use TechDocs. It provides users with a basic audit log and very basic RBAC, with no ability to determine permissions by teams or properties. While the company does offer some plugins, they are limited in scope and are non-configurable. 

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.

Compare Backstage vs Port, here.