Port vs. Cortex vs. Backstage: Choosing the right internal developer portal
A critical comparison of Port, Cortex, and Backstage—and why many developer portals fail to deliver on their promise.
Taylor Bruneaux
Analyst
In the past few years, the internal developer portal (IDP) has emerged as a promising solution for organizations struggling to scale engineering standards, ownership, and self-service across sprawling software ecosystems. Fueled in part by Spotify’s open source release of Backstage in 2020, the space has since exploded, bringing with it a range of offerings from SaaS startups like Port and Cortex, as well as a growing suite of plugins and enterprise layers built atop Backstage itself.
However, amid the buzz, a more complex picture is beginning to emerge. While the concept of a developer portal remains attractive, many engineering leaders are asking hard questions: Are these tools actually delivering value? Do teams use them? And what happens when the promise of standardization creates new layers of complexity?
In this guide, we’ll take a closer look at the three most prominent approaches to IDPs—Backstage, Port, and Cortex—and examine the tradeoffs of each. We’ll also highlight what most IDPs still fail to address, and options that are more likely to solve key engineering challenges.
What is an internal developer portal?
At its core, an internal developer portal is a unified interface that allows engineers to view, manage, and interact with the services they own. Ideally, it offers:
- A software catalog: a source of truth for service metadata, ownership, and dependencies
- Scorecards or standards: codified expectations for things like readiness, reliability, or migrations
- Self-service workflows: tools for spinning up new services, provisioning infrastructure, or requesting reviews
The goal is to reduce cognitive load, increase transparency, and enable teams to ship safely without bottlenecks. For many organizations, these tools have become central to maximizing productivity and visibility within engineering.
The contenders
Backstage: powerful but burdensome
Backstage is the de facto standard for IDPs, thanks to its open-source nature and active plugin ecosystem. But while it’s flexible, that flexibility comes at a cost.
Maintaining a Backstage instance requires significant engineering effort. This includes building and maintaining plugins, managing entity providers, developing scorecard logic, and creating a search experience that makes the portal easy to use on a daily basis. Many companies that start with Backstage end up needing a dedicated team just to maintain it.
Moreover, adoption is far from guaranteed. Developers may still default to Slack or rely on tribal knowledge if the portal feels incomplete or outdated. Several companies have quietly deprecated their portals after failing to drive usage.
As Spotify Backstage becomes more widely adopted, the gap between promise and reality has become more apparent.
Port: customizable but complex
Port pitches itself as a low-code IDP platform, allowing platform teams to configure software catalogs, scorecards, and self-service flows through a visual interface. It’s aimed at teams that want Backstage’s capabilities but don’t want to host and extend the platform themselves.
However, while the experience is slick, real-world deployments of Port often uncover new challenges:
- Overhead in data modeling: defining entities and relationships via YAML and JSON schemas can become a project in itself.
- Limited connectivity: while Port offers a growing list of integrations, syncing it with your organization chart, Git repositories, incident tooling, and CI/CD data can still require custom work.
- Adoption hurdles: users still need to learn a new interface and trust that the data is up to date.
Cortex: rigid and expensive
Cortex offers a more opinionated approach to developer portals, featuring out-of-the-box scorecards and catalog views that prioritize reliability and compliance. It promises faster time to value, but at the cost of flexibility.
Critics note that:
- Scorecard logic is complex to customize: Cortex relies on a proprietary config language, making it challenging to represent nuanced standards or edge cases.
- Tooling coverage is uneven: key engineering tools aren’t always supported natively.
- Costs add up quickly: licensing is per engineer, often with steep minimums.
Comparison table
Feature/Concern | Backstage | Port | Cortex | What's Missing |
|---|---|---|---|---|
Open source | ✅ Yes | ❌ No | ❌ No | |
Hosting model | Self-hosted | SaaS | SaaS | Hybrid options |
Setup effort | ⚠️ High | ⚠️ Moderate | ✅ Low | Turnkey setup with context |
Catalog customization | ✅ Flexible | ✅ Configurable | ⚠️ Limited | Linking to org charts |
Scorecard flexibility | ⚠️ Plugin-based | ⚠️ YAML/JSON schemas | ❌ Proprietary language | SQL-based definitions |
Self-service workflows | ⚠️ Plugin work | ✅ Built-in | ✅ Built-in | Native automation triggers |
Integration depth | ⚠️ Varies | ⚠️ Inconsistent | ⚠️ Spotty | Cross-tool correlation |
Developer adoption | ❌ Often low | ❌ Uncertain | ❌ Uncertain | Trusted entry point |
AI insights & productivity metrics | ❌ None | ❌ None | ❌ None | Rich context and reporting |
Cost | Free (but time-costly) | $$$ | $$$ | Reasonable ROI |
What most IDPs still get wrong
Despite their differences, Backstage, Port, and Cortex share a common set of limitations:
- They assume developer portals will be used, but in practice, developer adoption is often shallow unless the portal is integrated into existing workflows, such as Slack or Jira.
- They abstract away context: Knowing a service is “noncompliant” is only helpful if you understand why, what to do, and who owns it.
- They treat the catalog as the destination: In reality, the catalog is just a foundation. The real goal is to drive behavior change through visibility, feedback loops, and accountability.
This disconnect is reflected in many failed portal rollouts, despite well-intentioned engineering initiatives.
A new approach: DX Service Cloud
Recognizing these challenges, DX developed Service Cloud, a product suite designed to address the real problems that developer portals were intended to solve.
Rather than focusing on UI or plugin count, DX emphasizes three pillars:
Software catalogs that reflect your org
DX makes it easy to ingest service data from 40+ tools and map it to a software catalog with real-world ownership, relationships, and status. Whether you’re starting from scratch or layering on top of Backstage, DX acts as a reliable source of truth. This mirrors the emerging discipline of data platform engineering, which treats service metadata as critical infrastructure.
Scorecards with real logic
Unlike platforms that rely on YAML or black-box engines, DX utilizes SQL to define scorecards, enabling the measurement of standards in nuanced and dynamic ways. These scorecards are also connected to execution plans, Slack alerts, and team rollups.
Initiatives that drive real change
With Initiatives, scorecards become actionable. DX tracks progress, notifies owners, and integrates with issue trackers like Jira and Linear. It’s not just about reporting gaps—it’s about closing them.
The bottom line
If you’re considering an internal developer portal, it’s worth stepping back from the hype. Many tools promise a catalog and scorecards—but few deliver on adoption, actionability, or ROI.
Backstage is powerful but high-overhead. Port is polished but complex. Cortex is opinionated but inflexible. All three fall short when it comes to providing contextual, integrated, and truly developer-friendly solutions.