The “IDP” acronym is overloaded. It means both:
- Internal developer platform — the underlying capability stack (Kubernetes, IaC, observability, golden paths).
- Internal developer portal — the UI/catalog layer (Backstage, Port, custom).
Most discussions confuse these. The actual question — “do we need Backstage?” — has different answers depending on which IDP you’re talking about.
Platform vs portal
A platform without a portal still works. A portal without a platform is wallpaper.
Platform answers: “What capabilities can product teams self-serve?”
- Environment provisioning
- Application deployment
- Database / queue / cache provisioning
- Observability onboarding
- Secrets, identity, network access
Portal answers: “How do product teams discover and access those capabilities?”
- Service catalog
- Documentation entry point
- Self-service forms / actions
- Cost / SLO dashboards per service
The platform is required for self-service to work. The portal is required for discoverability when service count grows past what teams can hold in their heads.
When you need a portal
A portal becomes valuable when:
- Service count is large — 50+ services where engineers can’t navigate all of them.
- Team size is large — many engineers, many of whom aren’t yet platform-fluent.
- Cross-team service discovery is real — engineers from team A consume services from team B.
- Compliance / audit requires service catalog — regulator-ready service inventory.
When none of these hold (small org, small service count, fluent platform team), a portal adds maintenance cost without much benefit.
Portal options compared
Backstage (CNCF Incubating)
What: Open-source service catalog + plugin ecosystem. Originally built by Spotify, now CNCF.
Strengths: Mature, broad plugin ecosystem, customizable, strong community.
Weaknesses: Operational cost is real — running Backstage means maintaining plugins, integrating with internal tools, evolving with Backstage’s release cadence. Underestimated by many adopters.
Best for: Mid-to-large engineering orgs (200+ engineers) with platform-team capacity to maintain Backstage as a product.
Port (port.io)
What: SaaS internal developer portal.
Strengths: No self-hosting; quicker to deploy than Backstage; opinionated.
Weaknesses: SaaS dependency (sovereignty implications); less customizable than Backstage.
Best for: Mid-size orgs willing to use SaaS, wanting to skip Backstage’s operational cost.
Cortex / Compass / custom variants
Adjacent options with different trade-offs. Cortex is engineering-effectiveness-focused; Compass is Atlassian-native; custom is “build it yourself.”
No portal
What: IaC repository + Markdown documentation + GitOps interface.
Strengths: Zero operational cost beyond Git. No portal-specific maintenance.
Weaknesses: Discoverability scales poorly past 30-50 services.
Best for: Smaller orgs (under ~100 engineers) where the portal cost would exceed its value.
Backstage’s actual best fit
Backstage works well when:
- 200+ engineers, 100+ services
- Platform team has 5+ engineers who can dedicate time to maintenance
- Plugin ecosystem matches your tooling
- Customization is a priority (you’ll write or extend plugins)
When those don’t hold — the operational cost overshoots the value, and a lighter-weight option fits better.
CNOE — the open-source platform-engineering reference
The CNCF CNOE (Cloud Native Operational Excellence) project is worth mentioning. It’s an opinionated reference architecture combining Backstage, Argo CD, Crossplane, External Secrets, and other CNCF tools into a coherent platform pattern. For organizations that want a “platform-in-a-box” using CNCF projects, CNOE is the structured starting point.
CNOE is complementary to Cozystack: CNOE focuses on the developer portal + tooling layer; Cozystack focuses on the underlying multi-tenant Kubernetes-native platform with virtualization. Both can coexist.
How to decide
A practical decision tree:
- Do you have a working platform underneath? If no, build that first. Portal adoption assumes platform exists.
- Service count over 50? Engineering org over 100? If yes, a portal helps. If no, a portal is over-engineering.
- Backstage operational cost realistic? If yes (large team, plugin-friendly culture), Backstage. If no, Port or Cortex.
- SaaS acceptable? If yes, Port or Cortex. If no, Backstage or custom.
- Will you actually customize? If yes, Backstage. If no, Port.
The decision is smaller than vendors make it sound. The bigger architectural decision is the platform underneath.
Test yourself: portal vs platform (and Backstage)
5 questions · ~2 min