Pick Port if you want a hosted portal running this month, nobody on your team has TypeScript capacity to spare, and you’re fine paying per seat for as long as you use it. Pick Backstage if you need plugins that reach deep into your own systems, want the code and data in your own cloud, and can fund part of an engineer to own it. Both work. What decides it is who maintains the portal after launch.
I’ve been doing platform work for 18+ years and we build Backstage portals for clients, so I lean toward Backstage.
What is an internal developer portal?
It is the web front door to your platform. Engineers open it to find who owns a service, read its API spec, see whether the last deploy went through, create a new service from a template, or check what a workload costs. Underneath sits a software catalog: services, APIs, teams and resources, and how they relate.
The portal isn’t the platform. The platform is the pipelines, clusters, templates and guardrails underneath, and the portal makes them visible without a Slack thread. Neither Backstage nor Port builds your pipelines. If you go with Backstage, IDP Foundations is how we start it.
What are Backstage and Port?
Backstage is, in its own documentation’s words, “an open source framework for building developer portals”. It ships a software catalog, software templates, TechDocs for docs-like-code and a plugin system. The CNCF accepted it in September 2020 and it has been an Incubating project since March 2022.
The key word is framework. You get a TypeScript codebase (React frontend, Node.js backend) that you build, configure, deploy and upgrade yourself. The getting-started guide says plainly that the local install it produces “is not a production-ready installation”. Production means a real database, authentication, integrations with your source control and cloud, and a deploy pipeline for the portal itself.
Port is a commercial SaaS portal. You model the catalog as “blueprints” in its UI, connect data sources through integrations and expose self-service actions that call your existing automation. There’s no portal code to host or upgrade. You configure it, and the trade is a recurring per-seat fee and a data model that lives in the vendor’s product.
How much does each option cost?
Port publishes its prices, which makes the arithmetic easy. The Free plan is USD 0 for up to 15 seats. Basic starts at USD 30 per seat per month billed annually, up to 50 seats. Standard starts at USD 40, up to 200 seats. Past that, Enterprise is a platform fee plus per-seat pricing on a custom quote.
So a 50-engineer team on Basic pays 50 × 30 × 12 = USD 18,000 a year at list price, and a 120-engineer team on Standard pays 120 × 40 × 12 = USD 57,600. That bill comes back every year and grows with headcount.
Backstage has no license fee, so its cost is people and hosting. The first production version is our IDP Foundations package, a fixed USD 5,000 over two weeks. Then somebody has to upgrade Backstage, keep plugins compiling and add the next integration, because a portal nobody upgrades drifts away from the plugins it depends on. At our published rates a Senior engineer is USD 45 to 50 an hour. Hosting is a Node.js service and a PostgreSQL database in your cloud, usually the smallest line.
The real comparison is a seat fee that scales with headcount against engineering time that scales with how much you customize. Backstage implementation cost breaks the Backstage side down further.
When does Port make more sense?
When most of this is true. You need a catalog and scorecards soon, and nobody wants to own a TypeScript application. Your integrations are mainstream (GitHub or GitLab, a major cloud, Kubernetes, PagerDuty), so the connectors exist. And headcount is moderate, because at a few dozen seats the fee is small next to an engineer’s salary. Check with security before the pilot that a SaaS is allowed to hold your catalog.
The free tier (15 seats, no time limit per Port’s pricing FAQ) is a cheap way to learn whether your engineers open a portal at all. Most portal projects ask that question late.
When does Backstage make more sense?
When your differentiating views are custom: a cost view that reads your billing API, a CI health page with your own flake statistics, a profiling diff between two deploys. Those are plugins you write, and Backstage is built for that.
When data residency or control matters, so the portal, its database and its credentials stay in your cloud and behind your identity provider. When you have, or will fund, an owner. Maybe a fraction of someone, but a named person who upgrades it.
And when seats dominate the bill. At a few hundred engineers, per-seat fees can exceed the cost of the engineering time to run Backstage. Do that math with your own numbers.
What did we build with Backstage on a real platform?
For a portfolio-analytics SaaS platform on AWS, we built a Backstage portal with service and API catalogs generated from OpenAPI specs, a dependency map, deploy status, FinOps cost views fed straight from the cloud billing API, image vulnerability findings, CI health with 30-day flake and retry statistics, and profiling diffs between deploys. That came to 22 modules across 10 plugins.
None of those views is exotic, and most are specific to how that team builds and ships. That’s the pattern I keep seeing: a portal earns its keep through two or three views nobody sells off the shelf. If you can’t name yours yet, you probably don’t need Backstage yet.
What about Roadie, Cortex, OpsLevel or Humanitec?
They’re real options, and the questions are the same for each: who owns the code, who owns the data, and how does the price scale. Roadie is Backstage hosted for you, so you keep the plugin model without running it. Its Teams tier lists USD 24 per developer per month for 50 to 150 developers, but it’s marked “Existing subscribers only”, so ask what a new customer gets. I haven’t priced Cortex, OpsLevel or Humanitec.
How do I decide in a week?
Run the same small test on both. Pick three questions your engineers ask every week, for example: who owns this service, is my change in production, what does this cost.
On Port, sign up for the free tier, connect source control and one cloud account, and try to answer the three. Write down what needed a workaround. On Backstage, scaffold an app locally, load your catalog from catalog-info.yaml files in three repositories, and answer the same three. Write down what needed a plugin. Then score both on time to answer, gaps, and who would own each option in month six.
If Port answers all three and nobody wants to own code, buy it. If the third question needs a custom integration and you have an owner, build Backstage. If you’re still unsure, I’d go with Backstage and a narrow first scope, because the catalog file format is portable and the code is yours either way.
IDP Foundations is the quick way to run the Backstage half: USD 5,000, two weeks, a production portal with your own catalog before you commit to anything longer. The platform engineering service has the scope, and every package and hourly rate is on the pricing page.
Sources, accessed 2026-10-07: Backstage docs, Backstage, Getting Started, CNCF, Backstage, Port pricing, Roadie pricing.
Port, Roadie, Cortex, OpsLevel and Humanitec are trademarks of their respective owners. Clouditive is not affiliated with them.