Post

Developer Portals: Backstage, Port and Cortex

Backstage, Port and Cortex lead the internal developer portal market, but they are three different products: a framework you build, a data platform you model, and a standards engine you adopt. How they compare layer by layer, what they cost, and how to choose.

Posted Updated
By
13 min read
Developer Portals: Backstage, Port and Cortex

Backstage, Port and Cortex are usually compared as if they were three versions of the same product. They are not. Backstage is a framework you build a portal with. Port is a data platform you model your engineering world in. Cortex is a standards engine you adopt to raise service quality. Pick the one whose shape matches the problem you actually have, then check the feature list.

TL;DR

If your main problem is… Start with Why
“We need a portal that fits our org exactly, and we have engineers to build it” Backstage Unlimited extensibility, OSS, no licence cost, CNCF-governed
“We need self-service actions and a catalog that models our entities, live this quarter” Port Flexible data model (Blueprints) and workflows without writing a portal
“We know what good looks like; we need every service to get there and leadership to see progress” Cortex Scorecards, initiatives and engineering metrics are the core product

Most enterprises end up needing all three capabilities: a catalog, self-service, and standards. The choice is which one you want to be strongest and which you accept as “good enough”.

The Market in 2026

The portal is layer 1 of the six-layer IDP stack: the front door to everything below it. “Top 10 IDP” lists mix portals with orchestrators (Humanitec), PaaS products and CI tools. Restricting to portals and to signals that are not vendor marketing, three products lead:

Signal Backstage Port Cortex
Governance CNCF project, Incubating since March 2022 Commercial SaaS (Israel/US) Commercial SaaS (US)
Adoption signal 3,400+ adopting organisations, 2M+ developers (Spotify, 2025) $100M Series C at $800M valuation (Dec 2025) Gartner Market Guide for IDPs, representative vendor (2025)
Analyst signal Thoughtworks Radar: Adopt (earlier volumes) Thoughtworks Radar: Trial (Apr 2026) Gartner representative vendor two years running
Positioning (vendor’s words) “An open framework for building developer portals” “Agentic engineering platform” “Engineering operations / excellence platform”
Hosted options Self-host, Spotify Portal (SaaS), Roadie, Harness IDP SaaS only SaaS (self-managed option for enterprise)

Worth knowing about, but outside this comparison: Roadie and Spotify Portal (hosted Backstage — treat as “Backstage without the ops”), Harness IDP (Backstage-based, bundled with Harness CI/CD), OpsLevel (catalog + maturity rubrics, close to Cortex), Mia-Platform and Atlassian Compass.

Where each product sits

Every portal trades flexibility against time to value. The leaders sit in different corners:

quadrantChart
    title Developer portals: flexibility vs time to value
    x-axis "Slow to value" --> "Fast to value"
    y-axis "Opinionated" --> "Flexible"
    quadrant-1 "Configure your own model"
    quadrant-2 "Build your own portal"
    quadrant-3 "Avoid"
    quadrant-4 "Adopt the vendor's model"
    "Backstage (self-hosted)": [0.12, 0.92]
    "Hosted Backstage (Spotify Portal, Roadie)": [0.42, 0.72]
    "Port": [0.72, 0.78]
    "Cortex": [0.8, 0.32]
    "OpsLevel": [0.7, 0.22]

Read it with the job you need done. A portal has five jobs — catalog, self-service, standards, insight and docs/search. Backstage is strongest on catalog and docs; Port on self-service and insight over a custom model; Cortex on standards and insight.

Capability Comparison

Ratings reflect the product as shipped in late 2026, without custom engineering. ●●● strong out of the box, ●● capable, ● possible with significant work.

Capability Backstage Port Cortex
Catalog data model ●● Fixed entity kinds (Component, API, System…), extensible with custom kinds in code ●●● Fully custom “Blueprints” and relations, defined in the UI or API ●● Service-centric; custom entity types supported
Catalog ingestion ●● catalog-info.yaml in repos + entity providers ●●● 100+ integrations push live data into the model ●●● Integrations + AI-assisted ownership inference
Scaffolding / templates ●●● Scaffolder: the reference implementation ●● Self-service actions call your CI, Terraform, or webhooks ●● Workflows can scaffold services
Day-2 self-service ● Custom Scaffolder actions or plugins ●●● Actions + node-based Workflows (open beta, 2026) with approvals ●● Workflows (GA Oct 2024) with approvals and RBAC
Scorecards / maturity ● Tech Insights plugin, or Soundcheck (paid, Spotify) ●● Scorecards on any Blueprint ●●● Core product: levels, initiatives, deadlines, exemptions
Engineering metrics ● Build or buy plugins ●● Dashboards on any catalog data, DORA templates ●●● Engineering Intelligence: DORA, velocity, trends
Docs (docs-as-code) ●●● TechDocs (MkDocs) ● Links and embeds ● Links and embeds
UI customisation ●●● Anything you can write in React ●● Configurable pages and widgets ● Opinionated UI
AI / agent access ●● Actions Registry exposed via MCP (experimental) ●●● MCP server, built-in agents, “context lake” ●● MCP server (Jul 2025)
Governance (RBAC, audit) ●● Permission framework; you write policies ●●● Fine-grained RBAC applied to humans and agents ●●● RBAC on workflows and scorecards
Time to first value Months Weeks Weeks
Lock-in None (OSS) High (proprietary model) High (proprietary model)

Two things this table hides:

  1. Backstage’s ratings are a floor, not a ceiling. Every ● can become ●●● with engineering time. With Port and Cortex you get what the vendor ships, quickly.
  2. Port’s flexibility is also its risk. A fully custom data model means you must design one. Teams that skip that step recreate their CMDB’s mess in a nicer UI.

Three Mental Models

Backstage: a framework you build

Backstage is a TypeScript/React + Node.js monorepo you fork, extend and operate. It ships with five core features — Software Catalog, Scaffolder, TechDocs, Search and a plugin system — and everything else is a plugin.

flowchart LR
    Dev["Developer"] --> FE["Frontend<br/>React app of plugins"]
    FE --> BE["Backend<br/>Node.js plugins"]
    BE --> DB[("PostgreSQL")]
    BE --> CAT["Catalog"]
    BE --> SC["Scaffolder"]
    BE --> TD["TechDocs"]
    BE --> AR["Actions Registry"]
    AR --> MCP["MCP server<br/>for AI agents"]
    CAT --> EP["Entity providers<br/>GitHub, GitLab, cloud, custom"]

What changed in 2025–2026:

  • The New Frontend System became the default for new apps in v1.49 (March 2026) and is the release candidate for 1.0. Existing apps need a migration.
  • The Actions Registry (v1.40) lets plugins publish actions that an MCP server exposes as tools to coding agents. Still marked experimental.
  • Spotify Portal is now generally available: a hosted, no-code Backstage from Spotify, with paid plugins such as Soundcheck (scorecards) and Insights.

The catalog is the product. Every entity is declared in a catalog-info.yaml next to its code. Ownership, lifecycle, system and dependencies in those files are what make blast-radius analysis, change notifications and permissions possible. Stale catalog data silently breaks every feature built on it.

graph LR
    Domain --> System
    System --> Component
    System --> Resource
    Component -->|providesApi| API
    Group -->|owns| Component
    User -->|memberOf| Group

The real cost is people. Running Backstage well takes a small team (commonly 2–4 engineers for a mid-size org) for upgrades (monthly releases), plugin work, auth, catalog-quality campaigns and support. Organisations that do not staff it stall in what the community calls “perpetual rollout”.

Port: a data platform you model

Port starts from an empty data model. You define Blueprints (Service, Environment, Cluster, Team, Feature flag, Cloud account, anything) and their relations, then integrations fill them with live data. Self-service actions, scorecards and dashboards are all built on top of that model.

flowchart LR
    SRC["Sources<br/>GitHub, K8s, cloud,<br/>PagerDuty, Jira..."] --> CL["Context lake<br/>Blueprints + entities<br/>+ relations"]
    CL --> SS["Self-service actions<br/>and Workflows"]
    CL --> SCR["Scorecards"]
    CL --> DSH["Dashboards"]
    CL --> AG["AI agents<br/>and MCP server"]
    SS --> EXE["Your executors<br/>GitHub Actions, Terraform,<br/>webhooks"]

Strengths: fast time to value; the data model fits your organisation rather than Spotify’s; self-service actions call your existing automation instead of replacing it; RBAC applies identically to people and AI agents, which matters as agents start triggering platform actions. Port has repositioned hardest around agents: an MCP server (2025), agents that act on catalog context, and Workflows in open beta (2026). It also offers a free tier (15 seats).

Weaknesses: a blank data model needs a designer; proprietary lock-in, since Blueprints and actions do not port anywhere; docs-as-code is weak compared with TechDocs; per-seat pricing grows with the organisation.

Cortex: a standards engine you adopt

Cortex is opinionated about what good looks like and built to move a whole estate toward it. The catalog exists to feed Scorecards — rules such as “has an on-call rotation”, “no critical CVEs older than 30 days”, “runs on the current base image” — grouped into levels (Bronze, Silver, Gold) and pushed through time-boxed Initiatives with owners and deadlines.

flowchart LR
    INT["Integrations<br/>SCM, CI, on-call,<br/>security, APM"] --> CAT["Catalog<br/>auto-detected owners"]
    CAT --> SCR["Scorecards<br/>rules + levels"]
    SCR --> INI["Initiatives<br/>deadline, owners"]
    INI --> NOT["Nudges in Slack,<br/>IDE via MCP"]
    CAT --> EI["Engineering<br/>Intelligence<br/>DORA, velocity"]
    SCR --> EI

Strengths: the fastest route to production-readiness and compliance programmes; leadership reporting comes built in; Workflows (GA Oct 2024) cover common self-service; MCP server (Jul 2025) puts ownership and scorecard context in the IDE.

Weaknesses: least flexible UI and data model of the three; scaffolding and self-service are capable but not the centre of the product; proprietary lock-in; typically the highest per-seat price.

One Job, Three Implementations

“Every production service must have an owner, an on-call rotation and no critical vulnerabilities, and new services must start compliant.”

Step Backstage Port Cortex
Model the rule Tech Insights fact retrievers + checks (code), or Soundcheck Scorecard on the Service blueprint (UI/JSON) Scorecard with three rules and levels (UI)
Pull the data Entity providers + plugin backends for PagerDuty and Snyk Built-in PagerDuty and Snyk integrations Built-in PagerDuty and Snyk integrations
Drive the fix Custom notifications; dashboards you build Automations open Jira tickets or Slack messages Initiative with deadline, auto-reminders to owners
New services start compliant Scaffolder template wires owner + on-call Self-service action calls a template repo + registers entity Workflow scaffolds and registers the service
Report to leadership Build a page Dashboard widget Built-in initiative and scorecard reports
Effort Weeks of engineering Days of configuration Hours to days

The pattern is consistent: Backstage gives you the most control at the highest build cost; Cortex gives you the least control at the lowest; Port sits between.

Cost of Ownership

List prices are not published; all three are negotiated. The numbers below are ranges from 2025–2026 public comparisons for ~200 developers and should be treated as order-of-magnitude.

Cost line Backstage (self-hosted) Port Cortex
Licence $0 ~$20–80 per developer/month (reported range) ~$35–70 per developer/month (reported range)
Platform engineering 2–4 FTE ongoing ~0.5–1 FTE to model and maintain ~0.5 FTE
Infrastructure Postgres, K8s, object storage, search Included Included
Year-1 total (indicative) Highest (people-dominated) Medium Medium–high
Exit cost Low High High

The trap is comparing Backstage’s $0 licence against a vendor quote. The fair comparison is vendor licence vs fully loaded platform-engineer salaries, plus the opportunity cost of what those engineers would otherwise build. In Europe, 3 FTE of platform engineers cost more than most portal licences for a 200–500 developer organisation.

How to Choose

flowchart TD
    A{"Can you staff 2-4 engineers<br/>to own the portal as a product?"} -->|Yes| B{"Need deep customisation,<br/>docs-as-code, or zero lock-in?"}
    A -->|No| C{"What is the burning problem?"}
    B -->|Yes| BS["Backstage<br/>self-hosted"]
    B -->|No| HB["Hosted Backstage<br/>Spotify Portal / Roadie"]
    C -->|"Self-service and a catalog<br/>shaped like our org"| PT["Port"]
    C -->|"Raising standards across<br/>hundreds of services"| CX["Cortex"]
    C -->|"Both, equally"| POC["Run a time-boxed<br/>Port vs Cortex bake-off"]

Running a bake-off

If the shortlist is Port vs Cortex (with Backstage as the build option), run a six-week evaluation against your data, not vendor demos:

  1. Pick three real jobs — for example, one production-readiness scorecard, one day-2 self-service action (e.g. “provision a database”), and one leadership report.
  2. Connect real sources for one domain: SCM, CI, Kubernetes, on-call, security scanner.
  3. Score each tool on weighted criteria:
Criterion Weight What to measure
Time to the three jobs working 25% Calendar days, people involved
Fit of the data model 20% Can it model your entities (e.g. markets, stores, domains) without workarounds?
Self-service and governance 20% Approvals, RBAC, audit trail, agent access under the same rules
Standards and reporting 15% Can a director see readiness by domain without exporting to a spreadsheet?
Developer experience 10% Survey 10–20 pilot developers after two weeks
Cost and exit 10% 3-year TCO; how much is lost if you leave
  1. Decide on evidence, including an explicit “build on Backstage” baseline so the comparison is not only vendor vs vendor.

Adoption: The Same Curve for Every Tool

The tool choice matters less than the rollout order. The failure mode is identical across all three products: launching a feature-rich portal on top of an empty or stale catalog.

flowchart LR
    P1["1. Catalog<br/>every service has an owner,<br/>lifecycle, system"] --> P2["2. Golden paths<br/>new services start<br/>registered and compliant"]
    P2 --> P3["3. Standards<br/>scorecards on the<br/>existing estate"]
    P3 --> P4["4. Day-2 self-service<br/>and agent access"]
  • Phase 1 is the hardest. Ownership data for the existing estate takes a campaign: automation, PR templates, and a named owner for catalog completeness.
  • Phase 2 pays for Phase 1. Templates keep the catalog correct for every new service. See Golden Paths and Paved Roads.
  • Phase 3 is where Cortex is strongest, Phase 4 where Port is, and the whole curve is where Backstage rewards investment.

Anti-Patterns

Tool choice as strategy. Picking a portal before agreeing on the three problems it must solve. The result is a demo, not a product.

Vanity portal. Live with 40 entities and 5% weekly active developers, and the platform team reports success because it was deployed.

Stale catalog. Manual registration, no providers or integrations. A catalog where 30% of owners are wrong is worse than none: it misleads incident responders.

Custom data model without a designer. Especially in Port: twenty Blueprints that mirror every tool’s schema, with no agreed definition of “service”.

Scorecards as surveillance. Especially in Cortex: dozens of rules, no initiatives, no help to fix. Teams learn to ignore the colour.

Plugin sprawl. Especially in Backstage: 40 plugins at launch, each an upgrade liability. Start with 3–5 that remove daily pain.

Agents with more access than people. Exposing portal actions over MCP without the same RBAC, approvals and audit as the UI.

How Organisations Use Them

  • Spotify (Backstage). Built internally from ~2016 for ~2,000 microservices where “who owns this?” had no fast answer; open-sourced in March 2020. Spotify reports near-universal internal adoption and a 55% drop in onboarding time.
  • Expedia Group (Backstage). Roughly 5,000 developers and 20,000 services, catalog filled by GitHub discovery rather than manual registration (Roadie case study).
  • American Airlines (Backstage). “Runway” portal: golden-path templates get a new app to public ingress in minutes.
  • Port and Cortex. Both publish customer stories, mostly mid-to-large SaaS and fintech companies. Treat them as vendor marketing and ask for reference calls with organisations of your size and regulatory profile.

References

Software Architecture, Platform Engineering
system-design
This post is licensed under CC BY 4.0 by the author.