[opensourcedex]

openchoreo is a free, open source orchestration & scheduling project written in Go and released under Apache-2.0. It has 1,570 GitHub stars, 248 forks and 269 open issues, and was last pushed 8 hours ago. On this registry it ranks #55 of 64 tracked projects in Orchestration & Scheduling, with 5 head-to-head comparisons available. It gained 12 stars over the last 3 tracked days.

What is openchoreo?

What it is

OpenChoreo is an open-source internal developer platform for Kubernetes. It is built for developers, platform engineers, and AI agents that need to build, deploy, and operate applications, resources, and agentic workloads on Kubernetes. The project lives in the Kubernetes ecosystem and is described as a complete developer platform rather than a collection of separate tools.

The concrete problem it addresses is that Kubernetes primitives such as Namespaces, Deployments, CronJobs, Services, and NetworkPolicies are too low-level for most developers. Platform engineers often have to define higher-level abstractions, wire together delivery, security, and observability tools, and then maintain the resulting glue as an in-house product. OpenChoreo aims to provide those abstractions and integrated capabilities so that developers can use a self-service experience while platform engineers retain control over the underlying platform.

Key capabilities

  • OpenChoreo provides a developer platform for Kubernetes that supports building, deploying, and operating applications, resources, and agentic workloads.
  • It includes a Backstage-powered developer portal as part of the platform experience.
  • It includes built-in CI and GitOps capabilities for delivery workflows.
  • It includes observability, RBAC, and analytics among the platform capabilities listed in the README.
  • It provides higher-level abstractions that translate developer intent into Kubernetes platform reality.
  • It is associated with the internal developer platform, platform engineering, DevOps, and MCP topics in its repository metadata.

Who uses it and how

  • Platform engineers use OpenChoreo when they want to avoid assembling and maintaining a bespoke internal developer platform from low-level Kubernetes resources.
  • Developers use it for a self-service experience for building, deploying, and operating applications and resources on Kubernetes.
  • AI agents use it to build, deploy, and operate applications, resources, and agentic workloads.
  • Teams use it to connect developer portals, CI pipelines, GitOps workflows, observability, access controls, and analytics within one platform.
  • Kubernetes platform teams use it when they need control over what runs underneath while exposing simpler abstractions to developers.

Getting started

The provided README excerpt does not list Docker image names, package-manager commands, or a hosted option for installation. It points to https://openchoreo.dev as the project homepage.

When to use it — and when not to

OpenChoreo is a good fit when a team wants an open-source internal developer platform for Kubernetes instead of stitching together a developer portal, CI, GitOps, observability, and access controls by hand. The provided excerpt does not name paid products that it replaces, and it does not specify the database, storage, SMTP, or other self-hosted dependencies that an operator must run. The project is a CNCF Sandbox project with 269 open issues, so teams should verify the current installation and operational details before adopting it.

project readme (upstream, from github) — read inline

A complete, open-source developer platform for Kubernetes

OpenChoreo is a developer platform for Kubernetes that lets developers and AI agents build, deploy, and operate apps, resources, and agentic workloads. It provides development and platform abstractions, a Backstage-powered developer portal, CI/CD, GitOps, and observability.

License FOSSA Status CNCF Sandbox Twitter Follow Slack

OpenSSF Best Practices OpenSSF Scorecard CLOMonitor LFX Health Score

Build and Test E2E Tests Codecov GitHub Release GitHub last commit GitHub issues

Why OpenChoreo?

Kubernetes gives you powerful primitives like Namespaces, Deployments, CronJobs, Services, and NetworkPolicies, but they're too low-level for most developers. Platform engineers end up building the actual platform from scratch: defining higher-level abstractions, wiring together tools for delivery, security and observability, and maintaining all of it as an in-house product.

That means stitching together a developer portal, CI pipelines, GitOps workflows, an observability stack, and access controls and then owning the glue between them indefinitely. The result is a fragile, bespoke system that's expensive to maintain and hard to evolve.

Developers and platform engineers need different things from the same platform. Developers want a simple, self-service experience. Platform engineers want control over what's running underneath. Most DIY platforms end up optimizing for one side at the expense of the other.

What is OpenChoreo?

OpenChoreo, now a CNCF Sandbox project, takes a different approach. Instead of giving you a toolkit to assemble your own platform, it provides a complete, open-source developer platform for Kubernetes with abstractions that translate developer intent into platform reality. So platform engineers don't have to reinvent the wheel, and developers get a self-service experience that stays out of their way.

Under the hood, OpenChoreo brings together a Backstage-powered developer portal, built-in CI and GitOps, observability, RBAC, and analytics and all of them are organized across dedicated control, CI, data, and observability planes. Platform engineers get a production-ready foundation they can operate and extend, not scaffolding they'll eventually replace.

OpenChoreo was originally developed by WSO2, based on its experience building the SaaS internal developer platform formerly known as WSO2 Choreo (now WSO2 Developer Platform), bringing its core ideas to the open-source community. It's not a fork or an open-source dump; it's a complete rewrite based on what we learned from Choreo’s users over the years.

How does OpenChoreo work?

OpenChoreo is built around a multi-plane architecture, where each plane handles a distinct concern and operates independently.


  • The Experience Plane is where developers, platform engineers, and SREs interact with the platform via a Backstage-powered OpenChoreo Portal, CLI, GitOps, or AI agents.

  • The Control Plane sits at the center of OpenChoreo. It takes developer intent and platform intent expressed through high-level abstractions like components, endpoints, dependencies, environments, pipelines, and namespaces and translates them into the underlying Kubernetes resources. It also reflects runtime reality back up, so what developers see always matches what's actually running.

  • The Data Plane is where your workloads run. It is where OpenChoreo enforces and guarantees the semantics of those high-level abstractions, such as isolation between projects, traffic policies, and security boundaries. These aren't just configurations; they're guaranteed by the platform.

  • The Observability Plane feeds the loop with metrics, logs, and tracing, all surfaced through the abstractions your developers already understand.

  • The optional CI Plane handles builds using cloud native Buildpacks and Argo Workflows by default.

At the center of this is a set of opinionated abstractions. Developers work with components (services, workers, cron jobs, and other types defined as component types), expose functionality through endpoints, and declare dependencies on other endpoints or resources. Platform engineers control what component types are available, what traits can be applied, and how workloads behave, through configuration, not custom code.

The result is a clear separation of concerns: developers express what they want to run, the control plane figures out how to run it, and platform engineers govern the boundaries.

Underpinning all of this is the Platform API. It is a set of Kubernetes CRDs that let platform engineers declaratively define the structure and behavior of the entire platform. Instead of writing custom controllers or glue scripts, you configure organizational boundaries, environments, data planes, deployment pipelines, and observability through familiar Kubernetes-native resources. The Platform API also includes programmable abstractions like ComponentTypes, Traits, and Workflows that let platform teams define golden paths for their developers, encapsulate best practices, and enforce organizational standards. Together, they enable OpenChoreo's approach to policy, security, and governance by design.

The diagram below illustrates some of the core concepts of the Platform API and how they relate to each other. It represents one possible platform topology, not a prescribed structure.


Getting Started

The easiest way to try OpenChoreo is by following the Quick Start Guide. It walks you through setting up Choreo using a Dev Container, so you can start experimenting without affecting your local environment.

For a deeper understanding of OpenChoreo's architecture, see OpenChoreo Concepts.

Visit Installation Guide to learn more about installation methods.

Samples

Explore hands-on examples to help you configure and deploy your applications using OpenChoreo.

readme truncated — read the full docs on github

Frequently asked questions

Is openchoreo free to use?

openchoreo is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does openchoreo do?

OpenChoreo is an internal developer platform for Kubernetes

What is openchoreo written in?

openchoreo is primarily written in Go. Its source is publicly available at https://github.com/openchoreo/openchoreo, and it has 1,570 GitHub stars.