Backstage vs a managed internal developer platform: what each actually gives you on day one (8 options compared, 2026)

Key points:

• Backstage ships a Software Catalog, Software Templates (the Scaffolder) and TechDocs. It does not build, deploy, provision environments, create databases or upgrade clusters. Its official Kubernetes plugin shows service owners the health of their workloads; it does not control them.
• A managed internal developer platform such as Qovery ships the delivery layer on day one: git-push deployments, a preview environment per pull request, per-environment RBAC, auto-stop for non-production and managed cluster upgrades, running inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster.
• The real decision is portal problem versus delivery problem. If nobody knows who owns which of your 300 services, pick Backstage, Port or Cortex. If developers cannot get an environment without filing a ticket, a portal button has nothing to call.
• Backstage is free software with a staffing bill: monthly upgrades, catalog hygiene, and the Argo CD, Crossplane and Terraform stack behind every self-service action. Below roughly four dedicated platform engineers, buying the delivery layer reaches developers faster.
• The two are complementary. A common mature setup puts Backstage or Port in front as the catalog and a managed platform behind it doing the deploys.

Backstage will not deploy a single container for you, and most teams I talk to find that out about six months in. Backstage solves discovery, ownership and standardisation. A small platform team that adopts it hoping for Kubernetes self-service ends up building the delivery layer itself, on top of running the portal.

I run Qovery, a delivery platform, so read this with that bias in mind. I score Qovery on the same criteria as everyone else and I name the cases where another option wins. All pricing, plugin counts and adopter counts below were checked on November 4, 2026.

What is Backstage, and why can it not deploy your application?

Backstage is an open-source framework for building developer portals, made of a Software Catalog, Software Templates, TechDocs and a plugin system. It contains no build system, no continuous delivery engine and no environment provisioner, so every deploy behind a Backstage button is automation your team builds, wires and maintains.

Spotify's own documentation says it plainly: "Backstage is an open source framework for building developer portals" (Backstage docs). The core pieces are:

• Software Catalog for "managing all your software", fed by catalog-info.yaml entity files in each repository.
• Software Templates (the Scaffolder) for "quickly spinning up new projects": they create a repo, fill in boilerplate and open a pull request.
• TechDocs for documentation using a "docs like code" approach.
• Plugins, which is where everything else comes from.

The official Kubernetes plugin is observability. The docs describe it as "designed around the needs of service owners, not cluster admins", so developers "can easily check the health of their services" (Backstage Kubernetes docs). It shows pods and errors. It does not roll anything out.

Credit where due: Backstage has around 34,700 GitHub stars (GitHub), close to 300 organisations in its public ADOPTERS.md, and more than 260 active plugins in its plugin directory. It is a CNCF project at the Incubating maturity level since March 15, 2022 (CNCF). My criticism is about scope; the engineering quality is excellent.

The vocabulary causes half the confusion. A developer portal is the interface; an internal developer platform is the machinery underneath. The CNCF Platform Engineering Maturity Model draws the same line: capabilities are the building blocks, and interfaces, including "graphical portals as well as automatable APIs", are how users reach them. Backstage is an interface.

What does Kubernetes self-service actually mean for a small platform team?

Kubernetes self-service means a developer can create, deploy, preview and destroy a full environment without filing a ticket or editing a Helm values file, while the platform team stays out of the critical path. Most Backstage installations stop at the catalog, because getting past it is a separate, open-ended build project.

I use five testable capabilities as the bar:

1. Deploy from git, with no YAML edits by the developer.
2. An ephemeral preview environment per pull request.
3. Self-service databases.
4. Per-environment RBAC, so a developer can own staging without touching production.
5. Safe teardown or auto-stop of non-production.

The one-question diagnostic: is there a Slack channel where developers ask someone for a staging environment? If yes, you have a delivery problem, and a catalog will not fix it. Developers feel this: 32.3% of professional developers in the Stack Overflow 2024 Developer Survey list the complexity of the deployment tech stack as a frustration at work.

Then there is the cost nobody budgets. Kubernetes ships about three minor releases a year (Kubernetes release cycle), and each gets roughly 12 months of patch support (Kubernetes releases). The version skew policy says kube-apiserver must "not skip minor versions when upgrading", so the upgrade treadmill, plus node rotation and CNI, CSI and controller churn, never stops.

Platforms pay off when they are done well. The DORA 2024 report found internal developer platforms raise individual productivity and team performance, but also that they "can also lead to decreased change stability and throughput" without a focus on developer independence. The CNCF model's four levels (Provisional, Operational, Scalable, Optimizing) help you place your own team honestly.

"We will build it on Crossplane" usually means quarters of composition work before a developer sees anything, and a fragile system when the engineer who wrote those compositions leaves. My heuristic, from conversations with CTOs rather than any study: below roughly four dedicated platform engineers, buy the delivery layer and build only what differentiates you.

How should you compare internal developer platforms? (six criteria)

Six criteria decide whether a small platform team gets self-service or a second full-time job: where workloads run, who operates Kubernetes, what works on day one, the headcount required, the pricing model, and whether the product covers delivery, portal or both.

1. Where workloads run. Your own cloud account (BYOC) or the vendor's infrastructure. This decides data residency, egress costs, and whether your AWS Savings Plans or GCP committed-use discounts stay in your name.
2. Who operates Kubernetes. You, the vendor, or nobody because there is no Kubernetes underneath.
3. Day-one capabilities versus assembly. Deploys, preview environments per PR, databases, RBAC and rollbacks, or a kit of parts.
4. Platform headcount needed to run it in production, upgrades included.
5. Pricing model: per seat, per cluster, per resource, or free software plus a staffing bill.
6. Scope: delivery (deploy and run), portal (catalog, ownership, scorecards), or both.

Which internal developer platform fits which team? (2026 comparison table)

For a one-to-three person platform team that needs Kubernetes self-service this quarter, a managed IDP that deploys into your own cloud account is the shortest path; Backstage, Port and Cortex win when the bottleneck is service discovery, ownership and standards.

Decision rule:

• Delivery problem (developers wait for environments): buy a delivery platform first.
• Portal problem (nobody knows who owns what): Backstage, Port or Cortex.
• Both: portal in front, delivery platform behind it, connected by API.

Pricing checked on vendor pricing pages on November 4, 2026.

When is building your own portal on Backstage still the right call?

Backstage is the right pick when nobody knows who owns what across hundreds of services, you want full control of the data model with no per-seat licence, and you can staff at least two engineers to run the portal as a product. Do not pick it if your real bottleneck is that developers cannot get a Kubernetes environment.

The strengths are real: a large plugin ecosystem, a long adopter list, an open data model and the ability to extend into any internal system you already run.

The costs are just as real. Main releases ship monthly, "on the Tuesday before the third Wednesday of each month", and high or critical vulnerabilities are backported only "for the last 6 months if feasible" (Backstage versioning policy). Fall behind and you lose security fixes. Catalog entities rot within weeks of a reorg unless someone owns them, and every self-service action calls automation you have to build first.

Spotify Portal for Backstage is the commercial route: no-code onboarding wizards plus Insights, Soundcheck, RBAC and Skill Exchange. It removes assembly work. It does not add a deploy engine.

The proof that the deploy layer is always external sits in the plugin directory itself: Argo CD, Flux, Jenkins and GitHub Actions are all community or third-party plugins, and the directory notes they "haven't been fully vetted by the core Backstage team" (Backstage plugins).

Are Port and Cortex a faster Backstage for a small team?

Port and Cortex deliver the Backstage outcomes (catalog, ownership, scorecards, self-service actions) as configurable SaaS, which removes portal maintenance but leaves the deployment layer exactly where it was: with you.

Port has a flexible no-code data model, dashboards, scorecards and self-service actions that trigger pipelines you already have. It is the fastest route to a working portal, and its free tier covers up to 5 seats (Port pricing).

Cortex is strongest on service maturity scorecards, production readiness checks and ownership enforcement, so it fits standards-driven engineering organisations. It prices per seat on a custom quote (Cortex pricing).

Both orchestrate existing automation. With no Kubernetes automation underneath, the self-service action has nothing to call. A three-person team with no CD platform yet should buy delivery first and a portal second.

Humanitec, Northflank or a DIY stack: who ends up operating your clusters?

Delivery-first platforms actually ship workloads, and they split on one question: do your applications run in your own cloud account on clusters someone else keeps healthy, or on the vendor's infrastructure?

Humanitec calls its Platform Orchestrator "a graph-based backend for your IDP" and says it is "made by platform engineers, for platform engineers" (Humanitec). Setup starts with "Connect your existing Terraform or OpenTofu modules" and "Add rules for who can use what, and where." That model rewards platform headcount rather than replacing it, which makes it a strong fit for large multi-team standardisation programmes.

Northflank has strong developer UX and runs either on Northflank's cloud or in your own AWS, GCP, Azure, Oracle or CoreWeave account, where it "provisions and manages Kubernetes clusters" (Northflank BYOC). It suits teams comfortable with a vendor-run control plane.

Score is a CNCF sandbox project that describes itself as a "developer-centric and platform-agnostic workload specification", with score-compose and score-k8s reference implementations. It is a useful abstraction and a lock-in hedge whichever platform you choose.

The DIY Argo CD + Crossplane + Terraform stack still wins for air-gapped environments, strict compliance boundaries, unusual topologies, or a platform team that already has the headcount. For scale, the median US DevOps engineer earns $153,000 in total compensation before overhead (Levels.fyi), and a DIY platform needs several.

To be explicit about who beats Qovery where: Humanitec for large standardisation programmes, Northflank for teams happy on vendor infrastructure, Backstage, Port or Cortex for catalog, ownership and scorecards, and DIY for air-gapped or unusual compliance setups.

Where does Qovery fit, and when should you not pick it?

Qovery is the pick when a small team needs Kubernetes self-service running in weeks inside its own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, without hiring a DevOps engineer to build and operate the delivery layer. It is not the pick if what you need is a service catalog, an ownership graph and maturity scorecards across 400 microservices.

What works on day one:

• Git-push deployments from your repository.
• A preview environment per pull request, with app, database and unique URL.
• Environment auto-stop for non-production through Deployment Rules, for example stopping dev and staging outside business hours.
• Per-environment RBAC (Members & RBAC).
• Managed cluster upgrades on Qovery-managed EKS, GKE, AKS and Kapsule.
• Databases backed by managed cloud services, or containers for non-production.

Workloads, data and the cloud bill stay in your account, and so do your Savings Plans and committed-use discounts. If you already run Kubernetes, you can connect your existing cluster instead (BYOK docs).

The combination pattern is concrete: Backstage or Port is where developers start, and its self-service action calls the Qovery API to create and deploy the environment. Qovery is a delivery platform; it is not a service catalog, a scorecard engine or an ownership-governance product.

How do I set up Kubernetes self-service with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to create a cluster and deploy your first application. The agent proposes each step and waits for your approval before anything touches your cloud account.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to a single repository
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want the agent to change things (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills split the work: qovery-onboard sets up your organisation and cluster, qovery-deploy takes code to a running app, qovery-preview creates a preview environment per PR, and qovery-troubleshoot, qovery-optimize, qovery-speedup and qovery-terraform handle diagnosis, cost, build speed and infrastructure as code.

Then ask, for example: "deploy this service to my GCP account with Qovery and give me a preview environment on every pull request". See the AI agent quickstart and the Claude Code integration.