OpenChoreo: a CNCF Sandbox developer platform for Kubernetes, not another toolkit

The problem OpenChoreo targets: platform teams rebuilding the same stack

Kubernetes ships Deployments, Services, CronJobs and NetworkPolicies. None of those are a developer experience. The README states the consequence plainly: platform engineers end up building the actual platform from scratch, defining higher-level abstractions and wiring together delivery, security and observability tooling, then maintaining all of it as an in-house product. The result it describes is a fragile, bespoke system that is expensive to maintain and hard to evolve.

The second problem OpenChoreo names is a conflict of interest inside one platform. Developers want a self-service experience. Platform engineers want control over what runs underneath. A DIY stack usually optimizes for one side. OpenChoreo's answer is to ship the whole thing rather than a toolkit, and to split the concerns across planes so each audience gets its own surface. That is a real architectural claim, not a marketing line: the repository carries api/, internal/, pkg/, cmd/, config/ and install/ directories, which is the layout of a Go operator project rather than a collection of Helm charts.

Who it is for, based on the repository contents: platform engineering teams on Kubernetes who want a portal and a delivery pipeline without assembling both. The topics list adds ai-agents and mcp, and the dependency list includes github.com/modelcontextprotocol/go-sdk v1.4.1, so agent workloads are a first-class target rather than an afterthought.

How the multi-plane architecture translates developer intent

OpenChoreo is organized into planes that operate independently. The Experience Plane is where developers, platform engineers and SREs interact, through a Backstage-powered portal, a CLI, GitOps, or AI agents. The Control Plane sits in the middle and converts high-level abstractions (components, endpoints, dependencies, environments, pipelines, namespaces) into Kubernetes resources, then reflects runtime reality back up. The Data Plane is where workloads run, and it is where the platform enforces the semantics of those abstractions: isolation between projects, traffic policies, security boundaries. The Observability Plane supplies metrics, logs and tracing through the same abstractions. An optional CI Plane handles builds with cloud native Buildpacks and Argo Workflows by default.

The mechanism worth noting is the direction of translation. Developers write components, not Deployments. Platform engineers decide which component types exist and which traits can be applied, through configuration rather than custom code. That is the separation of concerns the README claims, and it is the part that determines whether the platform stays maintainable. If component types are configuration, a platform team can add one without shipping Go code. The repository supports that reading: samples/component-types/ and samples/platform-config/ exist as separate sample trees.

The go.mod file shows the implementation shape. sigs.k8s.io/controller-runtime v0.24.1 and k8s.io/api v0.36.3 indicate a controller-based control plane. github.com/casbin/casbin/v2 v2.135.0 covers RBAC. github.com/google/cel-go v0.30.0 suggests CEL expressions in validation or policy. github.com/jackc/pgx/v5 v5.10.0 and modernc.org/sqlite v1.53.0 give two storage backends. github.com/cilium/cilium v1.20.0 is a direct dependency, which is a notable commitment: the data plane leans on Cilium rather than staying neutral about the CNI.

Installing OpenChoreo and running a first sample

The README does not carry an install command, so the honest answer is that installation lives in the repository rather than the front page. The top-level install/ directory and the Makefile are the entry points. The Makefile includes make/kube.mk, make/helm.mk, make/k3d.mk and make/e2e.mk, which tells you the supported path is a Kubernetes cluster plus Helm, with k3d for local work. Running make help lists every target, since the Makefile states all targets are implemented in make/*.mk files.

Start by listing what the build system exposes:

make help

You should see targets grouped by the included .mk files, covering kube, helm, k3d and e2e. From there, samples/local-development/ is the sample tree aimed at a local cluster, and samples/getting-started/ is the first-run walkthrough. The samples directory also contains from-source/ and from-image/, which correspond to the two ways a component can be defined: built from a repository, or deployed from an existing image.

Because the codebase targets Go 1.26.3, building from source requires that toolchain. The Makefile includes make/golang.mk, and that file is where the Go build targets are defined:

make help

The Dockerfile packages the result as a distroless static image running as USER 65532:65532 with ENTRYPOINT ["/manager"], so the control plane container is minimal and non-root by default. If you prefer to run a published image rather than build, the repository's release page is where the tags v1.0.6, v1.1.7 and v1.2.5 live; check CHANGELOG.md for what changed between them before picking one, because those three releases landed within three days of each other and the ordering is not obvious from the numbers alone.

Where OpenChoreo is the wrong tool

The platform is opinionated by design, and that is also its main constraint. If your team already has a working Backstage instance with custom plugins, adopting OpenChoreo means adopting its abstractions on top: components, endpoints, dependencies, environments, pipelines and namespaces. You are not adding a plugin. You are moving your delivery model onto someone else's vocabulary, and the README is explicit that these abstractions are opinionated.

The second constraint is the plane split. Control, data and observability planes are separate concerns, and the CI plane is optional. That structure is what makes the platform operable, and it is also what makes a partial install awkward. A team that wants only the portal, or only the pipeline, gets less value than a team that runs the whole thing, because the abstractions are enforced in the Data Plane and observed in the Observability Plane. Cutting a plane out removes the feedback loop the design depends on.

The third constraint is dependency weight. Cilium v1.20.0 is a direct requirement in go.mod. That is a strong statement about the networking layer, and it means OpenChoreo is not a neutral choice for clusters already standardized on a different CNI. The README does not document a supported alternative, so treat that as unresolved rather than configurable.

Finally, the README does not document rollback, and it does not document an upgrade procedure between the v1.0.x, v1.1.x and v1.2.x lines. For a platform that owns your delivery path, that silence matters more than any feature list.

OpenChoreo compared with assembling Backstage yourself

The obvious alternative is Backstage plus your own pipeline. Backstage gives you the portal and a plugin system; you supply the CI, the GitOps controller, the observability stack and the glue. OpenChoreo uses Backstage for its portal too, so the difference is not the portal. It is everything behind it.

With plain Backstage, the catalog describes services and the deployment mechanism is whatever you wired. With OpenChoreo, the Control Plane translates component definitions into Kubernetes resources and the Data Plane enforces the semantics. That is a different division of labor: in the first case the portal is a view over systems you maintain, in the second the portal is a view over a platform that maintains itself. The trade is flexibility for a working default.

The second alternative is a GitOps-only approach with Argo CD or Flux and no portal at all. That is lighter and stays closer to raw Kubernetes. It also leaves the developer experience problem the README opens with unsolved: developers still face Deployments and Services directly, and platform engineers still write the abstractions by hand. OpenChoreo's CI Plane uses Argo Workflows by default, so choosing OpenChoreo does not mean abandoning Argo; it means Argo becomes one plane among several rather than the whole answer.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-10. Three releases appeared in the days before that: v1.1.7 on 2026-09-08, v1.2.5 on 2026-09-07 and v1.0.6 on 2026-09-09. That pattern is worth reading carefully. A v1.0.6 published after v1.2.5 indicates parallel maintenance lines rather than a single linear release train, which means upgrade cost depends on which line you are on. The repository includes a CHANGELOG.md and a VERSION file at the top level, so the project tracks this, but the README does not describe a supported upgrade path between lines.

The project is a CNCF Sandbox project, and the repository carries governance material: GOVERNANCE.md, MAINTAINERS.md, ADOPTERS.md, CODE_OF_CONDUCT.md and SECURITY.md. The README states OpenChoreo was originally developed by WSO2 based on experience building the SaaS internal developer platform formerly known as WSO2 Choreo, and that this is a complete rewrite rather than a fork. That origin explains the breadth of the plane model, and it also means the design carries assumptions from a hosted product.

The licence is Apache-2.0, declared in the LICENSE file and in the Dockerfile label org.opencontainers.image.license. Apache-2.0 permits commercial use and modification and includes a patent grant. The repository does not state a separate trademark policy in the files listed, so if you plan to use the OpenChoreo name in a product, check GOVERNANCE.md yourself. That is a question for your own counsel, not something this article can settle.

Editorial conclusion

Adopt OpenChoreo if you are a platform team that would otherwise spend a year wiring a portal, CI, GitOps and observability together, and you accept a Go 1.26.3 codebase and an opinionated abstraction set. Do not adopt it if you only need a Kubernetes dashboard with no delivery pipeline, or if you cannot run the control, data and observability planes. Before installing, read samples/getting-started/ and samples/local-development/, confirm which plane each sample deploys, and check the CHANGELOG for the gap between v1.0.6, v1.1.7 and v1.2.5.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openchoreo/openchoreo on GitHub
3. Project website
4. README
5. Releases