Backstage vs Port

Backstage is a framework, not a product. Spotify open-sourced it so every company could build their own portal. That means total flexibility — but also total ownership. You write React plugins, manage a Node.js backend, handle database migrations, and pin plugin versions that don't conflict. For a team of three platform engineers maintaining a portal for 500 developers, that overhead is real. Port inverts the model. Instead of building a UI, you define data models called Blueprints (e.g., Service, Team, Deployment) and ingest live data from your stack via an agent. The portal renders itself from the data. Actions, scorecards, and automation rules sit on top. You configure, not code. Neither approach is wrong — they optimise for different constraints.

Backstage catalogs are built from YAML descriptor files committed alongside each repo. This is intuitive but creates drift: a service gets renamed, the YAML goes stale, and the catalog lies. Keeping it accurate requires discipline (or automation) across every team. Port's catalog is ingested continuously from authoritative sources — your GitHub repos, Kubernetes clusters, PagerDuty, Datadog. The agent polls APIs and webhooks, so the portal reflects reality within minutes. No YAML to maintain, no stale entries. The tradeoff: you need to define your Blueprints carefully upfront; a poorly modelled schema is hard to restructure later.

Backstage's Scaffolder lets you define template YAML that generates repos, registers catalog entries, and runs custom actions. It's powerful, but the form UI is fixed to the template fields, and triggering complex multi-step workflows requires significant engineering. Port's Self-Service Actions can trigger any backend: GitHub Actions, GitLab CI, Jenkins, a custom webhook, or a direct API call. The input form is generated from your Blueprint schema — dynamic dropdowns, conditional fields, entity pickers. Engineers run actions from the portal; the heavy lifting happens wherever your automation already lives.

Port's scorecards let you define rules against any Blueprint property — "does this service have an on-call runbook?", "is production deployed within 24 hours of staging?", "does every team have an SLO set?" — and score every entity automatically. Platform teams get a live maturity dashboard; developers see exactly what's blocking their service from reaching the next level. Backstage has no native scorecard feature. You can replicate it with the Tech Insights plugin, but it requires custom data sources, fact retrievers, and check definitions written in code. It works, but it's a significant build effort versus Port's out-of-the-box experience.

Backstage is free to use. But staffing a platform team to maintain it is not. A conservative estimate: one engineer spending 30–40% of their time on Backstage maintenance at a $150k/yr salary is $50k–60k/yr in hidden cost, before infra, database, and ops overhead. Port's per-seat pricing is transparent. At 100 developers, the annual cost is typically $20k–40k depending on tier — often less than the engineering time Backstage consumes. At 500+ developers, the calculus shifts: Backstage's marginal cost approaches zero while Port scales per seat. Run the numbers for your org size.