IDP 2026 Deep Dive: Backstage, Port, Cortex, OpsLevel, Humanitec — The Present and Future of Platform Engineering

Introduction: Why IDPs Became Mandatory in 2026

In 2024, Gartner predicted that "by 2026, 80% of large software organizations will operate a platform team." In 2026, that prediction has effectively been realized. The CNCF 2025 Annual Survey shows that Backstage has become the fastest-adopted CNCF Incubating project after GitOps tooling, and SaaS IDPs like Port and Cortex have closed Series C and D rounds, entering their full-scale expansion phase.

But in late 2025, one event shook the IDP community: Spotify split key features from its internal "Portal" out of Backstage open source and released them as a separate commercial package. The move ignited fierce debate about Backstage governance and licensing, and forced organizations to re-evaluate the trade-off between "managed Backstage" (Roadie) and self-hosting.

This article takes a deep look at 11 major players in the 2026 IDP market — Backstage, Port, Cortex, OpsLevel, Humanitec, Mia-Platform, Compass (Atlassian), Roadie, Configure8, Mercari ATLAS, and Naver SCM Portal.

Platform Engineering vs DevOps: What Is Different

The 2010s DevOps movement tore down the wall between development and operations with the philosophy of "You build it, you run it." But by the mid-2020s, with microservices exploding, the model showed its limits. Demanding that the average full-stack developer deeply understand Kubernetes manifests, Terraform, Helm charts, ArgoCD, Prometheus, Grafana, Datadog, Snyk, and SonarQube — all of it — was unrealistic.

Team Topologies, published in 2019 by Manuel Pais and Matthew Skelton, offered an answer: a Platform team must provide self-service infrastructure so that Stream-aligned teams (value delivery teams) can move quickly.

Platform Engineering is not a rejection of DevOps but its evolution. The cultural values of DevOps (collaboration, automation, measurement, sharing) are preserved, while a well-designed abstraction layer is added to reduce cognitive load.

Team Topologies and the Four Team Types

Team Topologies defines four fundamental team types:

Stream-aligned team — aligned with a value stream (e.g. payments, search, recommendations)
Platform team — provides a self-service platform for stream-aligned teams
Enabling team — supports and coaches other teams in a specific technical domain (security, SRE, data)
Complicated-subsystem team — owns areas requiring deep specialist expertise (e.g. ML inference engines, trading engines)

The golden rule for platform teams is "treat the platform as a product." The users are the stream-aligned developers, and their satisfaction (NPS) and adoption rate become the success metrics for the platform team.

Backstage 1.30: What Changed at the Core

As of May 2026, Backstage is on the 1.30.x line. Major changes in the 1.30 series include:

New Frontend System (NFS) GA: the new extension model replacing the legacy createPlugin API is now stable.
Catalog database backend performance improvements: SQLite in production (beyond PostgreSQL) is officially in the deprecation phase.
Permission Framework integration: per-catalog-entity RBAC policies can now be expressed in OPA (Open Policy Agent) or Casbin.
Software Templates schema migration from v1beta3 to v1.

The biggest operational shift is the NFS (New Frontend System). If you don't migrate existing plugins, support will end after 1.32. For organizations with 50+ in-house plugins (Netflix, Spotify, Rakuten), this is a 6–9 month migration project.

Backstage Core Concepts: Software Catalog

The Software Catalog is the heart of Backstage. Every component (service, library, website), API, resource (database, S3 bucket), system, and domain is expressed as a catalog-info.yaml file.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Core payment processing service
  annotations:
    github.com/project-slug: acme-corp/payment-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/integration-key: PAGERDUTY_KEY_REF
    sonarqube.org/project-key: payment-service
    grafana/dashboard-selector: "tag = 'payment'"
  tags:
    - java
    - spring-boot
    - tier-1
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout
  providesApis:
    - payment-api-v2
  consumesApis:
    - fraud-detection-api
    - notification-api-v1
  dependsOn:
    - resource:postgres-payments
    - resource:redis-payment-cache

Once this file is pushed to GitHub, the Backstage Catalog Processor discovers it and automatically indexes all metadata, owners, and dependency graphs. When a new engineer on another team asks "who owns the payment system? what DB does it use?", the answer lives in a YAML file next to the code.

Software Templates and the Scaffolder

Software Templates deliver on the IDP's most powerful promise — "a new service in production in five minutes."

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: java-spring-microservice
  title: Java Spring Boot Microservice (Golden Path)
  description: Java 21 + Spring Boot 3.3 + JPA + OpenTelemetry
spec:
  owner: team-platform
  type: service
  parameters:
    - title: Service Identity
      required: [name, owner, tier]
      properties:
        name:
          type: string
          pattern: '^[a-z][a-z0-9-]{2,30}$'
        owner:
          type: string
          ui:field: OwnerPicker
        tier:
          type: string
          enum: [tier-1, tier-2, tier-3]
  steps:
    - id: fetch-template
      name: Fetch Skeleton
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=acme-corp
        defaultBranch: main
        protectDefaultBranch: true
        requireCodeOwnerReviews: true
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

Running this template once automatically triggers: GitHub repo creation, branch protection, CODEOWNERS setup, ArgoCD ApplicationSet registration, Datadog monitor provisioning, OpsGenie on-call schedule linking, and a SonarCloud project. A developer can go from first commit to production deploy in 30 minutes.

TechDocs: Documentation Next to the Code

TechDocs is Backstage's implementation of "docs as code." Built on MkDocs, it renders markdown files placed in each component's docs/ directory into a searchable site inside Backstage.

The key operational pattern is the split between TechDocs Out-of-the-box (OOTB) vs Recommended. OOTB mode builds docs on demand when a user enters the catalog, which creates severe latency at 200+ component scale. The Recommended mode builds MkDocs in CI, pushes to S3/GCS, and Backstage merely serves static files. In production environments, Recommended mode is effectively the standard.

Backstage Plugin Ecosystem: Five Core Plugins

Backstage's true value comes from its plugin ecosystem. As of May 2026 there are 350+ official and community plugins. Here are the five most widely adopted:

@backstage/plugin-kubernetes — surfaces K8s deployment, pod, service, and HPA state per component. Multi-cluster support is solid; EKS/GKE/AKS auth is all standard.
@backstage-community/plugin-github-actions — embeds recent GHA workflow runs into each component's catalog page.
@backstage-community/plugin-sonarqube — exposes code quality metrics (coverage, smells, vulnerabilities) in the catalog.
@backstage/plugin-techdocs — the docs-as-code engine described above.
@backstage-community/plugin-cost-insights — displays per-component cloud cost over time. The favorite plugin of FinOps teams.

Port: Model-Driven Low-Code IDP

Port (getport.io) was the fastest-growing SaaS IDP in 2024–2025. Where Backstage takes a "code-first" approach (catalogs defined in YAML), Port is "model-first": you first define what entity types (Blueprints) exist and what properties and relations they have, via UI or JSON.

{
  "identifier": "service",
  "title": "Service",
  "schema": {
    "properties": {
      "language": { "type": "string", "enum": ["go", "java", "python", "node"] },
      "tier": { "type": "string", "enum": ["1", "2", "3"] },
      "on_call_rotation": { "type": "string", "format": "url" },
      "slo_availability": { "type": "number", "minimum": 0, "maximum": 100 }
    },
    "required": ["language", "tier"]
  },
  "relations": {
    "owning_team": { "target": "team", "required": true, "many": false },
    "deployments": { "target": "deployment", "required": false, "many": true }
  },
  "calculationProperties": {
    "is_production_ready": {
      "calculation": ".properties.tier == \"1\" and .properties.slo_availability >= 99.9",
      "type": "boolean"
    }
  }
}

Port's strengths:

Exporters: AWS, GCP, K8s, GitHub, Snyk, Datadog, and 30+ integrations configurable without code.
Scorecards: quantitative service maturity.
Self-Service Actions: trigger actions like /port deploy from Slack.

The downsides are SaaS dependency and enterprise-tier pricing (starting around $25K/year), with on-prem options arriving late, which remains a barrier for Korean financial sector adoption.

Cortex: Service Maturity at the Center

Cortex (cortex.io) is an IDP centered on "Service Maturity." Where Port and Backstage balance catalog and actions, Cortex makes Scorecards the first-class citizen.

Cortex Scorecards support rule-based evaluations like:

Every service must have an owner team.
Tier-1 services must have a PagerDuty integration.
SLO definitions must be refreshed within 90 days.
Every production service must have an SBOM registered.
Code coverage above 70%.

Each rule has a weight, and every service is auto-classified as "Bronze / Silver / Gold." Platform teams can tune weights quarterly to reflect company priorities (e.g. a security-hardening quarter, a reliability quarter).

OpsLevel: Rubrics and Campaigns

OpsLevel (opslevel.com) is the most direct competitor to Cortex. Its core concepts are Rubrics and Campaigns.

Rubrics: checklists each service must satisfy (similar to Cortex Scorecards).
Campaigns: time-bounded improvement initiatives like "remove Log4j 1.x across the entire company within 30 days." Each team's progress is tracked in real time.

OpsLevel's differentiator is AI Engineer (launched in 2025) — you can query the catalog in natural language ("which tier-1 services have no PagerDuty integration?"). Compare this with Backstage's RAG-based catalog search, which is still experimental.

Humanitec and Score: Standardizing Workload Specs

Humanitec (humanitec.com) sits at a different layer from the other IDPs. If Backstage, Port, and Cortex are the "portal" layer, Humanitec is the "Internal Developer Platform Orchestrator" — the engine that actually abstracts environment provisioning and deployment.

The open spec Humanitec drives is Score (score.dev). Score joined CNCF Sandbox in 2025 and aims to be the environment-agnostic standard for workload specifications.

apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  main:
    image: ghcr.io/acme/orders-api:v3.4.2
    variables:
      DATABASE_URL: ${resources.orders-db.connection}
      REDIS_URL: ${resources.cache.url}
      LOG_LEVEL: info
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "1000m"
        memory: "512Mi"
service:
  ports:
    http:
      port: 8080
      targetPort: 8080
resources:
  orders-db:
    type: postgres
    params:
      version: "16"
  cache:
    type: redis
  dns:
    type: dns

A single file transparently translates to docker-compose in dev, Kubernetes + RDS in staging, and EKS + Aurora in production. If Backstage answers "what exists?", Score answers "how is it run?"

Mia-Platform: Europe's IDP Heavyweight

Mia-Platform (mia-platform.eu) is a Milan-based IDP that has strong adoption across European financial services. It packages a Backstage UI on top of Mia's own fast-data engine, microservice templates, and multi-cluster deployment tooling. Its SaaS+self-hosted hybrid model and built-in PSD2/GDPR compliance are its main strengths in the EU.

Compass (Atlassian): Integration with Jira and Confluence

Atlassian Compass targets organizations already running Jira, Confluence, and Bitbucket. Its standout strength is workflow integration. From a service in the Compass catalog, you can create Jira tickets directly, and change history publishes automatically to Confluence pages.

The catch: Compass is currently Atlassian Cloud-only, and many large Korean and Japanese organizations still on Data Center are hesitant to adopt. Whether Atlassian ships a Data Center version of Compass in 2026 is a key thing to watch.

Roadie: Managed Backstage

Roadie (roadie.io) is the SaaS for organizations that "don't want to run Backstage themselves but still want Backstage's flexibility." Roadie packages Backstage core as plugins-as-a-service without forking, maintaining upstream compatibility.

Decision criteria for choosing Roadie:

Platform team of 5 or fewer → Roadie recommended (self-hosting Backstage needs 2–3 full-time engineers).
Low need for custom plugin development → Roadie recommended.
Data sovereignty (especially EU/Korea financial) → self-hosted Backstage.
200+ services → factor in Roadie's multi-tenancy limits.

Configure8: IDP Focused on Visualization

Configure8 is a newer IDP with a strong emphasis on service topology visualization. Its differentiators are dependency graphs, real-time traffic flow, and blast-radius visualization during incidents. Catalog consistency and self-service automation are still less mature than Port or Backstage.

Korean and Japanese Cases: Kakao, Mercari ATLAS, Rakuten

In Korea, Kakao's Cognity platform team — in collaboration with Kakao Enterprise — operates a Backstage-based internal IDP. It integrates SLO, cost, and security compliance management across 200+ microservices. Naver runs SCM Portal, an in-house IDP, which couples GitHub Enterprise + Jenkins + Argo + their own K8s control plane. LINE (LY Corporation) maintains an internal fork of Backstage as its dev portal.

In Japan, the best-known case is Mercari's ATLAS. First disclosed in 2022 on the Mercari Engineering blog, ATLAS is a Backstage-based internal portal that integrates ML Platform, SRE, and Security tools. As of 2026, it manages 800+ components across the Mercari group. CyberAgent's AKE (AbemaTV Kubernetes Engine) and Rakuten's One Platform also operate their own IDPs. Sansan is known as an early Japanese adopter of Compass.

Golden Paths and Paved Roads

"Golden Path" is a term Spotify introduced in 2020 — one recommended, well-paved route where infrastructure, security, and observability come automatically. Netflix calls the same idea the "Paved Road" — on the road you are safe and fast, but off-roading is your own responsibility.

Golden Paths are not mandatory. Teams with special requirements can deviate, but they shoulder the responsibility (security audits, cost optimization, incident response) themselves. When this trade-off is clearly communicated, developer autonomy and organizational standards can coexist.

Measuring DX: DORA + SPACE

How should a platform team define "success"? The four DORA (DevOps Research and Assessment) metrics are the starting point.

Deployment Frequency — how often you deploy
Lead Time for Changes — time from commit to production
Change Failure Rate — share of deployments causing incidents/rollbacks
Mean Time to Recovery — time to restore service after an incident

But DORA alone is not enough. The SPACE framework published by Microsoft Research in 2021 adds five dimensions: Satisfaction, Performance, Activity, Communication/collaboration, and Efficiency. Developer satisfaction in particular must be tracked via a quarterly NPS — if the IDP's real users don't enjoy it, the quantitative metrics are likely lying.

Self-Service Infrastructure Templates: Terraform Modules + Crossplane

Day 0 of Software Templates is easy; Day 2 (lifecycle management) is hard. The 2026 standard pattern:

Terraform Modules (or Pulumi/CDK) — opinionated units of cloud resources.
Crossplane Compositions — managing cloud resources Kubernetes-natively.
Backstage Scaffolder triggers both and registers the resulting resources in the catalog.

# What happens when a developer requests "New Postgres DB" in the Backstage UI
backstage scaffolder run \
  --template postgres-database \
  --name orders-db \
  --tier production \
  --size medium

# Under the hood
git push -> renovate-style PR -> ArgoCD sync ->
Crossplane Composition -> AWS RDS Aurora cluster ->
catalog entity registration -> Datadog monitor created ->
PagerDuty service linked -> Slack notification

Multi-Cluster App Management

In 2026, the standard for large organizations is a fleet of clusters — separated by region, environment, and team. The Backstage Kubernetes plugin handles 30+ clusters well, but beyond that you need the following patterns:

Modularize cluster locators: model cluster metadata as catalog entities.
ArgoCD ApplicationSet + Backstage: visualize a single component deployed across 5 regions simultaneously.
Integrate multi-cluster control planes like KubeFleet / Karmada / Liqo.

Open Source IDP vs SaaS: Decision Matrix

Item	Backstage (self-hosted)	Roadie (managed BS)	Port	Cortex	OpsLevel
Initial learning curve	High	Medium	Low	Low	Low
Customization freedom	Very high	High	Medium	Medium	Medium
Operational FTEs	2~3+	0.5~1	0.5~1	0.5~1	0.5~1
Starting price (annual)	Infra only	about `$15K`	about `$25K`	about `$30K`	about `$30K`
Data sovereignty	Full control	Limited	SaaS-dependent	SaaS-dependent	SaaS-dependent
Plugins	350+	100+ (curated)	30+ integrations	20+ integrations	25+ integrations
Scorecard maturity	Medium (community)	Medium	High	Very high	Very high

Prices are rough estimates based on publicly available information as of May 2026; actual enterprise contracts require separate negotiation.

Security and Governance: New Responsibilities the IDP Brings

As the privileges an IDP carries grow, so does its attack surface. PagerDuty keys, AWS account IDs, and GitHub PATs exposed in the Backstage catalog, combined with an SSRF vulnerability, can become a critical incident. The 2024–2025 Backstage security advisories (e.g. GHSA-9p4x-3v2h-9q4j) make it clear that the IDP is no longer just a catalog — it sits at the center of the supply chain.

Recommended controls:

Enable the Permission Framework (default deny).
OIDC SSO + step-up auth (sensitive actions require 2FA).
Send every Scaffolder action's audit log to your SIEM.
Express catalog secrets/keys only as references to an external vault.

Adoption Roadmap: 0 → 1 → N

The common pitfall when platform teams first adopt an IDP is "everything at once." A staged approach:

Stage 0 (Months 1–2): 5–10 interviews with stream-aligned teams. Map cognitive load. Identify top 3 pain points.

Stage 1 (Months 3–6): PoC one of Backstage or Port. Start with catalog only. Register 30–50 key services as catalog-info.yaml.

Stage 2 (Months 6–9): Build exactly one Software Template. Example: "Java microservice golden path." Success means 5–10 new services are created from this template.

Stage N (Year 2+): Add Scorecards. Integrate Cost Insights. Multi-cluster visualization. Adopt Score workload specs.

Seven Common Anti-Patterns

Forcing the catalog before proving value — top-down mandates don't drive adoption.
Releasing too many templates at once — one good template beats 30 mediocre ones.
Platform team directly editing stream-aligned team code — violates Topology principles.
Using TechDocs OOTB in production — collapses at 200+ services.
Setting Scorecard weights once and never revisiting — quarterly review is mandatory.
Adopting SaaS IDPs without reviewing data residency — fails audits in financial services.
Reporting only quantitative metrics without measuring NPS — DORA can be green while developers hate the platform.

Beyond 2026: The Future of IDPs

Three big currents will define the next five years of IDPs:

AI-Native IDP: triggering the Scaffolder via natural-language commands ("create a new service in staging"). OpsLevel AI Engineer and Port AI Agents are early examples.
Broader adoption of the Score standard: as the consensus solidifies that K8s manifests are too complex, workload abstraction layers will standardize.
Evolution of Backstage governance: the final lap toward CNCF Graduation. How the Spotify commercial fork issue is resolved is the central question.

Platform Engineering is no longer a trend — it is the standard operating model for late-2020s software organizations.