Backstage, Port and Cortex: Three Paths to the IDP

Updated: 2026-07-07

The term Internal Developer Platform (IDP) gained traction throughout 2023. The idea is sound: reduce developer cognitive load by giving them a unified portal to discover services, provision environments, run common workflows, and see their systems’ state. Three options dominate the conversation: Backstage^[1] (Spotify, open source), Port^[2] (commercial, low-code), and Cortex^[3] (commercial, scorecards). This article is an honest comparison with criteria to choose.

What problem an IDP solves

Developers in mid-to-large organisations spend time on tasks that shouldn’t consume it:

• Discovering: "what service does X? where is the code? who maintains it?"

• Provisioning: "how do I request a DB? how do I spin up staging?"

• Repetitive workflows: "how do I roll back? how do I scale this?"

• Basic observability: "is my service OK? are there errors?"

An IDP centralises this in a portal that is the door to the internal ecosystem. The alternative is fragmentation: stale wikis, Slack channels, tribal knowledge. See the article on platform engineering and IDPs for the wider strategic context.

Backstage: the open-source standard

Backstage was born at Spotify and open-sourced in 2020. Today it’s a CNCF project with a large community.

Strengths:

• Pure open source (Apache 2.0). No vendor lock-in.

• Extensible via plugins: catalogs, docs, cost, cloud resources, Kubernetes; dozens available.

• YAML-in-Git catalog: services are described alongside the code.

• TechDocs: docs-as-code rendered in-portal.

• Large community: meetups, conferences, companies contributing actively.

Weaknesses:

• High adoption curve: months from "npm create app" to production.

• Continuous maintenance: it’s a React app you operate yourself. Plugin updates break things.

• Customisation needs code: adding a new tab is a PR to the portal’s own codebase.

• Discovery takes work: without a well-populated entity catalog, an empty Backstage is disappointing.

Backstage suits companies with a dedicated platform team (minimum three people) and a multi-year commitment.

Port: low-code and faster

Port (Israeli, founded 2022) takes a radically different approach: commercial SaaS with visual configuration.

Strengths:

• Setup in hours, not months: the model is pre-designed; you just adapt it.

• Dynamic catalog: automatic ingestion from AWS, GitHub, Kubernetes, Terraform state, JIRA.

• Visual blueprints and self-service actions: developer self-service without code.

• Built-in scorecards: "production-ready", "observability level".

• More polished UI than Backstage out of the box.

Weaknesses:

• SaaS: your data lives outside your network, though a private-cloud option exists.

• Commercial: priced per service or per developer.

• Less extensible: if you need something highly custom, Port may not stretch that far.

• Vendor lock-in: migrating to another IDP means rebuilding from scratch.

Port suits companies that want a productive IDP quickly, without investing in a dedicated platform team.

Cortex: scorecards focus

Cortex (founded 2019) positions itself strongly in service catalog + engineering standards.

Strengths:

• Sophisticated scorecards: define levels (Bronze, Silver, Gold) and measure services against them.

• Automatic catalog from GitHub, Jira, Datadog, and others.

• Reliability workflows: on-call, postmortems, runbooks.

• Powerful queries: "show services without an owner with more than 100 errors a day".

• Engineering excellence: focus on measurably raising technical standards.

Weaknesses:

• High price: Cortex is among the most expensive in this category.

• Less self-service than Port: the focus is visibility and measurement, not provisioning.

• Dense UI: a learning curve for non-technical users.

Cortex suits companies that want to raise their technical level measurably, especially after serious incidents.

Comparison table

Decision by team size

Startup or team under 30 engineers:

A sophisticated IDP is overkill. A well-kept README, an orderly Slack channel, and Kubernetes dashboards cover 80% of the need. If you do need something, start with Port on the free or basic tier.

Mid-market (30-150 engineers):

Port is the sweet spot: productive quickly, with no need for a dedicated platform team. Cortex if the focus is raising measurable technical level, for example after a serious incident that exposed missing ownership and observability.

Enterprise (150+ engineers):

Backstage starts to justify itself through extensibility and customisation. It needs a dedicated team of three to ten people to operate and evolve it. Port or Cortex are alternatives if you prefer commercial management and a lower operational burden.

Conceptual comparison of the three IDP platforms: trade-offs of extensibility, adoption speed, and maintenance cost

The common error: portal fetish

Many teams install Backstage and are surprised developers don’t use it. The typical cause: the portal has only a static catalog, with no real self-service, no executable workflows, and no actions.

A useful IDP offers four things:

• Catalog with rich information: the name alone isn’t enough; you need dependencies, SLIs, and an on-call owner.

• Executable self-service actions: create a repo, provision a DB, roll back.

• Integrated automation: not "click here, then copy-paste somewhere else".

• In-context observability: service metrics visible directly in the portal.

Without that, it’s just a wiki dressed up as a modern portal.

Crawl, walk, run

A pragmatic approach to building an IDP from scratch:

• Phase 1: service catalog, with an owner for each service and links to repos and dashboards.

• Phase 2: docs as code (TechDocs in Backstage or an equivalent).

• Phase 3: basic self-service actions (create a service, provision an environment).

• Phase 4: scorecards and measurable engineering standards.

• Phase 5: complex workflows (blue-green, orchestrated rollbacks).

Trying everything at once is a recipe for abandoning the effort within three months. For the underlying observability layer any IDP consumes, see OpenTelemetry: unifying logs, metrics, and traces.

Lighter alternatives

If the decision is not to build a full IDP, there are valid middle grounds:

• README + GitHub Topics: curate repos as a minimum viable catalog.

• OpsLevel: similar to Cortex, more focused on maturity scoring.

• Structured wiki in Notion or Confluence: low-tech but works for teams under 50.

• Slack + bots for self-service: create a repo via /create-service in Slack.

Not everything has to be a giant React portal with a dedicated team.

Conclusion

IDPs are useful for teams that have grown past the point where "ask on Slack" works. The choice between Backstage, Port, and Cortex depends on resources, culture, and ambition: Backstage for those who can invest in platform and want full control; Port for speed and pragmatism; Cortex for measurable technical discipline. The value is in the content and the executable workflows, not the interface: installing a pretty portal without real content is the most expensive mistake a platform team can make.

Esta guía también está disponible en español: Backstage, Port y Cortex: tres caminos al IDP.

Sources

1. Backstage
2. Port
3. Cortex