Backstage and Developer Portals in 2026: IDP at Scale, Roadie, Port, Cortex

Internal Developer Portals (IDPs) crossed the chasm from “nice to have” to “table stakes for platform engineering” between 2023 and 2026. Spotify Backstage’s CNCF Incubation graduation, the rise of hosted Backstage (Roadie, Aiven), the well-funded SaaS competitors (Port, Cortex, OpsLevel), and the broader IDP movement put a portal at the center of most serious platform-engineering organizations. The question is no longer whether you need one — it is which one, and what scorecards and metrics it should enforce.

This is the senior platform-engineer view of where the IDP market actually sits in 2026.

The IDP movement, briefly#

The Internal Developer Platform thesis: developers should consume infrastructure, deployment, observability, and compliance through a self-service interface, not through tickets to platform teams. The portal is the front door. The platform underneath — Kubernetes, Terraform, CI/CD, secrets management, monitoring — is the engine room.

Done well, the IDP shifts the platform team’s role from “the team that runs deploys for you” to “the team that builds the paved road for you to run deploys on yourself.” The IDP is the surface that makes the paved road feel like a paved road and not a configuration scavenger hunt.

The Team Topologies framing — stream-aligned teams, platform teams, enabling teams, complicated subsystem teams — became the lingua franca around this in 2022 and 2023 and is firmly in the vocabulary by 2026.

Backstage at scale: where it is and is not#

Spotify Backstage hit 1.30+ in 2025 and has graduated to CNCF Incubation. The core surface — service catalog, software templates, TechDocs, plugins ecosystem — is genuinely mature. The plugin marketplace is large; integrations exist for almost every CI/CD, monitoring, and cloud provider; the search and entity-relations work well at meaningful scale.

What Backstage does well: rich plugin ecosystem; deeply customizable; the right call when the platform team has serious frontend engineering capacity and a vision for what the portal should look like in 18 months.

What Backstage does less well: out-of-the-box operational cost. A self-hosted Backstage deployment requires ongoing TypeScript work, plugin maintenance, upgrade discipline, and a real frontend engineer to make it not look like an internal tool from 2014. The cost of operating Backstage at quality is the dominant variable that breaks small-team deployments.

The gardener-vs-Backstage debate (the SAP-originated Gardener project for Kubernetes-cluster-as-a-service vs Backstage as the portal layer) is largely settled: they solve different problems. Gardener handles cluster lifecycle; Backstage handles developer-facing portal. Modern platform stacks include both.

Roadie and Aiven Backstage: hosted options#

The two main hosted Backstage offerings:

Roadie is the SaaS hosted Backstage, founded 2020, real production traction at hundreds of organizations. They run the upgrade treadmill for you, integrate the common plugins, and provide a clean admin experience. The pricing is per-developer. The right pick for teams that want the Backstage feature set without the operational ownership.

Aiven Backstage (Aiven’s hosted variant) is newer but rapidly maturing. Strong fit for teams already running on the broader Aiven data platform.

The hosted-Backstage tradeoff: you give up some customization flexibility for someone else handling the operational treadmill. For most mid-sized teams the trade is favorable. For larger teams with serious customization needs, self-hosted is still the path.

The commercial IDP competitors#

Three serious commercial IDPs compete head-on with Backstage:

Port. Strong product surface, easy onboarding, very approachable scorecards, low-code interface for non-engineering personas. The right pick when the IDP is owned by engineering leadership but consumed by non-engineering stakeholders (security, compliance, executive metrics).

Cortex.io. Strong tech-health scorecard story; deep integrations with the typical observability and code-quality tools; their “service maturity” pattern is a clean abstraction. The right pick when the dominant IDP use case is enforcing tech-health standards across services.

OpsLevel. Similar shape to Cortex with a slightly different product opinion. Strong scorecard story, strong integration story. Real production traction.

The pitch all three commercial IDPs make against Backstage: “you should not have to staff a frontend engineering team to operate your developer portal.” For organizations without that engineering capacity, the pitch lands. For organizations with serious customization needs and the engineering team to back it, Backstage wins on long-term flexibility.

Scorecards and tech-health metrics: what actually moves the needle#

The IDP feature that delivers the most concrete value in our experience: scorecards that quantify service health and create accountability.

The scorecards we deploy by default for client platform engagements:

• Production readiness. Does the service have alerts? Runbooks? On-call rotation? SLOs? Recent load testing?
• Security posture. SBOM up to date? Critical CVEs zero? Secrets in a vault, not in environment variables? Dependency upgrades within 90 days?
• Documentation health. README exists and is non-trivial? TechDocs published? Architecture diagram current?
• Reliability metrics. Error rate within SLO? Deploy frequency reasonable? MTTR within target?
• Cost discipline. Tagged for chargeback? Idle capacity below threshold? Reserved-instance coverage at target?

The pattern: the IDP renders each service’s scorecard publicly across the organization. Teams compete on the leaderboard. Platform engineering provides the paved-road tools to fix gaps. Over 6 to 12 months the median service quality moves measurably.

This is the IDP feature most underdone in DIY portals — and the feature commercial IDPs (Cortex, OpsLevel, Port) lead with. Backstage has Tech Health plugins; they require setup.

What an IDP does not solve#

A short list of things teams blame the IDP for that the IDP cannot fix:

• A bad paved road. If the underlying platform requires a 20-step deploy with three manual steps, a beautiful portal will not save you. The portal exposes the platform; it does not replace it.
• A disengaged engineering culture. Scorecards work when teams care about them. If leadership does not back the scorecard, the scorecard is wallpaper.
• Conway’s Law mismatches. If the org chart and the service catalog disagree, the portal will show the disagreement clearly. Fixing it requires reorgs, not a new plugin.
• Lack of platform-engineering capacity. A portal at quality requires platform owners. There is no IDP-in-a-box that eliminates that.

The IDP is leverage on a real platform-engineering practice. Without the practice, the portal is decoration.

How we deploy IDPs in 2026#

For client engagements, the typical decision tree:

• Existing platform-engineering team with frontend capacity: self-hosted Backstage. Roadie or Aiven if the team explicitly does not want the operational ownership.
• Engineering org without dedicated platform team: Port for breadth, Cortex for scorecard focus, OpsLevel as alternative. The commercial IDP is the right path when there is nobody to operate Backstage.
• Very small teams (under 50 engineers): often no dedicated IDP. A well-organized GitHub org plus monitoring dashboards covers it. The IDP gets ROI past roughly the 50 to 100 engineer mark.

The mistake we see: organizations adopting Backstage because it is the obvious open-source choice, then under-staffing operations. The result is a half-finished portal that the team has lost confidence in. Either commit to staffing Backstage at quality or pick a hosted/commercial option.

The scorecard rollout pattern that works#

For platform engagements where we are deploying scorecards, the pattern:

1. Phase 1 (month 1): publish initial scorecards across all services with no enforcement. Make the data visible. Let teams react.
2. Phase 2 (months 2-3): invest in paved-road tools to make fixing gaps easy. Templates, runbooks-as-code, automated SBOM, automated dependency updates.
3. Phase 3 (months 3-6): introduce social pressure. Leaderboards visible to leadership. Discussion in engineering forums.
4. Phase 4 (month 6+): introduce gating. New deploys require minimum scorecard. Major releases require executive scorecard.

This pattern works when leadership backs phase 3 and 4. It does not work when leadership treats the scorecard as someone else’s responsibility.

For the broader context on platform engineering and DevEx, see our DevOps platform engineering piece, our Kubernetes production patterns, and the ADRs piece.

Where pdpspectra fits#

Our DevOps and CI/CD practice deploys IDPs (Backstage, Roadie, Port, Cortex) and the scorecards that make them concretely valuable. We have shipped IDP rollouts at clients ranging from 50-engineer SaaS teams to 800-engineer enterprises, with the corresponding paved-road investments to back the scorecards.

Related reading: Backstage plugins worth building, Kubernetes production patterns, and ADRs in 2026.

---

A developer portal works when the platform underneath does. Talk to our team about your IDP strategy.