Go to home page
CONTACT
Engineering Platform Logo
For Backstage Teams

Your Portal Is Ready. Now Build the Platform Behind It.

Backstage gives developers a great experience layer. OpenChoreo adds the platform behind it, turning developer actions into governed, production-ready workloads across your Kubernetes environments.

Take Maturity Assessment     Book a Free PoC
The Problem Statement

The hard part starts after the catalog

You invested in Backstage, and it delivered. But as developers start asking harder questions,
the limitations of a portal without a platform underneath it become clear.

"I see my service in the catalog, but is it actually running?"

You wire up the Kubernetes plugin. Then the CI plugin. Then observability links. Each new question means new glue code.

"The portal shows me what exists, but the moment I need to change anything, I'm back in Kubernetes."

Backstage surfaces your services, but it doesn't abstract away the infrastructure, exposing Kubernetes complexity to developers.

"Our golden paths are documented but not enforced."

Backstage templates encode best practices at scaffolding time. After that first commit, there's nothing preventing teams from drifting off the path.

"We spend more time maintaining integrations than building features."

The "messy middle" (a web of point-to-point connections between Backstage, CI/CD, GitOps, and Kubernetes) is fragile, expensive to maintain, and hard to evolve.

The Path Forward

The three stages of Backstage maturity

STEP 1

Just a Catalog: Service Discovery

Services are registered. Docs and ownership are centralized. It's far better than tribal knowledge, but it's still read-only. Developers look things up; they don't act from here.

STEP 2

An Interactive Map: Live Visibility

Plugins surface live Kubernetes status, recent deployments, CI/CD results. Developers can see what's running in Kubernetes, but the moment they need to act on it, the complexity leaks through.

STEP 3

An Actionable Platform: Self-Service Execution

A runtime sits beneath Backstage. Developers deploy, promote, and configure from the portal. Golden paths are enforced at the infrastructure level. Runtime state flows back automatically.

OpenChoreo is the runtime that bridges Stage 1 and Stage 3, adding the missing execution layer beneath your Backstage portal. No rip-and-replace. It's designed to plug directly into your existing catalog.

Read the Docs
How It Works

From point-to-point integrations to a platform architecture

Most Backstage deployments grow organically. Each new capability wired in manually, one integration at a time. OpenChoreo replaces that with a layered architecture that scales.

1

Start with Backstage

You adopt Backstage as your developer portal. Teams register services, docs get centralized, then the requests come in. CI status, live Kubernetes health, observability links. Each answer becomes a new point-to-point integration. This is the messy middle.

2

Add a control plane

Instead of wiring Backstage to every tool, a control plane sits between your portal and your infrastructure. Developers and platform engineers work with high-level abstractions; the control plane compiles these into Kubernetes config and feeds runtime state back into Backstage automatically.

3

Organize your runtime

Behind the control plane, your runtime separates into purpose-built planes: the Workflow Plane for CI/CD, the Data Plane for running workloads, and the Observability Plane for logs, metrics, and traces — all scoped back to each component in Backstage.

Learn More About OpenChoreo
Platform Maturity Assessment

Where does your
Backstage deployment stand?

Answer 9 questions to find out whether you're running a catalog, an interactive map,
or a true actionable platform, and what it would take to close the gap.


Assessment progress Question 1 of 9
Discovery & Visibility
How do developers in your organization find information about services — who owns them, what APIs they expose, whether they're healthy?
A
They search wikis, Confluence, or Slack, or ask whoever seems to know.
B
We have a Backstage catalog with service descriptions, ownership, and docs. It's kept reasonably up to date.
C
Backstage shows live Kubernetes status and recent CI/CD results alongside catalog entries, via plugins we've configured.
D
Backstage shows real-time health, active deployments, logs, and traces per component and environment. No context-switching required.
Service Creation
When a developer needs to create a new service or component, what does that process look like?
A
They copy an existing repo and set things up manually, or follow a step-by-step runbook.
B
We have Backstage scaffolding templates that generate a repo with the right structure and an initial Backstage entity.
C
Templates generate a repo plus CI/CD pipeline configuration and Kubernetes manifests, encoding our org's best practices.
D
A self-service flow scaffolds the repo and automatically provisions a running dev environment. No separate steps required.
Deployment & Promotion
When a developer has changes ready to ship, how do deployments to staging and production happen?
A
They follow a runbook, raise a ticket, or coordinate with the ops team to get a deployment done.
B
They trigger a CI/CD pipeline. Deployments are automated, but the developer must manage it themselves outside Backstage.
C
GitOps handles deployments; Backstage shows deployment state and history via a plugin, though managing environments still requires direct config changes.
D
Developers can promote builds across environments directly from the portal. Policies and guardrails are automatically enforced at each promotion gate.
Observability
When a developer needs to debug a production issue for their service, where do they go for logs, metrics, and traces?
A
They open Grafana, Datadog, CloudWatch, or whatever the team set up — separately from any developer portal.
B
Backstage has links to the relevant dashboards for each component, so at least the starting point is centralized.
C
Backstage shows embedded metrics and logs directly on the component page, via plugins we've configured for each observability tool.
D
Observability is automatically scoped to each component and environment. No configuration needed. Logs, metrics, and traces are part of the component view.
Golden Paths & Standards
How are your organization's platform standards (security policies, resource limits, network rules) enforced after a service is first created?
A
They're documented in a wiki and checked during code review. Compliance depends on individual discipline.
B
Backstage templates encode standards at scaffolding time, but once the repo exists, enforcement is up to CI checks and manual review.
C
CI/CD checks and admission controllers enforce some standards on every deployment, with alerts when things drift.
D
A control plane compiles our standards into every deployment automatically. Drift is detected and corrected continuously. Standards are invariants, not guidelines.
Environment Management
How does your organization define and manage environments (dev, staging, production) and promote workloads between them?
A
Each team manages their own environment configurations. There's no consistent standard across the organization.
B
We have documented standards for environments, and most teams follow them with some variation.
C
Environments are defined as Infrastructure as Code and mostly consistent. Promotions still involve manual steps or separate pipeline triggers.
D
Environments are platform primitives. Developers declare intent; the platform handles the how, including policy enforcement at each promotion gate.
Catalog Accuracy
How accurately does your Backstage catalog reflect what's actually running in your infrastructure right now?
A
It's largely manual and often stale. We rely on teams to keep their catalog entries updated.
B
We have auto-discovery from repos, so the catalog stays reasonably current, though runtime state isn't reflected.
C
Kubernetes and CI plugins pull live state into Backstage, so the catalog is a decent view of what's running. Though some gaps remain.
D
A control plane continuously reconciles declared vs. actual state and feeds runtime data back into Backstage. The catalog is always a live, accurate representation.
Platform Team Overhead
How much of your platform team's time goes toward maintaining integrations — wiring Backstage to CI/CD, Kubernetes, observability tools, and GitOps?
A
Most of our time. Every new capability means writing custom glue code, and maintaining existing integrations is a constant burden.
B
A significant chunk. We maintain several plugin configurations and custom integrations that regularly need updates.
C
Some. We've standardized on a few core integrations, but new feature requests often still require custom work.
D
Very little. A control plane handles the integration layer. Our team focuses on capabilities and developer experience, not plumbing.
AI & Agent Readiness
When your team thinks about AI agents interacting with your platform (triggering deployments, reasoning about incidents, querying service dependencies), how ready is your current setup?
A
We haven't thought about it yet. There's no clear structure for agents to act on our infrastructure.
B
Developers use AI coding assistants, but agents can't interact with our infrastructure or Backstage catalog directly.
C
We're exploring how agents could query our catalog or trigger CI/CD via existing APIs, but there's no structured interface or defined set of agent capabilities yet.
D
Our platform exposes MCP servers or agent skills. AI agents can create components, trigger deployments, and reason about service dependencies as first-class participants.
📋 Level 1

Result: Just a Catalog

Your Backstage deployment is doing exactly what it was designed for — centralizing service discovery and reducing tribal knowledge. That's real value. But right now it's primarily a reference tool, not a platform. Developers look things up here; they don't act from here.

Your highest-impact next steps
Instrument your existing CI/CD pipelines and K8s clusters to feed live state back into Backstage — even basic plugin integrations will dramatically improve your catalog's usefulness.
Build Backstage scaffolding templates that encode your org's standards at service creation time — this is the fastest way to establish consistent golden paths.
Consider what a control plane layer would give you — OpenChoreo can add a complete execution layer beneath Backstage without replacing any of your existing catalog work.
Book a 1-Week Free PoC     Explore OpenChoreo
🗺️ Level 2

Result: An Interactive Map

You've moved beyond a static catalog — your Backstage portal surfaces live data and gives developers a meaningful window into what's running. But it's still a map: it shows you where things are, not a platform that lets you act on them. The gap between visibility and execution is where most teams get stuck.

How to bridge the gap to an Actionable Platform
Identify the "messy middle" in your current setup — the point-to-point integrations that need constant maintenance. A control plane replaces this entire layer.
Move from golden paths as templates to golden paths as platform invariants — enforced at the infrastructure level, not just at scaffolding time.
Add self-service deployment and promotion flows so developers can act from Backstage, not just observe from it. OpenChoreo makes this possible without rebuilding your existing portal.
Book a 1-Week Free PoC     Explore OpenChoreo
Level 3

Result: An Actionable Platform

You're operating at the leading edge. Your Backstage deployment has a real execution layer beneath it — self-service deployments, enforced golden paths, runtime state flowing back automatically. Now the question is what you build on top of it.

What comes next at this level

Your platform is already AI-ready — activate it. If you're not already exposing MCP servers or agent skills, this is your highest-leverage next move.
Deploy built-in agents as platform capabilities — an SRE agent for root cause analysis, FinOps agents for cost visibility, and Architect agents for dependency and impact analysis.
Treat the platform as a product. Measure adoption, DORA metrics, and developer satisfaction — and publish a roadmap so your internal users know what's coming.
Explore OpenChoreo on GitHub     Talk to Our Architects
Backstage and OpenChoreo

What changes when you add a runtime.

OpenChoreo doesn't replace Backstage; it gives it an engine.

CI/CD and GitOps, built in

  1. Stop wiring pipelines to clusters. OpenChoreo handles the full path from source code to production, with Backstage showing the result, not just a link to another tool.

Observability wired to your catalog

  1. Logs, metrics, and traces appear scoped to each Backstage component and environment. Developers get the full picture via a single pane of glass, with no configuration required.

Golden paths that stay golden

  1. OpenChoreo enforces relationships between components and environments at the infrastructure level. Standards aren't just documented, they're compiled into every deployment.

Zero rip-and-replace

  1. OpenChoreo integrates with your existing Backstage catalog and the tools already registered in it. Your current investments stay intact; the runtime fills the gap.

AI agents as first-class platform participants

  1. When your platform has well-defined abstractions and a control plane, AI agents can interact with it just like developers do: creating components, triggering deployments, querying service dependencies, and surfacing root causes via MCP servers and agent skills. Good platform architecture is what makes AI actually useful in your infrastructure.

OpenChoreo is a CNCF Sandbox project. It is an open-source developer platform for Kubernetes with an active contributor community. The architecture described here is also documented in the CNCF Platform Engineering Maturity Model.

1-Week Quick Start

See it working in your environment, free

Day 1–2

Onboard sample services: We work with your team to connect a set of real services to OpenChoreo, demonstrating a complete code-to-cloud flow in your environment.

Day 2–3

Populate Backstage natively: Watch those services automatically appear in your Backstage portal with live logs, metrics, GitOps state, and deployment history, no manual wiring.

Day 3–4

Validate golden paths: Test our architectural abstractions and see how they eliminate the need for glue code while enforcing your org's standards at the infrastructure level.

Day 4–5

Expert debrief & roadmap: Our platform architects walk you through findings, answer your team's questions, and co-design a migration path that respects your existing toolchain.

Claim Your Free 1-Week Quick Start

No commitment. No rip-and-replace. Runs in your own environment.