Announcing OpenChoreo v1.3
We're pleased to announce the release of OpenChoreo v1.3. This release brings exciting new capabilities that combine our existing developer and platform APIs to do more across your internal developer platform.
Key highlights include cost usage, analytics and optimizations powered by the new cost insights feature, DORA metrics powered by a new delivery insights feature, a faster local development experience, platform logs for OpenChoreo system components, and a new module for emitting and collecting audit logs across the platform.
This release also includes several other features and quality-of-life improvements shaped by feedback and contributions from our growing community of platform builders.
What’s new in OpenChoreo v1.3.x​
Cost insights dashboards, MCPs and one-click optimizations​
OpenChoreo now provides cost and usage analytics dashboards across your internal developer platform, from namespaces and projects down to individual components.
Building on the FinOps foundations introduced in previous releases, the cost insights dashboard helps teams understand current and historical infrastructure costs, forecast future usage, and apply resource optimization recommendations based on historical usage trends.
Cost analytics are provided through the FinOps ecosystem module built on OpenCost and Prometheus. Once installed and enabled, cost insights are available through the OpenChoreo Portal and can also be accessed by AI agents using OpenChoreo’s MCP servers.
Enable cost insights in OpenChoreo ↗
Delivery and stability insights dashboards and MCPs with DORA metrics (alpha)​
OpenChoreo v1.3 introduces delivery and stability insights as an alpha feature, enabling teams to measure software delivery performance and stability at the component, project, and namespace levels across environments.
The release supports built-in metric publishing and aggregation, with a dashboard for visualizing four DORA metrics:
- Deployment frequency: how often code is deployed to production.
- Lead time for changes: the time from code commit to deployment.
- Change failure rate: the percentage of changes that fail in production.
- Mean time to recovery (MTTR): the time required to recover from a failed deployment.
This information can also be queried via AI agents using OpenChoreo’s MCP servers.
Learn more about enabling delivery insights for your internal developer platform ↗
Faster local development with remote dependency tunneling​
OpenChoreo v1.3 shortens the inner development loop for developers and AI coding agents by allowing them to run and test code locally against dependencies already deployed in a remote environment, without committing, building, and deploying every change first.
When a developer runs $ occ remote, the CLI reads the local workload definition (yaml) to identify the services and resources it depends on in the selected environment. It connects the local application process to those dependencies through local ports and opens a subshell with the required environment variables. Configuration and credentials published by dependencies can also be made available as environment variables or temporary local files.
This brings dependency tunneling and local configuration into one workflow, avoiding the manual setup required with an alternative such as kubectl port-forward for every remote service.
A component does not need to have been deployed before using occ remote, so developers can also test a component locally prior to its first deployment.
Audit logs (beta)​
OpenChoreo v1.3 introduces a new audit logs module as a beta feature, enabling platform teams to track state-changing operations across the platform.
The module provides a standard event format, a dedicated audit log stream, and pluggable publishing, with permission-controlled access to audit records via the OpenChoreo Portal, CLI (occ auditlogs), and MCP servers for agentic access.
More on audit logging in OpenChoreo ↗
Platform logs: Observability for OpenChoreo system components​
Platform teams can now access logs for OpenChoreo's own system components across all planes through an existing observability plane setup.
This extends observability beyond user applications to the platform itself, allowing operators to investigate the state of OpenChoreo’s system components without manually collecting logs through kubectl on each cluster.
OpenChoreo v1.3 covers platform logs, with metrics and Kubernetes events planned to follow in upcoming releases.
Learn more about platform logs ↗
Expanded Kubernetes resource trees for ComponentReleases​
Previously, the OpenChoreo Portal displayed a hardcoded resource tree for known workload types such as Deployments under Component > Deploy > "View K8s Resources". The tree could not discover additional child resources generated by external Kubernetes controllers.
OpenChoreo v1.3 introduces declarative discovery rules that platform teams can configure to include these child resources in the tree. This gives developers a more complete view of the Kubernetes resources created by their component releases, including those generated from custom resources (CRs) defined in a ComponentType.
The custom ComponentTypes provided by the Agent-Sandbox module serve as examples of how to use these rules to extend the resource tree for workloads managed via external controllers.
Learn more about configuring resource tree rules ↗
Namespace-level cell diagrams​
OpenChoreo now renders cell diagrams at the namespace level, providing visibility for component and resource interactions that span many projects within a namespace.
An expanded library of Traits with field extensions for building better UIs​
OpenChoreo v1.3 ships with an expanded library of common Traits for reusable capabilities such as autoscaling, health checks, and storage, with sensible defaults.
Trait authors can now use vendor extensions in the OpenAPI schema to configure Backstage Field Extensions. This gives authors more control over how Trait configuration forms are rendered for developers in the OpenChoreo Portal. The updated Traits library also uses these field extensions to provide improved configuration form designs.
We expect to expand this collection of Traits with more sensible defaults and additional reference examples in upcoming releases.
See the new Traits on GitHub ↗
Improvements to the Backstage-powered OpenChoreo Portal​
Migration to Backstage’s new frontend system​
The OpenChoreo Portal and its plugin suite now use Backstage's new Frontend System. This makes it easier for teams to customize the Portal or integrate OpenChoreo features into an existing Backstage installation.
Entity pages, cards, forms, and other UI elements are now provided as extensions through the published @openchoreo/* packages. Teams using the new frontend system can install these packages and use Backstage's extension configuration to compose the developer portal interface, reducing the custom frontend code needed to integrate OpenChoreo.
Backstage plugins for OpenChoreo ↗
Upgraded home page with configurable widgets and branding support​
The OpenChoreo Portal now includes a composable home page that teams can arrange using configurable widgets. Expect more useful widgets to be added in future releases.
Sizing guide for production OpenChoreo installations​
While not directly tied to the v1.3.x release, OpenChoreo’s documentation now includes a rough order-of-magnitude sizing guide and calculator to assist with estimations for infrastructure capacity planning.
Thank you​
Thank you to all our maintainers, new and returning contributors, and adopters for helping make OpenChoreo v1.3 possible. Your contributions and feedback continue to shape OpenChoreo's future.
We're excited to see what's next!
Join the OpenChoreo community​
If you're exploring OpenChoreo to build your internal developer platform, we invite you to join our community. We're always looking for feedback, contributions, and new ideas to drive the project forward. Here are some ways to get involved: