These three products get compared as though they solve the same problem, and they do not. One is a framework for building a portal, one is a portal you configure, and one is an orchestrator that mostly does not care about portals. Picking between them starts with working out which of those three things you are actually missing — which is why most of this article is not about the tools.
Start here: which layer is your gap?
An internal developer platform has three separable layers. There is a catalogue, which answers 'what exists, who owns it, and is it healthy'. There are self-service actions, which answer 'create me a service, an environment, a database, without a ticket'. And there is orchestration, which answers 'turn this developer's intent into correct, environment-specific configuration every time'.
Teams reach for a portal when they feel the pain of the first layer, but the pain that actually blocks delivery is usually the third. A portal in front of manual provisioning is a nicer-looking ticket queue. Work out which layer is missing before you shortlist anything, because these three products are strongest at different ones.
Backstage: a framework, not a product
Backstage is an open-source framework for building your own portal. That is the whole point and the whole cost. Anything you can imagine, you can build, and the plugin ecosystem is by far the largest of the three. If your requirements are unusual, or you have compliance reasons to self-host everything, nothing else offers the same ceiling.
The cost is real and consistently understated. Backstage is a TypeScript application that your team owns: you upgrade it, you resolve plugin incompatibilities, you keep the catalogue's data fresh, you run it. Adoption inside your company is a product problem you now also own. The teams we see succeed with it have at least one engineer on it more or less permanently, and treat it as an internal product with a roadmap.
Commercial distributions exist precisely because of that maintenance load, and they change the calculation considerably. If Backstage appeals but a permanent maintainer does not, price a supported distribution before deciding the framework is too expensive.
- Choose it when: requirements are genuinely unusual, self-hosting is non-negotiable, or you have platform engineering capacity to spare and want no ceiling.
- Avoid it when: nobody can name the person who will own it in twelve months. This is the single best predictor of a dead Backstage instance.
Port: a portal you configure
Port takes the opposite position. The catalogue is a configurable data model rather than a codebase, ingestion from your existing tools is set up rather than built, and self-service actions are wired to whatever automation you already have. Time to something genuinely useful is measured in weeks rather than quarters, and it does not consume a permanent engineer.
You trade the ceiling for that. When you want behaviour the product does not model, you are negotiating with a roadmap rather than writing a plugin. It is software-as-a-service, so data residency and self-hosting questions need answering early if you are in a regulated environment. And the pricing is per-developer, which means the cost scales with exactly the thing you hope will grow.
- Choose it when: the gap is visibility and self-service, you want value this quarter, and you would rather spend platform capacity on the automation behind the actions than on the portal itself.
- Avoid it when: self-hosting is mandatory, or your requirements are strange enough that you will spend the year fighting the data model.
Humanitec: orchestration first
Humanitec is solving the third layer. Rather than presenting a catalogue, it takes a workload description and generates the environment-specific configuration for it, so that the difference between staging and production is computed from rules you set once rather than maintained by hand across dozens of manifests. If your actual pain is configuration drift and per-environment YAML sprawl, this is the one aimed at your problem.
It is also the one that demands the most conceptual commitment. You are adopting a model for how configuration is produced, which means rethinking how your teams describe workloads. On a mature Kubernetes estate with many services and several environments, that pays back quickly. On a handful of services, it is a large idea for a small problem, and you will spend more time learning the model than you save.
- Choose it when: you have many services across many environments, drift is a recurring incident cause, and Kubernetes is already your substrate.
- Avoid it when: you have fewer than roughly twenty services, or your estate is mostly platform-as-a-service rather than Kubernetes.
The costs that do not appear in a comparison table
- Catalogue maintenance. Every one of these is only as useful as its data. A catalogue that is 60% accurate is worse than no catalogue, because people stop trusting it and go back to asking in Slack.
- The automation behind the buttons. None of these three provisions anything on its own. 'Create environment' still needs the Terraform, the pipeline and the guardrails underneath it. That work is the platform; the portal is the doorway.
- Adoption. Developers use whichever path is easiest. If the golden path is slower than the shortcut, no product on this list will save you, and mandating it will only teach people to route around you.
- Exit cost. Ask what leaving looks like before you enter. For Backstage it is a codebase you already own; for the commercial options it is a data model and a set of integrations to rebuild.
How we would actually decide
- 01Write down the three or four developer journeys that hurt most today, with current lead times. If you cannot, the problem is not tooling.
- 02Ask whether the pain is knowing what exists, waiting for provisioning, or configuration drift. That maps directly to catalogue, self-service and orchestration.
- 03Build the automation for one journey first, with no portal at all. If self-service environment creation works from a pipeline, you have a platform; adding a front door is then a small, well-informed decision.
- 04Name the owner for the next twelve months. Their available capacity, more than any feature comparison, determines whether Backstage or a managed option is right.
- 05Only then shortlist. By this point the choice is usually obvious, and occasionally the answer is that you do not need any of them yet.
The uncomfortable conclusion
Most teams asking this question are one or two quarters early. The version of this decision that goes well is made after the golden path exists and the automation works, when the portal is a way to expose something that already delivers value. The version that goes badly is made first, in the hope that the tool will create the platform.
We have no preference between these three and no reselling relationship with any of them. Every one of them is a good product being asked to do the wrong job somewhere right now.
Pick the layer, build one journey end to end, then choose the tool that exposes it. If you want an outside read on which layer is actually costing you delivery speed, that is one of the four things the free platform audit measures, and you keep the findings whichever way you go.