Backstage vs Port vs Cortex: Picking an IDP in 2026

Internal developer platforms (IDPs) are now a normal part of how larger engineering organizations ship, and the portal question comes up early: build on Backstage, or buy something like Port or Cortex? The tools are only part of the answer. Most platform initiatives that stall do so for organizational reasons, so this post covers both the comparison and the operating model around it.

Backstage vs Port vs Cortex: which should you pick?

Pick Backstage if you can dedicate engineers to running and extending an open-source portal and need deep customization. Pick Port if self-service actions and a flexible data model are the priority and you want SaaS. Pick Cortex if your main problem is inconsistent service quality and you want strong scorecards out of the box.

The rest of this post explains those tradeoffs, then covers golden paths, self-service, team design and measurement.

From DevOps to platform engineering

DevOps was never meant to be a job title. The movement was about shared ownership between development and operations. Over time, “DevOps engineer” came to mean the person who writes the Terraform and maintains the CI pipeline, often working from a queue of tickets.

Platform engineering is the correction. Instead of expecting every application developer to become an infrastructure expert, a platform team builds an internal product that hides the complexity behind self-service interfaces. Developers get what they need without filing a ticket. The platform team standardizes and governs without becoming a bottleneck.

The key distinction: DevOps teams typically work for development teams, handling tickets and configuring infrastructure. Platform teams build products used by development teams. The relationship moves from service provider to product provider.

Adoption has grown quickly. Gartner predicted that by 2026, 80% of large software engineering organizations would have platform teams, up from 45% in 2022, and DORA’s 2025 report found that 90% of organizations have adopted at least one platform and 76% have at least one dedicated platform team. “Platform team” still covers a wide range: some organizations run full service catalogs with automated provisioning, and others renamed an infrastructure team and stopped there.

The platform engineering maturity spectrum ranges from rebranded ops teams to fully productized internal platforms

The three portals

Backstage

Backstage is the open-source framework Spotify released in 2020. It was accepted into the CNCF in September 2020 and moved to Incubating in March 2022 (CNCF). It has the largest community and plugin ecosystem of the three.

The architecture is a React frontend, a Node.js backend and a database, with almost everything extensible through plugins. The software catalog is the core: it models services, APIs, resources and who owns them.

# catalog-info.yaml - Backstage service definition
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing and settlement
  annotations:
    github.com/project-slug: acme/payment-service
    pagerduty.com/service-id: P2KLBN7
    backstage.io/techdocs-ref: dir:.
  tags:
    - payments
    - critical-path
    - java
  links:
    - url: https://grafana.internal/d/payment-service
      title: Grafana Dashboard
      icon: dashboard
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout-system
  providesApis:
    - payment-api
  consumesApis:
    - fraud-detection-api
    - notification-api
  dependsOn:
    - resource:payments-db
    - resource:payments-redis

The tradeoff is ownership. Backstage is a framework, not a finished product. You host it, upgrade it, write or adapt plugins, and keep the catalog accurate. Plugin quality varies a lot; some are production-hardened, others are small community projects that may not keep up with upgrades. Standing up a demo is quick. Getting to a portal developers rely on daily takes sustained engineering time, and that time is the real cost.

Port

Port is a SaaS developer portal. Its data model is built from “blueprints”: you define any entity type (service, environment, cloud resource, team) and the relationships between them, then build self-service actions, scorecards and dashboards on top, largely without code.

The flexibility cuts both ways. You avoid Backstage’s fixed entity kinds, but you have to design your own model, and a poorly designed one is hard to change later. Port suits teams whose main goal is self-service workflows and who would rather not host a portal. Its published pricing has a free tier for up to 15 seats, then plans from $30 per seat per month (up to 50 seats) and $40 per seat per month (up to 200 seats), with custom Enterprise pricing above that.

Cortex

Cortex is a SaaS portal focused on service maturity and operational readiness. Its scorecards, catalog and initiatives are designed to answer “are our services meeting our standards?” out of the box, with rubrics for areas such as production readiness, security and documentation. Self-service exists but is not its center of gravity.

If your main pain is inconsistent service quality (missing runbooks, unowned services, outdated dependencies) rather than missing self-service, Cortex is often the more direct fit. Cortex does not publish prices; its pricing page says only that it charges per seat and that pricing scales with organization size.

Side by side

	Backstage	Port	Cortex
Model	Open-source framework, self-hosted	SaaS	SaaS
Time to first value	Slowest; you build the portal	Fast	Fast
Ongoing effort	Highest; you run and upgrade it	Low to moderate	Low to moderate
Software catalog	Strong, fixed entity kinds	Strong, custom blueprints	Good
Self-service actions	Via templates and plugins	Native, a core focus	Available, less central
Scorecards	Via plugins	Native	Native, a core focus
Customization ceiling	Very high	Moderate to high	Moderate
Pricing	Free software; cost is hosting and engineering time	Free up to 15 seats, then from $30-40 per seat per month	Per seat, not published
Best for	Large orgs with a platform team to own it	Self-service-first teams wanting SaaS	Service quality and standards

The worst outcome is choosing Backstage without the team to support it. If your platform team is small and needs to show value in weeks, a SaaS portal will usually get there faster. If you have a strong team that wants full control, Backstage’s customization ceiling can be worth the investment.

When comparing costs, put engineering time next to license fees. A self-hosted portal with no license fee is not free if it ties up engineers who could be building golden paths.

Golden paths: paved roads, not walled gardens

A golden path is a pre-built, opinionated and supported way to do a common task: create a service, deploy to production, provision a database, set up observability. The philosophy matters more than the tooling. It should be the easiest option, not the only one. Engineers can leave the path with good reason, but the default should be good enough that most teams don’t want to.

An example of what a service-creation golden path can cover:

// platform-cli: golden path service scaffolding
interface ServiceTemplate {
  name: string;
  runtime: "node" | "go" | "python" | "java";
  tier: "critical" | "standard" | "experimental";
  dataStores: DataStoreConfig[];
  apis: ApiConfig[];
  team: string;
}

interface DataStoreConfig {
  type: "postgres" | "redis" | "dynamodb";
  size: "small" | "medium" | "large";
  highAvailability: boolean;
}

// The golden path generates:
// 1. Git repository with a CI/CD pipeline
// 2. Kubernetes manifests (namespace, deployment, service, autoscaling)
// 3. Database provisioned through the platform's infrastructure layer
// 4. Observability (metrics, logs, traces, alerts)
// 5. Catalog entry
// 6. On-call service and escalation policy
// 7. Security scanning (SAST, dependency and container scanning)
// 8. Load testing baseline

# Developer experience: one command, full service scaffold
$ platform create service \
    --name order-processing \
    --runtime go \
    --tier critical \
    --datastore postgres:medium:ha \
    --datastore redis:small \
    --team checkout \
    --api grpc

Creating service: order-processing
  [OK] GitHub repository created
  [OK] CI/CD pipeline configured (build, test, scan, deploy)
  [OK] Kubernetes namespace and RBAC provisioned
  [OK] PostgreSQL (medium, HA) provisioning initiated
  [OK] Redis (small) provisioning initiated
  [OK] Monitors and dashboards created
  [OK] On-call service linked to team-checkout
  [OK] Catalog entry registered
  [OK] Security scanning pipeline enabled

Teams that do this well treat templates as products, with versions, deprecation policies and upgrade paths. They track how many new services use the templates and ask why the others didn’t. And they involve application developers in designing the templates instead of building in isolation.

A common anti-pattern: golden paths that are technically excellent but ignore how developers work. If using the path means learning a new CLI, a new abstraction and a new deployment model all at once, adoption will be low however good the platform is. Start from the developer experience and work back to the implementation.

Self-service infrastructure: promise and reality

Self-service is the flagship capability. Developers provision what they need when they need it, and the platform enforces guardrails, security policy and cost controls behind the scenes.

In practice most organizations reach partial self-service first. Developers can create dev environments, pipelines and standard components on their own, while production databases, security-sensitive configuration and expensive resources still go through approval. That isn’t a failure. Fully automated provisioning of production databases with no review is not right for every organization. A tiered model makes the trade explicit:

# Example: tiered self-service policy
self_service_tiers:
  # Tier 1: fully automated, no approval
  automatic:
    - dev_namespace_creation
    - ci_cd_pipeline_setup
    - feature_branch_environments
    - non_production_databases (size <= medium)
    - redis_cache_instances
    - s3_buckets (non_public)

  # Tier 2: auto-approved with notification
  auto_approved_notify:
    - staging_deployments
    - non_production_databases (size == large)
    - api_gateway_routes
    - dns_records (internal)

  # Tier 3: single approval (platform team)
  single_approval:
    - production_deployments (first deploy)
    - production_databases
    - public_dns_records
    - third_party_integrations

  # Tier 4: security + platform approval
  dual_approval:
    - public_s3_buckets
    - iam_role_modifications
    - vpc_peering
    - secrets_management_access
    - compliance_scope_changes

Underneath, many Kubernetes-based platforms use Crossplane to expose infrastructure as Kubernetes-native custom resources, while Terraform or OpenTofu still create much of the actual cloud infrastructure. Our comparison of Terraform, OpenTofu and Pulumi covers the provisioning layer.

Self-service portals hide cloud complexity behind intent-based interfaces

Platform teams vs. DevOps teams: the organizational question

This is where platform initiatives succeed or fail. The tooling is the easy part. The hard part is defining responsibilities and managing the relationship between the platform team and the teams it serves.

The model that works treats the platform team as an internal product organization. That means a product owner (or a tech lead who thinks like one) keeping a roadmap based on developer feedback and usage data, running user research, tracking adoption, and deprecating features on purpose. It means clear interfaces: the platform publishes an API, literal or conceptual, and commits to its stability, so application teams don’t need a meeting to use it. And it means a funding story tied to outcomes, such as faster time to production, fewer incidents and better developer satisfaction, because platform teams funded purely as cost centers get squeezed first when budgets tighten.

The pattern that fails is the renamed operations team. If your “platform team” still works from tickets, still provisions by hand, and still defines success as keeping the lights on, it’s a DevOps team with a new name. Nothing is wrong with a DevOps team, but calling it platform engineering sets the wrong expectations on both sides.

Team size is a judgment call. There’s no reliable industry ratio of platform engineers to application developers. Size the team to the number of golden paths and services it has to support well, and grow it when adoption, not ambition, says you need to.

Measuring platform success

Platform engineering is expensive, and the platform team needs to show what it returns.

DORA metrics

DORA’s software delivery metrics are the foundation. DORA now groups five of them: change lead time, deployment frequency and failed deployment recovery time measure throughput, while change fail rate and deployment rework rate measure instability. Our guide to DORA and SPACE metrics covers setting them up. A good platform should move these in the right direction by removing friction from deployment, standardizing pipelines, and building in testing, container security scanning and canary deployments.

Be ready for mixed results. DORA’s 2024 report found that internal developer platform users had 8% higher individual productivity and 10% higher team performance, and that organizational delivery and operations performance rose 6% with a platform. The same research found throughput fell 8% and change stability 14%, which DORA called “a surprising result.” A platform adds a layer that people must learn and that can break. Roll it out gradually, and watch the delivery metrics during the transition rather than only at the end.

Developer experience

DORA metrics capture delivery but miss the human side. Also track:

• Developer satisfaction, through a short regular survey that includes “would you recommend the platform to a colleague?”
• Time to first deploy for a new engineer, a strong proxy for onboarding quality and platform usability.
• Cognitive load: how much infrastructure knowledge a developer needs day to day, approximated through surveys and how often people ask for help.

// Example: platform metrics data model
interface PlatformMetrics {
  dora: {
    deploymentFrequency: { perDay: number; trend: "improving" | "stable" | "declining" };
    changeLeadTime: { medianHours: number; p95Hours: number };
    changeFailRate: { percentage: number; rollingWindow: "30d" | "90d" };
    failedDeploymentRecoveryTime: { medianMinutes: number; p95Minutes: number };
    deploymentReworkRate: { percentage: number };
  };
  developerExperience: {
    satisfactionScore: number;
    timeToFirstDeploy: { medianHours: number; targetHours: number };
    selfServiceCompletionRate: number; // percentage
    ticketVolume: { current: number; trend: "decreasing" | "stable" | "increasing" };
  };
  platformHealth: {
    goldenPathAdoption: number; // share of new services on templates
    templateCoverage: number;
    platformUptime: number;
    pluginMaintenance: { upToDate: number; deprecated: number; unmaintained: number };
  };
}

The platform-specific numbers that matter

1. Self-service completion rate: of requests started through the platform, how many finish without a human stepping in.
2. Golden path adoption: what share of new services use the templates. A low share means the paths are not meeting developer needs.
3. Idea to production time for a new service, end to end.
4. Developer satisfaction trend, quarter over quarter.
5. Ticket deflection: infrastructure support tickets should fall as self-service grows. If they don’t, self-service isn’t working.

Set your own targets from a baseline you measure before the platform launches. Targets copied from someone else’s report tell you little about your organization.

What is clear by now

Platform engineering is a product discipline applied to infrastructure. Organizations that treat it as a rebrand get little from it; organizations that treat it as product development do better.

Build versus buy is a real choice now. When Backstage was the only credible option, building was the default. With mature SaaS portals available, self-hosting needs a reason, such as deep customization or avoiding lock-in, and the engineering time it consumes belongs in the comparison.

Golden paths only work if they are genuinely good. If the paved road has potholes, developers go off-road.

Measurement is not optional. Platform teams that can’t show their impact are first in line for cuts, and DORA’s research is a reminder that the impact is not automatically positive.

And the team matters more than the tool. A modest portal run by people with product instincts and real empathy for developers will beat a technically superior one built by a team that sees developers as users to be told what to do.

If that last point lands, our guide to hiring a platform engineer covers how to screen for those product instincts, rather than hiring an ops generalist and calling it platform engineering.