TT Lab

한국어 English 日本語

Get started
Blog

Blog

Internal Developer Platforms (IDPs) in 2026 — Backstage / Port / OpsLevel / Cortex / Compass / Roadie Deep Dive

"Platform engineering didnt replace DevOps. It finally productized the DevOps promise." — an SRE lead

This post is a map of the Internal Developer Platform (IDP) market as of May 2026. Backstage graduated from the CNCF and became the de facto standard. In parallel, Spotify launched a commercial Portal for Backstage, and Roadie established itself as a managed Backstage with classic YC speed. Around them, a SaaS cohort — Port, OpsLevel, Cortex, Configure8, Humanitec — has been taking the "Backstage is heavy" narrative to market. Atlassian Compass walked in with Jira/Confluence on its hip.

We will compare these tools along five primary axes — catalog, scorecards, golden paths, self-service infrastructure, software templates — and end with real cases from Karrot and Toss in Korea, and CyberAgent CIU and Mercari in Japan, before landing a decision guide for whether your own team should adopt an IDP at all.

1. The 2026 IDP Map — Why Platform Engineering, Again

In the early 2020s "DevOps" got interpreted as "everyone does everything." Backend engineers wrote Kubernetes manifests by hand, hand-rolled Terraform, polished GitHub Actions workflows daily, and maintained five environment-specific Helm value files per service. The result was a cognitive load distribution of "30% time on feature work, 70% time on infra and tooling" — and it started eroding productivity.

Platform engineering is the movement that says: absorb that cognitive load into an internal product. That product is the IDP. The 2026 market splits roughly into four camps.

Gartner predicted that by 2026, 80% of large software engineering organizations would have a platform team. The Stack Overflow Developer Survey 2025 showed 38% of respondents already had a dedicated platform team at work.

2. IDP Core Concepts — Catalog / Scorecard / Golden Path / Self-Service

There is a shared vocabulary for evaluating IDPs. Five axes.

1) Software Catalog. The single searchable metadata store for every service, library, API, and data pipeline your company owns. The Backstage catalog-info.yaml file has become the de facto interchange format.

2) Scorecard. A checklist of standards every service should meet. "Test coverage above 70%", "Datadog alerts configured", "runbook present", "owner declared." The platform evaluates these continuously and grades each service. OpsLevel and Cortex lead with this; Backstage implements similar functionality via the Tech Insights plugin.

3) Golden Path. The recommended way to do a thing. "Go service equals chi router plus zap logger plus OpenTelemetry plus the standard GitHub Actions workflow." Deviating is allowed but requires explicit justification.

4) Self-Service Infrastructure. Developers create new databases, queues, and S3 buckets without filing tickets. Backend is typically Crossplane or Terraform Cloud; the frontend is exposed as a Backstage Software Template or a Port Action.

5) Software Template. A scaffolder that generates the boilerplate for a new repo or service. The @backstage/plugin-scaffolder package is the reference. Think of this as the IDP version of Cookiecutter or Yeoman.

Of these five, the catalog is the heart. An IDP without a working catalog is just a wiki.

3. Backstage — CNCF Graduated, De Facto Standard

Backstage is the IDP framework Spotify open sourced in 2020. CNCF Incubating in 2022, Graduated in 2024. Written in React, Node.js, and TypeScript. The plugin architecture is the headline strength.

Architecture in one file:

# catalog-info.yaml — the de facto Backstage metadata format
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Payment processing service
  annotations:
    github.com/project-slug: myorg/payment-service
    pagerduty.com/integration-key: PD123
    datadoghq.com/service-name: payment
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: payments
  dependsOn:
    - resource:postgres-payments
    - component:user-service

Backstage strengths:

Backstage weaknesses:

Who should pick it: Engineering organizations of 100 or more, with at least five people on the infrastructure or platform team, and an absolute preference against data lock-in. Netflix, Spotify, American Airlines, Expedia, LinkedIn, and Twilio all run self-hosted Backstage.

4. Spotify Portal for Backstage — The Commercial Package

In 2024, Spotify shipped Portal for Backstage — the commercial product from the team that built the open source framework. It is a bundle of premium plugins, already battle-tested inside Spotify, sitting on top of the open source Backstage core.

Headline plugins:

Pricing is reportedly per-seat per-month, and you still self-host the Backstage instance. In other words: you host it, you license the premium features.

Who should pick it: Organizations already operating Backstage in-house that would rather buy scorecards, AI search, and enterprise RBAC than build them. Conservative enterprises for whom "endorsed by the original creators" is a real procurement criterion.

5. Roadie — Managed Backstage (YC)

Roadie is a Y Combinator alum that ships hosted Backstage. Think of it as outsourcing Backstage operations.

Highlights:

Why pick Roadie:

  1. You want Backstage but have no one to run it.
  2. You want to compress a 6-month setup into one week.
  3. You want catalog data to live in GitHub as catalog-info.yaml, not in some proprietary database.

Limits: deeper customization is more restricted than self-hosted Backstage. Some plugins do not work in the managed environment.

6. Port — Opinionated, Fast

Port launched in Tel Aviv in 2022 and closed Series B in 2024. The pitch: "Backstage is heavy; we are light and opinionated."

Ports data model differs from Backstages. Backstage uses fixed kinds — Component, API, Resource, System, Domain — whereas in Port you define your own Blueprints:

# Port Blueprint example
identifier: microservice
title: Microservice
icon: Microservice
schema:
  properties:
    language:
      type: string
      enum: [Go, TypeScript, Python, Rust]
    tier:
      type: string
      enum: [tier-1, tier-2, tier-3]
    on_call:
      type: string
      format: user
    slo:
      type: number
relations:
  team:
    target: team
    required: true
  database:
    target: postgres_instance
    many: true

Port strengths:

Port weaknesses:

Who should pick it: 50 to 300 engineer organizations where time-to-value matters and your platform team is two or three people.

7. OpsLevel — Service Ownership

OpsLevel launched in Canada in 2018. Catalog plus scorecards (quality grading) is the core.

The OpsLevel differentiator is the Maturity Rubric. Each service gets graded A through F automatically:

The grade is recomputed daily and surfaced on team dashboards. When the CTO starts asking "why is your team averaging C?", behavior changes.

OpsLevel strengths:

Weaknesses:

Who should pick it: organizations whose core problem is "our service quality is inconsistent — start by measuring it."

8. Cortex — Engineering Excellence

Cortex effectively chases the same market as OpsLevel. They are routinely compared and frequently meet in procurement bake-offs. Cortex started in 2019 in the US and is at Series C.

Where Cortex differs from OpsLevel:

Who should pick it: roughly the same audience as OpsLevel. Run both demos during procurement and pick the one your team prefers. The mental model: OpsLevel leans toward "strict governance," Cortex toward "flexible campaigns."

9. Atlassian Compass — Integration With Jira and Confluence

Atlassians Compass went GA in December 2023 with a sharp message to existing Atlassian customers: "you already use our tools — buy your IDP from us too."

Compass uses a data model compatible with Backstages catalog-info.yaml — its config file is called compass.yml and the schema overlaps heavily. Migration in either direction is realistic.

Compass strengths:

Weaknesses:

Who should pick it: organizations already on the Atlassian stack. Often "add Compass to our Atlassian bill" is politically easier than "adopt an IDP."

10. Humanitec / Configure8 — The Newer Camp

Humanitec prefers the term Platform Orchestrator over IDP. The center of gravity is Score, a workload specification format (now a CNCF Sandbox project). Score is the IaC abstraction layer that generates environment-specific Kubernetes manifests automatically.

# score.yaml — Humanitec / Score example
apiVersion: score.dev/v1b1
metadata:
  name: hello-world
containers:
  hello:
    image: nginx:latest
    variables:
      DB_HOST: ${resources.db.host}
      DB_USER: ${resources.db.user}
resources:
  db:
    type: postgres

That single file generates dev, staging, and prod Kubernetes manifests plus Helm and Terraform. Powerful when you need a backend for self-service infrastructure.

Configure8 is a Y Combinator graduate and a newer entrant. GA in 2024. Same catalog-and-actions model as Port, but with the marketing line "lighter and more opinionated." Targets the startup and scale-up market.

You may remember Effx — acquired by LinkedIn in 2022 and absorbed into LinkedIns internal IDP. Once a dark horse in this market, it no longer exists as a standalone product.

11. DORA / SPACE Metrics — What an IDP Actually Measures

The metrics IDPs measure come from two frameworks.

DORA (DevOps Research and Assessment) four key metrics:

  1. Deployment Frequency — how often you ship to production.
  2. Lead Time for Changes — time from code commit to production deploy.
  3. Change Failure Rate — percentage of deploys that cause incidents.
  4. Mean Time to Recovery (MTTR) — time from incident start to resolution.

The DORA 2024 State of DevOps report defines "Elite" performance as multiple deploys per day, lead time under one hour, change failure rate under 5%, and MTTR under one hour.

SPACE framework (Microsoft Research, 2021):

SPACE captures what DORA does not — developer satisfaction, flow, collaboration quality. The actual adoption pattern across IDPs:

The hard part is not collection — it is definition. The definition of "one deploy" varies team to team (PR merge? canary start? 100% traffic?). Adopting an IDP does not make this definitional work disappear.

12. Backstage vs Port — Self-Hosted vs SaaS

The most common forced decision is Backstage (self-hosted) vs Port (SaaS). Five axes.

AxisBackstagePort
Setup time3 to 6 months1 to 7 days
Operational cost2 to 5 platform engineersSeat subscription only
Data lock-inMinimal (self-hosted)Medium (Port cloud)
CustomizationUnlimited (code)Medium (Blueprint plus Action)
Plugin count200+60+
Annual cost (100-person org)500K to 1M USD in headcount plus infra20 to 50 USD per seat per month

General guidance:

There are always exceptions. A 30-person fintech might self-host Backstage (security or lock-in policy). A 1,000-person gaming company might run Port (velocity over flexibility).

13. Korea (Karrot, Toss) / Japan (CyberAgent, Mercari) IDP Cases

Korea — Karrot: Karrot has been running a Backstage-based IDP since 2022. The internal name is "Karrot Platform" or "DX Console." Every microservice is required to ship a catalog-info.yaml, and a Soundcheck-style scorecard measures SLO compliance, security patch posture, and cost visibility. Since 2024 they have added an internally trained LLM for catalog search.

Korea — Toss: Toss runs an in-house IDP called "Toss Developer Platform" internally. They evaluated Backstage early on but went with a custom build. Reasons: (1) fintech-grade security requirements, (2) Tosss monorepo structure and bespoke build system conflicted with Backstages abstractions. They built their own catalog, their own self-service infrastructure (Kubernetes namespace creation, RDS provisioning), and their own DORA dashboards.

Japan — CyberAgent CIU (CyberAgent group Infrastructure Unit): CyberAgent has an org called CIU that provides common infrastructure across the whole group. CIU runs Cycloud, a homegrown IDP, on Kubernetes and OpenStack, serving 100+ subsidiaries with multi-tenant self-service infrastructure. They did not adopt an external SaaS IDP because (1) tenant isolation requirements across subsidiaries, (2) cost.

Japan — Mercari: Mercari evaluated Backstage in the early 2020s and in 2023 integrated parts of it into what they call the "Microservices Platform." The catalog uses a catalog-info.yaml-compatible format, but the UI is a custom React app. They wrote custom plugins for Spinnaker, ArgoCD, Datadog, and Sentry. The Mercari Engineering blog has detailed write-ups.

The common pattern: global big tech and large scale-ups skew toward self-hosting or custom building, while 100 to 500 engineer Korean and Japanese scale-ups are increasingly adopting SaaS (especially Port and OpsLevel).

14. Should Your Team Adopt an IDP — A Decision Guide

Five-step checklist.

Step 1: does the problem exist?

Three or more — consider an IDP. Two or fewer — a well-maintained wiki might be enough.

Step 2: organization size matching

EngineersRecommendation
Up to 30Wiki, GitHub READMEs, custom scripts. IDP cost rarely justifiable.
30 to 80Port or Roadie. Fast-setup SaaS is the answer.
80 to 300Pick from Port, OpsLevel, Cortex, Compass, Configure8. Run a procurement bake-off.
300+Self-hosted Backstage plus Spotify Portal. Staff a platform team of 5+.

Step 3: platform team headcount

Buying the tool is not the end. Someone has to populate catalog data, define scorecard rules, build golden path templates, and train developers. A minimum of 1.5 FTE for six months is the threshold for visible results.

Step 4: catalog data source

Where does your service metadata live today?

Step 5: success metrics

Define your KPIs before adoption:

If those numbers do not move six months in, adoption failed — either the rollout failed, or the data population failed, or both.


An IDP is not magic. It is context and governance encoded into code. Tool choice is the second problem; the first problem is the political agreement on what your company calls "the standard." With that agreement, Backstage or Port — either works. Without it, no tool succeeds — you just end up with more wikis.

## References

Sign in to like

Comments

No comments yet.

Sign in to leave a comment