OpenChoreo 1.0 enters the Kubernetes internal developer platform market with AI agent integration, GitOps workflows, and a programmable control plane architecture, positioning itself against established players like Crossplane and newer entrants like KubriX.
OpenChoreo 1.0 represents a significant evolution in the Kubernetes internal developer platform (IDP) space, introducing AI agent capabilities and GitOps workflows as core components of its architecture. The open-source project, now accepted into the Cloud Native Computing Foundation (CNCF) Sandbox, offers organizations an alternative to building custom developer platforms or adopting existing solutions.
What Changed: OpenChoreo 1.0 Architecture and Capabilities
OpenChoreo introduces a multi-plane architecture designed to separate concerns rather than stacking tools. The platform consists of four core planes:
- Experience Plane: Handles developer and site reliability engineer (SRE) interactions through a Backstage-powered console
- Control Plane: Translates high-level abstractions into Kubernetes manifests and reconciles runtime state back to those abstractions
- Data Plane: Where workloads actually run
- Observability Plane: Manages metrics, logs, and traces
An optional CI Plane handles builds using cloud native Buildpacks and Argo Workflows.

The 1.0 release introduces several key innovations:
AI Agent Integration: OpenChoreo exposes Model Context Protocol (MCP) servers, enabling AI agents to create and deploy components, manage configurations, and reason about platform state. The platform treats AI agents as "first-class participants," according to Sameera Jayasoma, Distinguished Engineer at WSO2 and project lead.
Built-in SRE Agent: Uses LLMs to analyze logs, metrics, and traces, surfacing likely root causes of incidents without requiring extensive manual correlation.
GitOps as First-Class Interaction: Managed under the hood by FluxCD, GitOps workflows are integrated from day one, providing a declarative approach to application delivery.
Extensible Abstractions: Platform engineers can define and extend component types and traits without writing low-level Kubernetes controllers, enabling customization without forking the platform.
The modular design allows organizations to select components based on their specific needs, with API gateway support including Kong, Envoy, Kgateway, and Traefik. Deployment topologies range from single-cluster setups with namespace isolation to fully separated multi-cluster production environments.
Provider Comparison: OpenChoreo vs. Competing Solutions
OpenChoreo enters a competitive landscape with several established and emerging Kubernetes IDP solutions:
Crossplane
- Graduated from CNCF in November 2025
- Focuses on extending Kubernetes with declarative APIs
- More infrastructure-centric compared to OpenChoreo's developer-centric approach
- Better suited for organizations with existing Kubernetes expertise
KubriX
- Launched in August 2025 with similar premise
- Built from established tools including Argo CD, Backstage, and Kyverno
- Takes an opinionated approach rather than programmable control plane
- May be simpler to adopt but less flexible for customization
Backstage
- The underlying developer portal technology in OpenChoreo
- More focused on developer experience than full platform capabilities
- Requires additional tooling for complete IDP functionality
OpenChoreo differentiates itself through its programmable control plane approach, which allows platform engineers to extend the platform without forking the codebase. This contrasts with solutions that require either extensive integration work (like building from Backstage) or accept rigid, opinionated stacks.
The project's acceptance into the CNCF Sandbox after less than a year of development (first commit in January 2025) indicates strong community interest, with 785 contributors across 240 organizations and 694 GitHub stars as of January 2026.
Business Impact: Adoption Considerations and Migration Path
For organizations evaluating OpenChoreo, several business and technical factors should be considered:
Adoption Scenarios
- Greenfield deployments: Organizations starting new Kubernetes platforms can adopt OpenChoreo as a foundation without building from scratch
- Brownfield integrations: Existing Backstage deployments can extend functionality with OpenChoreo plugins rather than complete replacement
- Hybrid approaches: Teams can selectively adopt components while maintaining existing tooling for other functions
Migration Considerations
- Teams already using FluxCD for GitOps will find familiar workflows, though integration with existing CI/CD pipelines may require adjustments
- The platform's "does not hide K8s" approach means developers maintain visibility into Kubernetes primitives, which may appeal to organizations with Kubernetes expertise
- Organizations heavily invested in other CNCF projects may find integration points, but should evaluate the learning curve for new concepts like the control plane
Total Cost of Ownership
- Reduces platform engineering overhead by providing pre-integrated components
- Extensibility through abstractions may reduce long-term maintenance costs compared to custom-built solutions
- AI agent integration could potentially reduce operational costs through automated incident response
Market Positioning OpenChoreo appears positioned for organizations that want:
- A middle ground between full Kubernetes exposure and complete abstraction
- Extensibility without the complexity of building custom solutions
- Integration of AI capabilities in a structured manner rather than ad-hoc adoption
The project's approach to treating AI agents as first-class participants suggests a forward-looking strategy, acknowledging that AI will increasingly play a role in developer and operations workflows. However, the practical impact of these AI features remains to be seen in production environments.
As Sameera Jayasoma has indicated, OpenChoreo aims to engage with ongoing CNCF ecosystem discussions about developer platforms rather than positioning itself as a complete solution. This collaborative approach may benefit the project as the Kubernetes IDP space continues to evolve.
Organizations interested in OpenChoreo can evaluate the project at github.com/openchoreo/openchoreo, with documentation available at openchoreo.dev. The modular architecture allows for incremental adoption, enabling teams to start with specific components before expanding platform-wide.

Comments
Please log in or register to join the discussion