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 Catalog | Self Managed Backstage | Harness IDP | Notes |
---|
Entity definition as Code | Yes | Yes | |
Favorites/bookmark entities | Yes | Yes | |
Catalog Dependency graph | Yes | Yes | |
Custom Entity Types | Yes | Yes | Docs |
Custom Entity Kinds | Limited | No | Backstage does not recommend creating custom entity Kinds, since the existing Kinds are sufficient for major use-cases. |
Custom Catalog Processors | Yes | Alternative | See Catalog Ingestion API |
Custom Entity Providers | Yes | No | |
Automated Service Discovery | No | Roadmap | |
Workflows | Self Managed Backstage | Harness IDP | Notes |
---|
Config-driven UI for each workflow/template | Yes | Yes | |
API response based custom dropdown pickers | Yes | Roadmap | |
UI based pipeline orchestrator | No | Yes | |
UI based input form editor | Yes | Yes | |
Write custom action/step | Limited | Yes | Possible via custom steps in Harness Pipelines |
Isolation of infrastructure for executions | No | Yes | Backstage 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 workflows | No | Yes | Requires Permission policy to be written via code. |
Native integration with Jira/Slack/ServiceNow/etc. | No | Yes | |
Integration with other orchestrators (GitHub Actions, Azure DevOps, Jenkins, etc.) | No | Limited | |
Long running processes as part of the step | No | Yes | |
Support for human interaction during execution | No | Yes | |
Define failure Strategy or Conditional executions | Limited | Yes | |
Scheduled execution | No | Yes | |
Custom UI field extensions | Limited | No | |
Plugins | Self Managed Backstage | Harness IDP |
---|
Install and configure plugins | Yes | Yes |
Customize Catalog layout using plugins | Yes | Yes |
Write custom frontend plugins | Yes | Yes |
Write custom backend plugins | Yes | No |
Scorecards | Self Managed Backstage | Harness IDP | Notes |
---|
Service Scorecards | Limited | Yes | |
Custom checks | No | Yes | |
Parsing support for file-content based checks | No | Yes | |
Custom Data Source | No | Yes | See Catalog Ingestion API |
Governance and Security | Self Managed Backstage | Harness IDP |
---|
Approval gates via Jira/ServiceNow/etc. for workflows | No | Yes |
Role Based Access Control | No | Yes |
Open Policy Agent based Policies | No | Yes |
Audit Trails | No | Yes |
Integration with Secret Managers (AWS, GCP, Vault, etc.) | No | Yes |
Platform | Self Managed Backstage | Harness IDP |
---|
User and Group Management UI | No | Yes |
Ingestion of Users, User Groups and Roles from different sources (LDAP, AD, SCIM, etc.) | Limited | Yes |
Single Sign-On | Limited | Yes |
Custom Dashboards for Key Adoption Insights | No | Yes |
Scheduled executive reports | No | Yes |
Alerting based on metrics trends | No | Yes |
Project and Org based hierarchy of entities | No | Limited |
Miscellaneous | Self Managed Backstage | Harness IDP |
---|
Customize UI theme colors | Yes | Roadmap |
AI assisted onboarding and workflows | No | Roadmap |
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