Skip to main content

Harness IDP vs Self Managed Backstage - In-depth Feature Comparison

The following tables compare feature availability between Harness IDP and Self-Managed Backstage for various features like Software Catalog, Workflows, Plugins, Scorecards, Governance and Platform.

Software CatalogSelf Managed BackstageHarness IDPNotes
Entity definition as CodeYesYes
Favorites/bookmark entitiesYesYes
Catalog Dependency graphYesYes
Custom Entity TypesYesYesDocs
Custom Entity KindsLimitedNoBackstage does not recommend creating custom entity Kinds, since the existing Kinds are sufficient for major use-cases.
Custom Catalog ProcessorsYesAlternativeSee Catalog Ingestion API
Custom Entity ProvidersYesNo
Automated Service DiscoveryNoRoadmap
WorkflowsSelf Managed BackstageHarness IDPNotes
Config-driven UI for each workflow/templateYesYes
API response based custom dropdown pickersYesRoadmap
UI based pipeline orchestratorNoYes
UI based input form editorYesYes
Write custom action/stepLimitedYesPossible via custom steps in Harness Pipelines
Isolation of infrastructure for executionsNoYesBackstage Scaffolder tasks execute on the same infrastructure as the Backstage app. Any changes to the Backstage app infrastructure can kill existing scaffolder runs.
Granular access control of workflowsNoYesRequires Permission policy to be written via code.
Native integration with Jira/Slack/ServiceNow/etc.NoYes
Integration with other orchestrators (GitHub Actions, Azure DevOps, Jenkins, etc.)NoLimited
Long running processes as part of the stepNoYes
Support for human interaction during executionNoYes
Define failure Strategy or Conditional executionsLimitedYes
Scheduled executionNoYes
Custom UI field extensionsLimitedNo
PluginsSelf Managed BackstageHarness IDP
Install and configure pluginsYesYes
Customize Catalog layout using pluginsYesYes
Write custom frontend pluginsYesYes
Write custom backend pluginsYesNo
ScorecardsSelf Managed BackstageHarness IDPNotes
Service ScorecardsLimitedYes
Custom checksNoYes
Parsing support for file-content based checksNoYes
Custom Data SourceNoYesSee Catalog Ingestion API
Governance and SecuritySelf Managed BackstageHarness IDP
Approval gates via Jira/ServiceNow/etc. for workflowsNoYes
Role Based Access ControlNoYes
Open Policy Agent based PoliciesNoYes
Audit TrailsNoYes
Integration with Secret Managers (AWS, GCP, Vault, etc.)NoYes
PlatformSelf Managed BackstageHarness IDP
User and Group Management UINoYes
Ingestion of Users, User Groups and Roles from different sources (LDAP, AD, SCIM, etc.)LimitedYes
Single Sign-OnLimitedYes
Custom Dashboards for Key Adoption InsightsNoYes
Scheduled executive reportsNoYes
Alerting based on metrics trendsNoYes
Project and Org based hierarchy of entitiesNoLimited
MiscellaneousSelf Managed BackstageHarness IDP
Customize UI theme colorsYesRoadmap
AI assisted onboarding and workflowsNoRoadmap

How does Harness IDP compare against Self managed Backstage in terms of extensibility and flexibility?

In Harness IDP we offer the support for custom plugins wherein you could build your own backstage frontend plugins and upload the package in IDP or provide the link to their published package on npm registry.

We support the code customers write and build and deploy it to the IDP on their behalf. This solves most of the use cases customers have that could be supported by extensibility. We are yet to receive the support for dynamic frontend plugins on Backstage, which is just on the proposal phase also it would be supported along with the new backend and frontend system, most plugins we see in the Backstage Plugins marketplace are built out of legacy backend system because that's what most adopters of Backstage are running. Today we support almost all the plugins from marketplace required by our customers and are open for customers request to enable any plugin, usually within one week, that's already on backstage marketplace but isn't available in Harness IDP.

Harness IDP doesn't yet support custom entity provider and custom catalog processors but even on Backstage world these are complex code-level customizations which require good knowledge of typescript to implement.

A direct implementation of the custom entity providers and processors would require us to run customer's code on our backend which poses serious security risks. Hence we have worked on providing workarounds to solve the customer use cases that would otherwise require building out custom providers and processor on self managed backstage, for example the custom catalog processors are used to update the entity definitions on the fly (not YAML based), which is done using our Ingestion API in Harness IDP