Should we build on Backstage or buy Port for an internal developer portal?

Backstage is an open-source framework you build a portal from, so you own it and you staff it. Port is a commercial portal built around blueprints you define, with scorecards, self-service actions and workflow automation included. The choice is build versus buy, not feature versus feature.

Is Backstage really free?

The framework is free to download. The cost is a self-hosted instance, the plugin code you write, and the engineering time to keep both current through a release every two weeks. Most published accounts put a usable state six to twelve months out.

What are Port blueprints?

Blueprints are custom entity definitions, the centre of Port's data model. You define what a service, environment, cluster or package looks like in your organisation rather than accepting a fixed schema, and the catalog is built from those.

Do both need engineers to maintain the catalog?

Both are declaration-based, so yes. Backstage reads catalog-info.yaml from repositories and Port ingests from your existing tools into blueprints. Port's ingestion does more of the work, but neither derives the catalog purely from what production is doing.

Which is better for enforcing engineering standards?

Port, without much argument. Scorecards are a first-class rules engine in the product. Backstage can do it through plugins such as Tech Insights, which means building and maintaining that capability yourself.

Backstage vs Port | NOFire AI

At a glance

	Backstage	Port
What you are getting	An open-source framework to build a portal from	A commercial portal, configured rather than built
Data model	Fixed entity kinds, extended through plugin code	Blueprints, custom entity definitions you author
Catalog population	`catalog-info.yaml` committed to repositories	Ingested from existing tools into blueprints, plus declarations
Scorecards	Through plugins such as Tech Insights, which you maintain	First-class rules engine in the product
Self-service actions	Software templates, a core feature	Self-service actions layer, a core feature
Documentation	TechDocs, docs-as-code	Centralised technical documentation
Time to a usable portal	Six to twelve months on most published accounts	Weeks, being configuration rather than construction
Ongoing cost shape	Engineering time, including a release every two weeks	Licence, plus configuration effort
Ownership and lock-in	Total. You own the code and can never be cut off	Vendor dependency, as with any commercial platform

How the two differ in practice

This is a build-versus-buy decision wearing the costume of a product comparison, and evaluations go wrong when teams score features instead of naming that.

Backstage gives you the pieces Spotify built its portal from. What it does not give you is Spotify's platform team, and that is the whole of the difficulty. Reaching a usable instance takes a large number of setup steps and, on most published accounts, six to twelve months of TypeScript and React work. Each plugin is a separate codebase with its own frontend, backend and database schema. Releases land every two weeks without honouring semantic versioning, so patch versions can carry breaking changes and upgrade work is permanent rather than occasional.

Port starts from the assumption that you want the outcome rather than the construction project. Its data model is built on blueprints, which are custom entity definitions you author, so you describe what a service or a cluster means in your organisation without writing code to represent it. Scorecards are a rules engine over that catalog, self-service actions and workflow automation are part of the product, and the whole thing is configured rather than compiled.

The difference in what you spend is not licence versus free, it is licence versus salary. A Backstage deployment with one or two engineers attached is not cheaper than a commercial portal for most organisations, and the comparison only looks favourable when the engineering time is treated as already paid for.

Both are declaration-based underneath, which is worth knowing because it is the property that determines whether either catalog stays true. Port's ingestion from existing tools does more of the work than Backstage's YAML, but neither derives the catalog purely from what production is running.

Where each one is stronger

Port is stronger for almost every team that wants a portal and does not want to build software. The blueprint model handles unusual architectures without code, scorecards are the mature part of the product rather than a plugin somebody has to own, and the time from purchase to something engineers actually open is measured in weeks. Its customer list includes GitHub, Wiz, BT and StubHub, which is a reasonable signal that it holds up at size.

Backstage is stronger in two specific situations. The first is an environment strange enough that any commercial product would need extending past its intended limits, where owning the code is genuinely worth what it costs. The second is an organisation with a real platform engineering function that is going to build internal tooling regardless, for which Backstage is a sensible foundation rather than an additional burden.

There is also the ownership argument, and it is not nothing. Nobody can raise Backstage's price, change its licence terms, or be acquired and redirect its roadmap. Teams who have been through a vendor acquisition tend to weigh that more heavily than teams who have not.

The honest caution on Port is the one that applies to any commercial platform: you are dependent on a vendor's roadmap and pricing. The honest caution on Backstage is that the six-to-twelve-month figure is real and the teams who miss it usually assumed the demo instance was representative.

How to choose

Count the platform engineers you can actually assign, not the ones you hope to hire. If the answer is fewer than one full-time person indefinitely, Backstage will not reach a usable state and the decision is already made.

Then ask what the portal is for. If it is mainly a catalog people read, both work and Port gets there sooner. If it is mainly self-service scaffolding, both do it and the question is whether you want to write the templates or configure them. If it is mainly standards enforcement, Port's scorecards are ahead by enough that it is close to decisive.

What a service catalog is and what it is for is worth reading first if the requirement has not been written down precisely, because a portal bought for an unclear reason is the most common way this money gets wasted.

Finally, be honest about what keeps a catalog true. Both of these depend on somebody declaring things, and both drift when nobody does. If the failure you are actually trying to fix is a stale catalog rather than a missing one, what teams move to when they leave Backstage covers that separately.