Choosing the portal for your needs:

Isolated third-party plugins are available to ingest incident data, but connecting incident data to users and workflows requires you to you to write custom code and your own custom data models, and that’s before you can begin to deliver the incident response experience to users.

Backstage’s Scaffolder is good at manually creating and displaying a high-level list of software components via GitOps. However, if you want to dynamically create  relationships among resources, people, and tools, you have to write your own custom plug-ins and code. No built-in visualization of relationships.

The UI plugin components are fixed, and any customization requires in-house code. This applies to both the back-end ETLs for the data, where you need an aggregation engine to gather insights; and then a custom front-end React plotting component for presentation.

Isolated third-party plugins are available. Ingesting security data via the plugins is straightforward, but connecting security data to resources and owners requires additional backend custom coding as well as front-end work to provide your custom DevEx.

A paid plugin, Soundcheck, is available for creating and publishing scorecards. However,  Soundcheck plugins are separate from Backstage plugins and there are far fewer of them, so you will likely need to write additional plugins in order to collect all the relevant data for your scorecards.

TechDocs plug-in is provided and if you follow a “docs like code” approach it may fit your workflow. But that’s only one source of potential documentation and one approach. If you want to centralize all docs, including API docs, you will need to do additional custom work.

Third-party plugins are available, but it’s up to you to code your custom data model for engineering metrics and manage the connections to all relevant sources of information, and then to build the appropriate front-end to display them to devs.

The default model is fixed; any customization requires in-house code. Third-party plugins are isolated, making it hard to build a software catalog from multiple sources, requiring you to build your own data lakes and ETLs processes.

Port’s catalog model is completely flexible. You can quickly add software assets and platform tools using our built-in models, but you can tweak and customize as you see fit to represent your unique structure of people, processes, and technology. You can map data from multiple sources into a real-time, up-to-date source of truth about your services.

Backstage supplies a permission framework, but by default, Backstage endpoints are not protected. It’s up to you to custom code all your own policies, or buy an RBAC solution, like Spotify’s or RedHat’s.

With Port, you can offer a personalized experience for various personas of your organization. This makes it easy to provide personalized views such as "show me my team’s services" or "my pull requests". Or to display a costs dashboard only to team leaders. Port’s dynamic permission models are based on the catalog data, including flexible users and team management. You can also import your own SSO structure from tools like Google and Okta.

The UI plugin components are fixed, and any customization requires in-house code. This applies to both the back-end ETLs for the data, where you need an aggregation engine to gather insights; and then a custom front-end React plotting component for presentation.

Custom, dynamic dashboards and widgets can be built in Port without code, ranging from tables to pie charts and trend lines. Widgets are built upon the flexible catalog model so the entire context is always present where you need it.

Backstage does not offer native scorecards. There are paid plugins available for creating scorecards, which can be set on the opinionated data mode.

Scorecards are a native offering in Port. You can define your own scorecard checks, tiers, and initiatives based on your unique software catalog model.

Backstage’s built-in scaffolder can create software components, but any workflow automation beyond that require in-house coding to build.

With Port, you can of course scaffold a software component. But maybe you want something more end-to-end. Maybe you want allow developers to create a sandbox environment with a one week time-to-live, then automatically tear down the environment at the end of the week. Port can handle all of that. Trigger any workflows via your tools, webhooks, and event-based system. Customize the payload sent based on form inputs. Utilize automation to trigger actions based on any event in the portal, and chain them to create complete workflows.

You can create forms and validations for scaffolder in YAML, but just as you would have to write in-house code for custom actions, you will have to write your own code to collect inputs for those actions.

Build custom, dynamic forms with a range of input types and multiple steps for enhanced developer experience. Leverage the custom catalog model to automatically populate form data.

One of the key values of a developer portal is being able to connect the data from your unique combination of tools you use today, and to evolve with you as things change. Backstage offers isolated, community-based, and commercial plugins that create specific UI components based on the tools you have. To unite and relate data across plugins requires building yet another plugin in-house.

Third-party plugins in Port can be leveraged by any other part of your portal: Relations, Dashboards, scorecards, actions, or RBAC. This ability to unify all your different tools, with your processes and users gives Port it’s flexibility, but also enables you to get started faster.