OpenChoreo Kubernetes developer platform: the openchoreo/openchoreo repository describes itself as « a complete, open-source developer platform for Kubernetes ». It targets teams that build an internal developer platform (IDP) by gluing together a portal, CI, GitOps and observability. The project is released under the Apache 2.0 licence and, according to its README, belongs to the CNCF Sandbox.
The README states that WSO2 developed OpenChoreo from its experience with the Choreo SaaS platform, and that it is a complete rewrite, not a fork. For an SRE, the appeal comes down to one idea: logs, metrics and traces are surfaced « through the abstractions your developers already understand » (component, project, environment). What does the repository contain, how can it be tried, and what can be monitored?
A note on honesty: span.observer has not installed or run OpenChoreo. The commands and files quoted here come from the README, the repository’s samples/ folder and the official documentation on openchoreo.dev, all read on 5 November 2026. The screenshots below reproduce those texts. The star count could not be re-read at the source that day, so it is not quoted.
OpenChoreo Kubernetes developer platform: what the repository says
- Licence: the LICENSE file is the Apache License 2.0; the README confirms « Apache 2.0 ».
- Version: the
VERSIONfile on the main branch reads1.4.0-m.2, a milestone build. The installation guides in the documentation targetv1.3.3, which is the version used here. - Plane architecture: the README describes an experience plane (Backstage portal, CLI, GitOps, AI agents), a control plane that translates abstractions into Kubernetes resources, a data plane where workloads run, an observability plane and, optionally, a CI plane based on Buildpacks and Argo Workflows.
- Abstractions: developers work with components, endpoints and dependencies; platform teams define component types, traits and workflows through Kubernetes resources (CRDs), with no custom controller.
Another useful point: the documentation groups the ideas into four concept pages: developer abstractions, platform abstractions, runtime model and resource relationships.
Step-by-step installation (local trial)
These steps follow the « on k3d locally » guide in the official documentation. They create a local Kubernetes cluster inside Docker: this is a trial, not a production install.
Step 1: check the prerequisites
The documentation asks for Docker v26 or later (with 8 GB of RAM and 4 CPUs), k3d v5.8 or later, kubectl v1.34 or later and Helm v3.12 or later. It suggests checking them with the four commands in the screenshot below.
Step 2: run the one-command install
The script creates the cluster and installs all four planes. The --with-build option adds the workflow (CI) plane and --with-observability adds the observability plane.
The guide also offers a step-by-step Helm installation to understand each component. A shorter alternative exists: the quick start launches a development container (ghcr.io/openchoreo/quick-start:v1.3.3), then runs ./install.sh --version v1.3.3 inside it; adding --with-build --with-observability works the same way.
Step 3: open the portal
The Backstage portal is served at http://openchoreo.localhost:8080; the Observer answers at http://observer.openchoreo.localhost:11080, and deployed application traffic uses port 19080. The default trial credentials are listed in the documentation: never reuse them outside a local machine.
Service observability: what the documentation describes
The installation guide deploys the observability plane with several Helm charts: a logs module and a tracing module based on OpenSearch, a metrics module based on Prometheus, Fluent Bit to collect logs and an OpenTelemetry collector for Kubernetes events. The events are exported to an OpenSearch index named k8s-events.
The plane is modular. The « tracing adapter API » page explains that the Observer queries an adapter to read traces, spans and span details; the backend is whatever the module provides. That page names no backend other than those in the installation, so do not assume any.
Alerts declared as code
According to the documentation, developers attach an alert rule to a component as a trait (observability-alert-rule). A condition has a window, an interval, an operator (gt, lt, gte, lte, eq) and a threshold. The source is a log pattern or a resource metric; the repository example names cpu_usage and memory_usage.
This example fires a critical alert if more than five occurrences of the error appear within five minutes, evaluated every minute. It is exactly the reasoning of an error-rate SLI; to frame it, see our SLO and SLA learning path.
Notification channels
Alerts leave through one channel per environment, either email (SMTP) or webhook. According to the documentation, the first channel created in an environment becomes the default. The next excerpt comes from the sample file; the webhook address is an example to replace.
A root cause analysis agent
The repository also contains an RCA agent. According to its README, it receives an alert through a REST API, investigates with a ReAct loop through two MCP servers (observability, and OpenChoreo resources) and produces a structured report. Only a set of read-only tools is exposed to it. To judge this kind of agent in production, read the guardrails for AI agents and how to secure an MCP server.
Limits and open questions
- Weight of the stack: a full installation assembles Gateway API, cert-manager, External Secrets, an OpenBao vault, an identity provider, OpenSearch and Prometheus. Plan for operating time, not just installation time.
- Local trial: the documentation examples use default credentials, and the events collector is configured with
insecure_skip_verify: truetowards OpenSearch. These settings do not suit production. - Pace of change: the main branch is a 1.4.0 milestone; the changelog mentions, for example, release lines and secret management for the observability plane. Read the release notes before each upgrade.
- Application instrumentation: we did not read a page describing how an application sends its traces to the observability plane. This point is unverified; check the documentation before promising it to a team.
- Dynatrace: the project documents no Dynatrace integration, and we do not invent one.
Monitoring the platform itself
An internal platform is a service like any other: if the control plane goes down, nobody deploys. OpenChoreo’s documentation describes observability for the deployed workloads; for the platform, you still have to monitor the Kubernetes components that carry it. Here are common-sense pointers, not specific to the project:
- Availability: watch the deployments in the
openchoreo-control-plane,openchoreo-data-planeandopenchoreo-observability-planenamespaces created by the installation, using alerts on pods and quotas. - Metrics: if your cluster already runs Prometheus, see how to connect Prometheus to Dynatrace; the principle holds for any observability backend.
- OpenTelemetry signals: the installation’s events collector is an OpenTelemetry collector; our notes on Collector contrib components help to read this kind of configuration.
Next in the series: Jan, the open source ChatGPT alternative, another project read the same way.
Best practices
- Try it on k3d first with the observability plane, then compare with your current stack before any migration.
- Keep alert rules in Git like other resources, and tie each threshold to an SLO.
- Replace every example credential and secret; use the intended secrets vault rather than plain-text values.
- Pin chart versions, as the documentation does with
--version. - Restrict agents’ MCP tools to read-only, as the repository’s RCA agent does.
Frequently asked questions
Does OpenChoreo replace Backstage?
No: the README describes a « Backstage-powered » portal. OpenChoreo adds the abstractions, control plane, CI, GitOps and observability around that portal.
Do I need to install the observability plane?
It is optional according to the documentation: the --with-observability option adds it. You therefore need to enable it to get the logs, metrics and traces described above.
Which licence, and who maintains the project?
The code is under Apache 2.0. The README states initial development by WSO2 and CNCF Sandbox status; read the repository’s governance page (GOVERNANCE.md) before an enterprise decision.
Conclusion
OpenChoreo offers a complete developer platform for Kubernetes, with built-in observability and alerts declared in YAML. The project looks active, but the installation is heavy and several points remain to be checked in the documentation: application instrumentation and long-term operation. Try it locally, measure what it replaces in your toolchain, then decide.
span.observer is an independent community blog, not affiliated with OpenChoreo, WSO2 or Dynatrace LLC. Brands mentioned belong to their owners. Tools change quickly: check commands and options in their official documentation.
Originally published on span.observer. French version: https://span.observer/fr/openchoreo-plateforme-developpeur-kubernetes/.
Top comments (0)