Here’s a practical way to choose.

Short answer

If you want internal service discovery + self-service developer portal, the main options split like this:

• Backstage: best if you want the most flexible, open-source, ecosystem-heavy platform and can invest in setup/maintenance.
• Port: best if you want a faster-to-adopt, more opinionated internal developer portal with a polished product experience.
• Cortex: best if your top priority is engineering standards, service ownership, scorecards, and operational maturity.
• Something else: if you mostly need service catalog + docs + ownership, you may not need a full portal yet; a lighter stack may be better.

How to think about the problem

“Internal service discovery and self-service” usually means a mix of:

1. Service catalog

   • What services exist?
   • Who owns them?
   • What environments, repos, dashboards, runbooks, dependencies, and APIs are related?

2. Self-service actions

   • Create a service
   • Provision infra
   • Create secrets, DBs, queues
   • Deploy or promote versions
   • Request access
   • Spin up preview environments

3. Developer experience

   • Searchable portal
   • Templates
   • Golden paths
   • Docs and workflows in one place

4. Governance

   • Standards
   • Scorecards
   • Service health
   • Ownership completeness
   • Compliance/security signals

Different products lean differently across those.

---

Option-by-option

1) Backstage

Best for

• Organizations that want a platform they can heavily customize
• Teams already comfortable with engineering and want open-source control
• Companies that need a broad plugin ecosystem
• Those who want to build the portal as an internal product

Strengths

• Very flexible
• Open source, strong community
• Large plugin ecosystem
• Good for catalog + docs + templates + software templates/workflows
• Can unify many internal tools under one portal

Tradeoffs

• Higher implementation effort
• You own more of the UX, integrations, and maintenance
• Can become a “platform project” requiring ongoing engineering
• Self-service often needs extra work/integration

When it’s a great fit

• You have platform engineering resources
• You want deep customization
• You’re okay building and maintaining integrations
• You want to avoid vendor lock-in

---

2) Port

Best for

• Teams that want a modern internal developer portal quickly
• Companies that want a more opinionated, productized experience
• People who want a strong portal for assets, ownership, actions, and scorecards without as much DIY

Strengths

• Faster time to value
• Good UX
• Built around service catalog + self-service + blueprints
• Typically easier to operationalize than a fully custom Backstage deployment
• Good for mapping internal resources and automating actions

Tradeoffs

• Less open/extensible than Backstage in some areas
• You’re buying into the product model
• Integration breadth may depend on roadmap/vendor support
• Can be costlier at scale

When it’s a great fit

• You want value now, not a long platform build
• You have clear portal requirements
• You want self-service plus governance in a managed product

---

3) Cortex

Best for

• Organizations that care a lot about service ownership, standards, scorecards, and engineering intelligence
• Teams focused on maturity, quality signals, and accountability
• Leaders who want visibility into service health and engineering practices

Strengths

• Strong emphasis on service catalog and scoring
• Great for ownership, metadata, maturity metrics
• Useful for standardization and operational rigor
• Good for platform/engineering leadership visibility

Tradeoffs

• Less of a “build anything” developer portal than Backstage
• More focused on governance and service health than broad portal customization
• Self-service workflows may not be as broad depending on your needs
• Can feel more like an engineering management platform than a full portal

When it’s a great fit

• You want to enforce and measure standards
• You want service scorecards and portfolio visibility
• You need strong service ownership and operational hygiene

---

A simple decision framework

Choose Backstage if:

• You want maximum flexibility
• You have platform engineers to own it
• You want to integrate many systems
• You want OSS and control
• You expect to customize workflows heavily

Choose Port if:

• You want a faster rollout
• You want a polished portal product
• You need self-service, catalog, and governance without building everything
• You want a more “ready-made” experience

Choose Cortex if:

• You care most about catalog quality, ownership, and engineering standards
• You want scorecards and service health visibility
• You want to drive operational maturity across teams

Choose “something else” if:

• You mainly need:
  • docs + service catalog, or
  • workflow automation, or
  • cloud resource provisioning, without needing a full portal platform
• In that case, a lighter stack may be better:
  • Backstage-lite (catalog/docs only)
  • Homegrown catalog + workflow tools
  • A doc platform + automation layer
  • ServiceNow/Jira + internal tooling
  • Pulumi/Terraform + templates + chatops

---

Common real-world patterns

Pattern A: “We need a portal, but don’t want to build one”

• Port
• Best for faster adoption and less engineering overhead

Pattern B: “We want an internal platform product”

• Backstage
• Best if you want to own the developer experience long-term

Pattern C: “We need standards and visibility first”

• Cortex
• Best if the biggest pain is inconsistent ownership, poor metadata, and lack of accountability

Pattern D: “We only need service discovery right now”

• Use a lighter catalog/documentation approach first
• Don’t overbuy a portal if self-service is not yet mature

---

Questions to ask internally

If you answer these, the choice becomes much clearer:

1. Do we want to build/own the portal or buy it?
2. How much customization do we need?
3. Do we need self-service workflows now, or just catalog/discovery?
4. Do we have platform engineers to maintain integrations?
5. Is our priority developer UX or engineering governance?
6. How many systems need to be integrated?
7. Do we need scorecards and service maturity metrics?
8. How fast do we need to launch?

---

Quick recommendation by org type

Small-to-mid org with limited platform engineering

• Port is often the quickest win
• Or a lightweight solution if the need is modest

Mid-to-large org with strong platform team

• Backstage if you want control and extensibility
• Cortex if governance/scorecards are a major goal

Org focused on service quality, ownership, and standards

• Cortex first
• Add portal capabilities later if needed

Org wanting a broad developer portal and workflow hub

• Backstage or Port
• Backstage for flexibility, Port for speed

---

My practical guidance

If you’re undecided, here’s the most useful rule of thumb:

• Backstage = best platform foundation, most effort
• Port = best speed-to-value for portal/self-service
• Cortex = best for governance and service maturity

If your core goal is “help developers find services and do common tasks themselves”, I’d usually lean:

• Port if you want quicker rollout and a productized solution
• Backstage if you want long-term ownership and customization

If your core goal is “make ownership and service standards visible and measurable”, I’d lean:

• Cortex

---

If you want, I can help you choose more concretely

If you tell me:

• your org size,
• how many services/teams you have,
• whether you have platform engineers,
• what self-service actions you want,
• and your tolerance for building vs buying,

I can give you a specific recommendation and even a rough architecture for the portal.