OpenChoreo: a multi-plane developer platform for Kubernetes
OpenChoreo is an internal developer platform for Kubernetes
At a glance
- What is it?
- OpenChoreo packages a developer portal, GitOps delivery, CI, and observability into one CNCF Sandbox project instead of a toolkit you assemble. The trade-off is that you adopt its planes and its abstractions together.
- Who is it for?
- Adopt OpenChoreo if you are a platform team that would otherwise spend a year wiring a portal, GitOps, CI and observability together, and you accept its component and endpoint abstractions as the developer contract. Do not adopt it if you only need a deployment controller, or if you cannot run the control, data and observability planes as separate concerns.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenChoreo fills for platform teams
The README states the problem directly: Kubernetes primitives such as Namespaces, Deployments, CronJobs, Services and NetworkPolicies are too low-level for most developers, so platform engineers build the platform itself. That means assembling a developer portal, CI pipelines, GitOps workflows, an observability stack and access controls, then owning the glue between them. The README calls the result a fragile, bespoke system that is expensive to maintain.
OpenChoreo's answer is to ship the platform rather than the parts. It is aimed at two audiences at once. Developers get a self-service surface through a Backstage-powered portal, a CLI, GitOps or AI agents. Platform engineers get control over what component types exist, which traits can be attached, and how workloads behave, expressed as configuration rather than custom code. The README frames the split as developer intent versus platform intent, both translated by the same control plane. If your team already has a portal and a delivery pipeline that people like, the value proposition weakens considerably.
Five planes and where the control plane sits
The architecture is described as multi-plane, with each plane handling a distinct concern and operating independently. The Experience Plane is the human and agent entry point: the OpenChoreo Portal, the CLI, GitOps, or AI agents. The Control Plane is the centre. It accepts high-level abstractions such as components, endpoints, dependencies, environments, pipelines and namespaces, and translates them into Kubernetes resources. The README adds a detail worth noting: the control plane also reflects runtime reality back up, so what developers see matches what is running.
The Data Plane is where workloads execute, and it is where the platform enforces semantics such as isolation between projects, traffic policies and security boundaries. The README is explicit that these are guaranteed by the platform rather than merely configured. The Observability Plane supplies metrics, logs and tracing through the same abstractions developers already use. The CI Plane is optional and handles builds using cloud native Buildpacks and Argo Workflows by default. The word optional is doing real work there: a team with an existing build system can plausibly run without it, though the README does not spell out what breaks when you do.
Components, endpoints and the abstractions developers actually touch
The abstractions are the product. Developers work with components, which the README describes as services, workers, cron jobs and other types defined as component types. Components expose functionality through endpoints and declare dependencies on other endpoints or resources. Platform engineers decide which component types are available and which traits can be applied.
This is a real constraint, not a convenience. If your application does not map cleanly onto a component plus endpoints plus dependencies, the abstraction will fight you, and the README offers no escape hatch beyond defining a new component type. The benefit is that isolation, traffic policy and security boundaries become properties of the platform rather than per-team configuration, which is the opposite of how most DIY setups end up. Whether that is worth it depends on how much of your estate is conventional service-shaped workloads. A stateful system with unusual networking is the case where the abstraction is most likely to chafe.
Getting it running and what the README does not give you
This is the weakest part of the supplied material. The README describes the portal, CLI, GitOps flow and the CI Plane's use of Buildpacks and Argo Workflows, but the excerpt contains no install commands, no Helm chart names, no CRD names and no configuration keys. The homepage is listed as openchoreo.dev, and that is where a reader should go for the actual install path. I cannot state a working command sequence from what is here, and I will not invent one.
What can be said is structural. Because the CI Plane is optional and the planes are described as operating independently, an installation is likely to be a set of plane deployments rather than a single chart, but the README does not confirm that. Treat the documentation site, not this review, as the source for cluster prerequisites and version pinning. The release cadence visible in the repository is busy, with v1.0.6, v1.1.7 and v1.2.5 published within three days of each other in September 2026. Three parallel minor lines is a pattern worth understanding before you pin a version, because it suggests either active backporting or a rapid release train, and the README does not explain which.
The cost of adopting a platform rather than a toolkit
The README is candid that OpenChoreo is not scaffolding you eventually replace. It is a production-ready foundation you operate and extend. That framing has consequences. A toolkit lets you adopt one piece and leave the rest; a platform asks you to accept its planes, its portal and its abstractions together. The observability plane surfaces metrics, logs and tracing through OpenChoreo's abstractions, which is convenient until you want the raw query interface your SREs already know.
The project's provenance cuts both ways. It was originally developed by WSO2, based on experience building the SaaS platform formerly known as WSO2 Choreo, and the README insists it is a complete rewrite rather than a fork or an open-source dump. That claim is about intent, not maturity. A rewrite that is roughly a year into public releases, with three minor versions shipping in the same week, is still a moving target. Plan for upgrade work between minor lines, and check the release notes for each line before you move. The Apache-2.0 licence is permissive and carries no copyleft obligation on your own code, but it also comes with no warranty, and this review is not legal advice.
Where OpenChoreo is the wrong tool
If you need a deployment controller and nothing else, OpenChoreo is too much. Argo CD or Flux will reconcile your manifests without asking you to model components, endpoints and dependencies first. The same applies if your developers are already comfortable with raw Kubernetes and your platform team is small: the abstraction layer adds a vocabulary that someone has to maintain, and the README's own framing assumes platform engineers who want to define component types rather than write YAML.
A second failure mode is organisational rather than technical. OpenChoreo assumes a separation between developer intent and platform intent, with platform engineers controlling the catalogue. Teams without that split, where everyone edits everything, will find the control plane's mediation more annoying than useful. The README does not describe an override path for developers who need to bypass an abstraction, and it does not discuss what happens when a workload genuinely cannot be expressed as a component. That silence is the thing to probe hardest before adopting.
How this differs from assembling Backstage plus Argo yourself
The obvious alternative is the DIY stack the README describes: Backstage for the portal, Argo CD or Flux for GitOps, Argo Workflows for CI, and Prometheus with an OpenTelemetry collector for observability. OpenChoreo uses Backstage for its portal and Argo Workflows for its CI Plane, so the components overlap heavily.
The difference is the control plane in the middle. In a DIY stack, the portal is a catalogue and the delivery tools act on manifests; nothing translates developer intent into platform-enforced semantics. OpenChoreo inserts a layer that both translates intent downward and reflects runtime state upward, and it pushes guarantees such as project isolation and traffic policy into the data plane. That is a genuine architectural difference, not a packaging one. The cost is that you inherit OpenChoreo's abstraction vocabulary and its release cadence instead of choosing your own. A team that has already standardised on Backstage software templates and Argo CD ApplicationSets has most of the surface area and none of the lock-in to a single control plane.
Editorial conclusion
Adopt OpenChoreo if you are a platform team that would otherwise spend a year wiring a portal, GitOps, CI and observability together, and you accept its component and endpoint abstractions as the developer contract. Do not adopt it if you only need a deployment controller, or if you cannot run the control, data and observability planes as separate concerns. Before committing, verify the current plane topology and the CLI install path against the docs at openchoreo.dev, since the README describes a rewrite that is still moving.
Community notes