For years, the cloud native community has debated which technologies win.

• Which ingress controller?
• Which service mesh?
• Which observability stack?
• Which CI/CD engine?
• Which AI framework?

History has shown that these debates rarely have permanent answers.

A decade ago, Mesos looked unstoppable. Service meshes exploded with innovation. New observability platforms emerge every year. Today, AI infrastructure is evolving even faster than Kubernetes itself.

Yet many Internal Developer Platforms (IDPs) are still designed around a single assumption:

The platform team knows the right technology choices, and everyone else should use them.

That assumption creates one of the biggest long-term risks in platform engineering: vendor lock-in. The real job of a platform is not to force technology decisions. It is to provide a stable developer experience while allowing the underlying technology stack to evolve.

Developers should depend on platform capabilities, not platform implementations.

And that's why platforms alone don't win.

Ecosystems do.

Kubernetes Didn't Win Because It Included Everything​

Kubernetes itself succeeded because it became an ecosystem, not because it solved every problem. Kubernetes does not include a built-in CNI, ingress controller, storage engine, observability stack, or CI/CD system. Instead, it defines stable abstractions:

• Pods
• Services
• Deployments
• Ingress
• Custom Resource Definitions (CRDs)

Innovation happens behind those abstractions.

Organizations can replace Flannel with Cilium, NGINX with Envoy, Prometheus with another metrics backend, or ArgoCD with Flux without fundamentally changing how developers interact with Kubernetes.

The ecosystem evolves while the user experience remains stable. This separation between interface and implementation is perhaps Kubernetes' greatest architectural achievement. Developer platforms should learn from that model.

The Hidden Problem with Many Internal Developer Platforms​

Many IDPs simplify Kubernetes by hiding its complexity. That's valuable. But often they replace one form of complexity with another. Instead of exposing Kubernetes primitives, they tightly couple the platform to a specific collection of technologies:

• One ingress solution
• One workflow engine
• One observability vendor
• One security model
• One AI framework

Initially, this feels simpler. But over time, platform teams discover that changing one of these technologies requires changing the platform itself. The platform becomes the bottleneck. Ironically, the platform designed to accelerate innovation starts slowing it down.

Platform Teams Need Freedom Too​

We often talk about improving the developer experience. But platform engineers are users too. Their requirements evolve constantly:

• Replace one networking stack with another.
• Introduce a new observability backend.
• Add cost management capabilities.
• Integrate new security scanners.
• Adopt emerging AI tooling.
• Support organization-specific workflows.

A platform that cannot evolve forces teams to choose between stability and innovation. A platform built around an ecosystem allows both.

Designing for an Ecosystem​

At OpenChoreo, we started with a simple architectural principle:

Kubernetes remains the system of record.

Instead of building a monolithic platform, OpenChoreo provides higher-level abstractions for developers while allowing platform capabilities to be composed from interchangeable modules.

This led to several key design decisions.

Multi-Plane Architecture​

Rather than placing everything into a single control plane, OpenChoreo separates responsibilities across multiple planes:

• Control Plane
• Data Plane
• Workflow Plane
• Observability Plane

Each plane can evolve independently while presenting a unified experience to developers.

High-Level Platform Abstractions​

Developers should think about applications, APIs, components, environments, and resources—not networking plugins or ingress controllers. The platform translates those higher-level concepts into Kubernetes-native implementations. As underlying technologies change, developer workflows remain unchanged.

Extensible APIs​

Every platform capability should be accessible through stable APIs. Whether consumed by portals, CLIs, GitOps pipelines, automation systems, or AI agents, the same abstractions apply. This avoids creating separate operational models for humans and machines.

Ecosystem Modules​

Modern platforms cannot anticipate every future requirement. Instead of embedding every capability into the core platform, OpenChoreo allows functionality to be delivered through ecosystem modules.

Examples include:

• Networking modules
• Observability modules
• Security modules
• FinOps integrations
• Workflow extensions
• Infrastructure providers
• Built-in agents
• Reusable skills

This allows organizations to adopt new technologies without redesigning the platform itself.

AI Makes Ecosystems Even More Important​

The rise of AI agents introduces a new challenge. Agents need access to platform capabilities just as human developers do. They need to deploy applications. They need to inspect observability data. They need to trigger workflows. They need to understand policies and guardrails. If these capabilities are tightly coupled to vendor-specific implementations, every AI integration becomes custom work. Instead, OpenChoreo treats AI as another ecosystem participant. The same platform abstractions exposed to humans are also exposed to agents through MCP servers, reusable skills, APIs, and workflows. The goal is not to build a separate AI platform. The goal is to make AI a first-class consumer of the same ecosystem.

The Future of Platform Engineering​

Platform engineering is often described as building products for developers. That's true. But products eventually become ecosystems.

The most successful cloud native projects didn't win because they had the best individual features.

• Linux
• Kubernetes
• Prometheus
• Backstage

They won because they created environments where innovation could happen without replacing the foundation. Internal Developer Platforms should aim for the same outcome. The platform should provide consistency. The ecosystem should provide innovation. Developers should experience stability. Platform teams should retain freedom. Organizations should never have to choose between adopting new technology and preserving their developer experience.

Because in the long run, platforms don't win.

Ecosystems do.​

This post walks through the model, the new CRDs that back it, and a real example you can install: a small collaborative document editor called Doclet that depends on Postgres and NATS.

Why managed infrastructure needs the same treatment as workloads​

In our last post on developer abstractions, we argued that Kubernetes is a platform for building platforms, not a developer interface. OpenChoreo's answer was ComponentType and Trait: typed, declarative templates that platform engineers author and developers consume by name. A developer writes "I want a service on port 8080", and the platform translates that into the right Deployment + Service + HTTPRoute, with governance baked in.

That model worked well for the application workload. But every real application depends on more than just its own container. It needs a database, a message broker, a cache, an object store. And in most Kubernetes-native platforms today, that side of the picture stays raw.

The developer experience for managed infrastructure looks something like this:

• A wiki page that says "to get a Postgres, file a ticket with the platform team."
• A Crossplane composition the dev has to know how to invoke directly.
• A handful of ConfigMaps and Secrets dropped into the namespace by some out-of-band process, with names the developer has to memorize.
• Connection strings stitched together by hand and pasted into env vars.

Every one of these breaks the abstraction we worked so hard to give the developer on the workload side. The developer learned to think in Component and Workload, then has to context-switch into Helm values, cloud SDKs, or Terraform variables the moment their app needs a database.

OpenChoreo 1.1 closes that gap. Managed infrastructure now has the same shape developers already know: a typed, named, declarative dependency.

The two-sided abstraction​

Like ComponentType, the resource model has a clean PE/dev split.

• Platform engineers author a ResourceType (namespace-scoped) or ClusterResourceType (cluster-wide). It defines the parameters developers can set, the outputs the resource exposes, and the actual Kubernetes manifests that get emitted on the data plane.
• Developers create a Resource that references that type by name and supplies any parameters. They consume the outputs from their Workload's dependencies.resources[] block, much like they consume endpoints from other components today.

The developer never sees the data-plane manifests. The platform engineer never has to ship a new abstraction every time a developer wants a different database name. The contract between them is a typed schema.

OpenChoreo 1.1 ships three default ClusterResourceTypes out of the box (postgres, valkey, and nats), covering relational, KV/cache, and pub-sub. These are plain in-cluster StatefulSets and Deployments backed by emptyDir storage, intended for demonstration purposes only.

Platform engineers ship their own ResourceTypes for production, pointing the resources: template surface at whatever provisioner the org already uses: cloud-operator CRs, Crossplane claims, vendor-managed service CRDs, or in-house operators. A developer who consumes a Crossplane-backed postgres ResourceType writes the same Resource and the same dependencies.resources[] block as one consuming the in-cluster sample. The developer-facing contract stays the same regardless of what's underneath.

The example: Doclet​

Doclet is a small collaborative document editor shipped as a sample. It has three components:

• doclet-frontend: a React app served by nginx
• doclet-document: a Go HTTP service that persists documents in Postgres
• doclet-collab: a Go WebSocket service that pushes presence updates over NATS

And two resources:

• doclet-postgres: an instance of the postgres ClusterResourceType
• doclet-nats: an instance of the nats ClusterResourceType

Here's the whole picture as it appears in the OpenChoreo portal once everything is deployed:

Three components, two resources, edges from the project to each part, and dependency edges from the consuming services to their resources. The developer browsing this page doesn't need to know anything about StatefulSets, ConfigMaps, or Secrets to read it.

The Cell Diagram view renders the same project from OpenChoreo's cell architecture perspective: each project is a cell, with its components and resource dependencies both living inside the boundary.

The PE side: a typed Postgres template​

The postgres ClusterResourceType ships with OpenChoreo's getting-started samples. Stripped of its CEL templates and bootstrap scripts, the contract it exposes is small:

apiVersion: openchoreo.dev/v1alpha1
kind: ClusterResourceType
metadata:
  name: postgres
spec:
  parameters:
    openAPIV3Schema:
      type: object
      properties:
        database:
          type: string
          default: appdb

  environmentConfigs:
    openAPIV3Schema:
      type: object
      properties:
        memory: { type: string, default: 256Mi }
        adminEnabled: { type: boolean, default: false }

  retainPolicy: Delete

  outputs:
    - name: host
      value: "${metadata.name}.${metadata.namespace}.svc.cluster.local"
    - name: port
      value: "5432"
    - name: database
      configMapKeyRef: { name: "${metadata.name}-config", key: database }
    - name: username
      configMapKeyRef: { name: "${metadata.name}-config", key: username }
    - name: password
      secretKeyRef: { name: "${metadata.name}-creds", key: password }
    - name: url
      secretKeyRef: { name: "${metadata.name}-creds", key: url }
    # (plus adminURL and adminPassword, omitted here)

Three things to notice:

1. Parameters and environmentConfigs are JSON Schemas. Developers writing parameters.database: doclet get validated against the schema at admission time. Environment configs (memory, adminEnabled) are layered on a per-environment binding, not on the developer-facing Resource.
2. Outputs are typed by source kind. Some outputs are plain value strings (host, port). Some are configMapKeyRef. Some are secretKeyRef. The PE explicitly decides which outputs are sensitive, and that decision flows end-to-end.
3. The actual manifests live below in a resources: block (omitted above): a StatefulSet, a Service, ConfigMaps for configuration and bootstrap scripts, External Secrets Operator (ESO) resources for credential generation, and an HTTPRoute for the admin UI. CEL expressions like ${metadata.name} and ${parameters.database} give the PE a typed templating model with metadata, parameters, environment configs, and the surrounding dataplane and gateway context in scope.

The OpenChoreo Portal view of the same type makes the contract immediately legible:

One parameter (database), eight outputs with their source kinds rendered next to each name, retain policy, the description from the YAML, and the catalog graph showing six Resource instances currently using this type.

The dev side: consuming the type​

A developer who wants a Postgres for their project writes this:

apiVersion: openchoreo.dev/v1alpha1
kind: Resource
metadata:
  name: doclet-postgres
  namespace: default
spec:
  owner:
    projectName: doclet
  type:
    kind: ClusterResourceType
    name: postgres
  parameters:
    database: doclet

That's the entire Resource. No StatefulSet, no Service, no Secret. The developer chose a type, named the database, and tied it to a project via owner.projectName. Any component in that project can now consume it. The platform handles the rest.

Wiring that resource into a workload looks like this. Doclet's document service declares both dependencies inline:

apiVersion: openchoreo.dev/v1alpha1
kind: Workload
metadata:
  name: doclet-document
spec:
  dependencies:
    resources:
      - ref: doclet-postgres
        envBindings:
          host: DB_HOST
          port: DB_PORT
          username: DB_USER
          password: DB_PASSWORD
          database: DB_NAME
      - ref: doclet-nats
        envBindings:
          url: DOCLET_NATS_URL
  container:
    image: ghcr.io/openchoreo/samples/doclet-document:latest

envBindings is a map from output name (left, defined by the ResourceType) to env-var name (right, chosen by the developer). At runtime the container sees five env vars from Postgres and one from NATS. The two secretKeyRef-backed outputs (Postgres's password and the composite NATS url) become DB_PASSWORD and DOCLET_NATS_URL respectively, both resolved by kubelet from data-plane Secrets, so the bytes never travel back to the control plane.

The shape mirrors dependencies.endpoints[].envBindings, which already exists for cross-component HTTP wiring. Resources slot into the same place developers already look for "things this workload depends on".

There's also fileBindings, which mounts an output as a file rather than projecting it into an env var. Useful when an SDK insists on reading credentials from disk.

Per-environment overrides​

A Resource is environment-agnostic: one doclet-postgres Resource is the single source of truth for development, staging, and production. Each save of the Resource (or of its ResourceType) cuts an immutable ResourceRelease snapshot. Each environment then gets its own ResourceReleaseBinding that pins a ResourceRelease to that environment:

apiVersion: openchoreo.dev/v1alpha1
kind: ResourceReleaseBinding
metadata:
  name: doclet-postgres-development
spec:
  owner:
    projectName: doclet
    resourceName: doclet-postgres
  environment: development
  retainPolicy: Delete
  resourceTypeEnvironmentConfigs:
    adminEnabled: true # Demo only — exposes Adminer at the gateway
  # resourceRelease: doclet-postgres-6d67ff9695   # set when the binding is promoted

The binding is where you set per-env knobs without forking the developer-facing Resource. resourceTypeEnvironmentConfigs is type-checked against the environmentConfigs schema on the ResourceType (where adminEnabled is declared as a boolean). retainPolicy lets each environment decide whether deleting the binding tears down the underlying state or holds onto it.

Bindings are typically PE/GitOps-authored: the platform team ships them as YAML alongside the project, or generates them from a pipeline. Promotion (pinning the binding to a newer ResourceRelease) is a one-call client-side flow: read Resource.status.latestRelease.name, PUT the binding with spec.resourceRelease set. The Doclet README uses a kubectl patch loop; occ resource promote --env <env> <resource> is the same flow with the API call wrapped, and the portal's Deploy tab exposes both promote and deploy as one-click actions on each environment lane.

What this looks like to the developer​

The YAML above is what gets written; the portal is what developers actually use. Here's how Doclet's Postgres surfaces to a developer browsing the catalog:

The Overview tab tells the developer everything they need to know without leaving the page: the one parameter they set, which environments this resource is deployed in, which components in the same project consume it. The graph on the right anchors the resource in its project and ties it back to the type it instances from.

Clicking through to the Deploy tab shows the per-environment view, the same lane-based layout already used for component releases:

Development is active; staging and production are not. The "Promote" buttons on each environment lane advance the release through the project's deployment pipeline. Eight outputs are available behind the "View All" link:

The panel reflects each output's declared source kind. host and port are plain values, safe to show. database and username are configMapKeyRef. The panel shows the reference, not the value, but a "Show reference" toggle reveals the underlying ConfigMap name and key for anyone who wants to dig in. The application's password and url are secretKeyRef-backed and ESO-generated on the data plane; the portal shows the reference but never the secret bytes. The adminURL is a plain value because it's intended to be opened in a browser. adminPassword shows demo here only because this binding sets adminEnabled: true, which toggles a separate demo-only superuser for the Adminer login; with the admin UI disabled the same output renders as disabled. The application user's credential is unaffected either way.

That trust model is enforced end-to-end, not just in the UI. Secret-backed outputs are resolved on the data plane by kubelet at pod start. The control plane only ever sees the reference (the {name, key} pair), so a leaked control-plane log file never contains a credential. The same constraint applies to the CLI and any other client reading bindings: every layer reads the same ResourceReleaseBinding.status.outputs[] list, and Secret-backed entries simply don't carry a value field.

Trying it​

The Doclet sample is in the OpenChoreo repo under samples/from-image/doclet/. The README walks through the three-step install: enable WebSocket upgrades at the gateway, apply the project + components + resources + bindings, then promote each resource to the development environment. The whole thing comes up on a fresh k3d-openchoreo cluster in a few minutes.

If you'd rather start smaller, the three default ClusterResourceTypes ship with the getting-started samples and each one is independently usable. samples/getting-started/cluster-resource-types/{postgres,valkey,nats}.yaml are the source of truth for what these templates look like.

For the deeper material:

• Authoring ResourceTypes: the PE-side guide, including the full CEL surface and outputs source-kind rules.
• Resource Dependencies: the dev-side guide on dependencies.resources[], env bindings, and file bindings.
• CRD references: Resource, ResourceType, ClusterResourceType, ResourceReleaseBinding, ResourceRelease.

Components covered the application workload. Resources cover everything the workload depends on. Try it, file issues, or join us in the OpenChoreo Slack. We'd love to hear what you build on top of this.

• Get started
• Star us on GitHub
• Join our Slack

This release brings new features, user experience improvements and AI capabilities to the developer platform, addressing much of the feedback we have received following the v1.0 release.

What’s new in OpenChoreo v1.1​

Resources and Resource Types: Developer self-service for infrastructure resource provisioning​

This feature provides a much-needed mechanism for platform teams to define reusable templates for infrastructure and platform services such as databases, caches, queues, object storages, cloud services, and more as Resource Types that application teams can discover and provision.

These resource templates use the same CEL-based, environment-aware templating model already used by OpenChoreo Component Types and Traits, and support Kubernetes-native provisioners, such as Crossplane.

This builds on the same foundations as Components and Component Types, allowing platform teams to retain full control over what gets provisioned while exposing simpler, developer-focused self-service abstractions.

Learn more about resource types in OpenChoreo →

eBPF-powered data plane networking, observability and security with the Cilium module​

OpenChoreo now natively integrates with Cilium, a CNCF project that provides eBPF-based networking, observability, and security in data planes.

Once installed and configured, the optional Cilium ecosystem module enables several new platform capabilities:

1. Enhanced Cell diagrams with runtime traffic, static dependencies, and architecture drift detection

   

2. Component-level metrics for network throughput and latency

   

3. OpenChoreo controllers will switch to Cilium Network Policies for logical project isolation across environments and namespaces created in data planes configured with Cilium

Install the Cilium module from the ecosystem →

Agentic skills for platform engineers and developers with MCP toolset improvements​

OpenChoreo’s MCP (Model Context Protocol) servers cover the entire surface of its platform and developer APIs, enabling AI agents to assist with or drive actions within the developer platform based on the user or agent permissions. While the MCP toolset is self-instructional, we found that combining MCP tools with skills significantly improves the accuracy and efficiency of one-shot prompts.

This release includes four new Skills in the OpenChoreo ecosystem, supporting both imperative workflows through the UI and CLI and declarative GitOps-based workflows.

We’ve also expanded the MCP tool surface to cover API operations that were not included in v1.0, along with optimizations to reduce the total number of exposed tools and lower token overhead, especially for clients that do not support dynamic MCP tool loading.

Install the skills from the ecosystem →
Connect to OpenChoreo’s MCP servers →

Dark mode, faster event-based syncing, revamped deploy view in the Backstage-based developer portal​

Light, dark and auto modes​

One of the most requested UI features is now available in OpenChoreo’s developer portal, with native support for light mode, dark mode, and automatic theme switching based on your OS preference.

View CLI and Git-driven changes immediately with event-based syncing​

Previously, changes made outside the UI through the API, CLI, or MCP servers could take time to appear in the Backstage-based developer portal due to Backstage’s default long-polling synchronization model.

With OpenChoreo v1.1.x, the portal now uses an event-based synchronization model, allowing changes made through the API server to appear immediately in the UI without polling delays. This delivers a faster and more responsive developer experience regardless of what interaction mode you use.

Revamped deploy view with support for DAG-based deployment pipelines​

We’ve significantly improved the deployment experience to make creating releases, deploying, and promoting across environments more intuitive for application teams.

Deployment pipelines are now rendered as a visual canvas with support for DAG-based (Directed Acyclic Graph) deployment pipelines.

Install OpenChoreo Backstage UI plugins in existing Backstage portals​

While OpenChoreo ships with a preconfigured Backstage distribution optimized for a complete developer platform experience, we recognize that this is not ideal for teams that already operate customized Backstage portals.

With v1.1, you can now import and install OpenChoreo’s Backstage UI plugins into existing Backstage deployments.

Read the guide →

Extending OpenChoreo’s RBAC with ABAC (Attribute-Based Access Control)​

OpenChoreo v1.1 extends its declarative RBAC (Role-Based Access Control) model with attribute-based access control (ABAC), enabling administrators to define access policies based not only on who and what and where, but also under what circumstances.

This allows teams to implement more flexible access control policies, such as restricting deployments to production environments while still allowing the same role binding to view logs and other telemetry within those environments.

OpenChoreo v1.1 supports attribute-based conditions for environments, with more attributes planned for future releases.

Learn more about access control conditions →

Introducing the OpenChoreo FinOps agent​

We’re excited to introduce the OpenChoreo FinOps Agent, expanding the catalog of built-in platform agents designed to assist with operational workflows.

Once installed, teams can define budget thresholds for components. When actual costs exceed those thresholds, the FinOps Agent automatically analyzes historical cost and runtime telemetry to identify and recommend cost optimizations.

This agent is based on the existing Prometheus metrics module and OpenCost, an open-source project for real-time cloud infrastructure and container cost measurement.

This release sets the foundation for agentic FinOps in OpenChoreo, and future releases will bring more ease-of-life improvements, such as component- and project-level cost dashboards and analytics to the developer portal.

Install the FinOps agent from the ecosystem →

Manage secrets in external secret stores directly via the OpenChoreo UI and CLI​

OpenChoreo integrates with any secret store (such as HashiCorp Vault, OpenBao, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, etc.) that is supported by the ESO (External Secrets Operator) project. Prior to this release, platform teams needed to manage secrets directly in the external secret store and manually provide SecretReferences to application teams.

This release introduces an optional feature that allows teams to create, update, and delete secrets directly via the OpenChoreo UI, CLI, and APIs while continuing to support existing external secret management workflows.

This capability is explicitly opt-in and supports both centralized and self-service secret management models.

Enable the built-in secret management features →

Introducing the AI portal assistant​

OpenChoreo v1.1 introduces the foundation for an AI-powered assistant integrated directly into the developer portal UI. Like all AI capabilities in OpenChoreo, the assistant is fully opt-in and can be configured to use your preferred AI model provider.

Once enabled, the assistant becomes available while debugging builds and runtime telemetry, prompting you to interact with it through chat. While all of these capabilities are possible through your own agents using the MCP servers and skills, the AI portal assistant provides a more convenient experience directly within the UI.

Future releases will continue to expand the portal assistant’s capabilities within the developer portal.

Configure the AI portal assistant →

AgentGateway as an AI gateway module​

OpenChoreo now includes an ecosystem module for integrating with the agentgateway project within OpenChoreo data planes.

This module provides reusable component Traits that enable:

• Unified LLM routing across multiple providers
• MCP federation for AI agent communication
• Standardized AI gateway integration patterns

Install the agentgateway module from the ecosystem →

Agent-Sandbox integration​

This ecosystem integration with the kubernetes-sigs/agent-sandbox project introduces Component Types for deploying AI agent runtimes using the same developer abstractions and workflows already available in OpenChoreo.

Supported capabilities include:

• Sandbox environments for agents with persistent storage and other capabilities inherited from the upstream project
• Kernel-level sandbox isolation using Kata Containers or gVisor (if your hardware supports it)
• Pre-warmed sandbox pools for faster agent startup times

Set up agent sandboxing from the ecosystem →

AWS observability modules​

OpenChoreo can now integrate natively with the AWS observability stack for logs, metrics, and traces.

• Distributed logs and metrics through AWS CloudWatch
• Distributed tracing through AWS X-Ray

These integrations allow teams already invested in the AWS ecosystem to continue using OpenChoreo’s self-service workflows through the UI, CLI, APIs, and MCP servers without adopting the default self-hosted observability stack.

Support for additional cloud observability providers, including Azure and Google Cloud Platform, is planned for future releases.

Discover the AWS observability modules from the ecosystem →

Looking forward​

OpenChoreo v1.1 is another step towards making internal developer platforms more open, modular and agent-ready on Kubernetes.

We’d like to thank the community, contributors and early adopters who continue to shape the project with feedback, ideas and contributions. We’re excited for what’s ahead, and we look forward to building OpenChoreo together with the broader platform engineering community.

• Star the project on GitHub
• Get started
• Join the community on CNCF Slack (#openchoreo)

If you've come across OpenChoreo, you've probably seen our logo. It is a small stilt structure standing above two wavy blue lines. It looks simple. Maybe a bit weird at first. That's kind of the point.

People sometimes ask what it means, so I figured it was time to write the story down...

Starting from Kubernetes​

OpenChoreo is a developer platform for Kubernetes, so when we started thinking about a logo, the obvious place to look was the Kubernetes family of projects.

The word "Kubernetes" comes from the Greek for helmsman or pilot. The logo is a stylized ship's wheel with seven spokes. It is a nautical metaphor for steering containers through the complex seas of distributed systems. Helm picked up the same theme. So have a few other projects in the ecosystem.

I liked that, and I wanted OpenChoreo to belong to the same family. Even metaphors that seem random at first can become iconic when paired with the right story and the nautical thread running through Kubernetes, Helm, and other CNCF projects already had that kind of pull.

What we wanted​

When I started sketching ideas, I had a few principles in mind:

• Not corporate looking. Not too serious.
• Something that reflects developer culture, platform engineering, and open source.
• Not afraid to be a little weird.
• Unique and memorable enough to work on swag.
• No mascot.

I also wanted the logo to mean something, not just look nice, but actually map to what OpenChoreo does.

The sketch​

Here's what I drew on my iPad:

Your first reaction is probably: this is a random shape sitting on some waves. Fair enough. Let me explain.

One more small detail: the "OpenChoreo" wordmark under the stilt uses the same font as the official Kubernetes logo. It's a tiny thing, and most people won't notice consciously. But these little details matter. They make the project feel familiar to people who already live in the cloud-native world. A logo isn't just a shape; it's a set of signals.

This design is inspired by the handcrafted stilts used in traditional Sri Lankan fishing. If you haven't seen it before, it's worth a quick image search. It's been done for generations along the southern coast of Sri Lanka. I grew up around this imagery.

The parallel was hard to miss once I saw it, a person standing calmly above the water, focused on their work while everything moves below.

The waves​

The waves are everything going on under the hood such as Kubernetes, Cilium, GitOps pipelines, observability, networking, all of it. Dynamic, powerful, sometimes messy.

With OpenChoreo, you don't have to ride the waves. You just need to know they're there, doing their job, while you stay focused on yours.

The runtime environment isn't hidden either. It's visible, accessible, observable. Developers don't have to operate Kubernetes directly, but it's not abstracted away into a black box either.

The stilt structure​

Think of it as a simple platform that is just enough for a developer to sit on, do their thing, and stay above the chaos. It's not hiding what's happening below, but it keeps you steady while everything flows underneath.

That's what OpenChoreo is, really. A platform that gives developers space to focus, with the calm and confidence to build.

The voting process​

I wasn't the only one with ideas. A few other colleagues at WSO2 also pitched designs, and we ran an internal vote with all of them collected into a single deck. Each design came with a short write-up explaining the concept.

Here's the slide I submitted:

Sanjiva's reasoning sealed it. OpenChoreo sits on top of Kubernetes, so it belongs in the same nautical family and the stilt-and-waves design fit that thread naturally.

From sketch to final logo​

I designed the OpenChoreo logo - the concept, the metaphor, and the original hand-drawn version. From there, Surani Bandara from WSO2 marketing team took my sketch and produced the polished digital version that's now on the website.

Why I'm sharing this​

Here is why:

One: I think more open source projects should tell the stories behind their visual identity. The Kubernetes helmsman story is part of why people remember the project. The little nautical thread that runs through CNCF, Helm, the wheel, the wave, is part of the culture. We're adding something to that thread, and I'd rather explain it than have it stay opaque.

Two: I wanted to put the cultural reference on record. Sri Lankan stilt fishing is a genuinely beautiful piece of heritage, and it felt right to bring a piece of that into a project I've put a lot of myself into.

Three: if you're working on an open source project and you're staring at a blank canvas trying to figure out a logo, don't be afraid to be weird. Don't be afraid to start with a sketch. A metaphor that lands is worth more than a polished mark with nothing behind it.

That's the story. Next time you see the stilt above the waves, you'll know what it's about.

Before anything else, we want to give a huge shoutout to everyone who has been part of this journey. To our contributors, early adopters, and community members who filed issues, asked hard questions, and pushed the project forward. This milestone belongs to you. A sincere thank you to the CNCF team for their guidance and for giving us the space to present and discuss OpenChoreo with the broader community.

But we didn't want to stop there. Alongside the CNCF acceptance, we're also shipping OpenChoreo 1.0, our first production-ready release.

Two milestones, one moment, and a community that made both possible.

Check our CNCF submission and onboarding issues for full details.

What is OpenChoreo?​

For those who haven't heard of OpenChoreo, here's the one-paragraph version.

OpenChoreo is a complete developer platform for Kubernetes that brings together the abstractions platform and application teams actually need, development and architecture guardrails, a Backstage-powered developer portal, application CI/CD, GitOps, and observability, in a single, cohesive platform. Rather than stitching together a dozen tools yourself, OpenChoreo gives your team a production-ready foundation to build on.

OpenChoreo is the open-source evolution of Choreo, WSO2's SaaS developer platform. With OpenChoreo, we bring battle-tested ideas and years of platform engineering experience to the broader community.

How OpenChoreo works​

OpenChoreo is built on a multi-plane architecture that separates concerns rather than just stacking tools.

The Experience Plane is where developers, platform engineers, and SREs interact with the platform via a Backstage-powered OpenChoreo Portal, CLI, GitOps, or AI agents.

The Control Plane sits at the center of OpenChoreo, translating high-level development and platform abstractions such as components, APIs, environments, pipelines, and namespaces into Kubernetes and other manifests. It is also programmable, allowing platform engineers to define and extend those abstractions, through component types and traits, to fit their organization's needs, without forking the platform or writing low-level Kubernetes controllers. And it doesn't stop at deployment. OpenChoreo continuously reconciles runtime state and observability data back into those same abstractions, so developers always see a complete, high-level picture of their applications with deployment status, API health, and environment state, without ever needing to think in Kubernetes primitives.

The Data Plane is where your workloads run. It is where OpenChoreo enforces and guarantees the semantics of those high-level abstractions, such as isolation between projects, traffic policies, and security boundaries. These aren't just configurations; they're guaranteed by the platform.

The Observability Plane feeds the loop with metrics, logs, and tracing, all surfaced through the abstractions your developers already understand.

The optional CI Plane handles builds using cloud native Buildpacks and Argo Workflows by default.

Developers and platform engineers get a unified view of how every component, pipeline, and environment connect across planes, making it easy to reason about the platform as a whole rather than just individual pieces.

Built for the agentic era​

AI agents are becoming a core part of how developers and platform teams work. OpenChoreo is designed from the ground up with this in mind.

On one hand, OpenChoreo is purpose-built for agent-driven development. OpenChoreo exposes MCP servers and skills that enable your AI agents and copilots to interact with the platform as first-class participants, allowing them to create and deploy components, manage platform configurations, and reason about the platform's state.

On the other hand, OpenChoreo ships its own built-in agents to help your teams day to day. The SRE agents analyze logs, metrics, and traces to surface likely root causes of issues using LLMs (root cause analysis). The upcoming FinOps agent helps teams understand and optimize their resource costs. The Architect agent assists with system design decisions.

Modular by design​

OpenChoreo is built around the idea that you should build a platform that fits your organization, rather than inherit a fixed stack. Just as Backstage has plugins, OpenChoreo has modules that plug into the platform's planes. Today, this includes API gateway options such as Kong, Envoy, Kgateway, and Traefik.

The goal is simple: choose what makes sense for your organization and leave out what doesn't. And if the module you need doesn't exist yet, we'd love your help building it.

What’s in 1.0​

Here is a highlight of what's shipping in OpenChoreo 1.0.

Development and platform abstractions​

OpenChoreo 1.0 ships with a rich set of abstractions for developers and platform engineers, including components, APIs, environments, pipelines, and namespaces. These abstractions offer every team a clean, high-level vocabulary to work with, regardless of what's running beneath the surface.

Programmable control plane​

Platform engineers can define and extend the platform's abstractions through component types and traits, encoding your organization's preferred ways of running workloads without writing low-level Kubernetes controllers. Developers get a simple, clean interface. Platform teams get full control.

AI-native platform​

OpenChoreo is being built to treat AI agents as first-class participants. In 1.0, agents can interact with the platform via MCP to generate and edit component configurations, reason about releases and environments, and more. The built-in SRE Agent is a first example of this. It analyzes logs, metrics, and traces from your deployments and uses LLMs to surface likely root causes and actionable insights.

Observability​

Built-in distributed logs, metrics, and tracing are integrated with your abstractions out of the box. This allows developers to see the health of their components and APIs without leaving the platform or manually piecing together dashboards.

GitOps​

Built-in GitOps is a first-class interaction model in OpenChoreo. Platform and application configurations are managed declaratively through Git, with FluxCD handling reconciliation under the hood.

Component workflows and generic workflows​

OpenChoreo now includes a built-in workflow engine powered by the optional CI Plane. Run any workflow as a standalone automation, or associate workflows directly with components to build, test, and deploy them natively in OpenChoreo.

OpenChoreo console​

The OpenChoreo console is built directly on top of Backstage, giving you a unified portal to explore components, view logs, inspect releases, and manage environments. If your organization already has a Backstage-based developer portal, you can simply install the OpenChoreo plugins without replacing your existing UI or workflows.

CLI​

A first-class CLI for developers and platform engineers who prefer terminal-based workflows or want to integrate OpenChoreo into their existing automation.

Flexible deployment topologies​

OpenChoreo supports a range of deployment patterns. From a single cluster with namespace isolation for development and testing, to fully separated multi-cluster production setups for scalability and fault tolerance. Hybrid topologies are also supported, allowing teams to colocate planes like Control and CI for cost or operational efficiency.

What’s next​

As we look ahead, we're excited about the impact we can make in the community. OpenChoreo's abstractions-first approach to platform engineering positions us to contribute to ongoing discussions about what developer platforms for Kubernetes should look like.

We're eager to explore questions like: What is the right level of abstraction for platform and application teams? How do we make Kubernetes truly accessible without hiding its power? How can a programmable control plane evolve alongside an organization's needs?

We're particularly excited about the potential to integrate and collaborate with other projects within the CNCF landscape. OpenChoreo is designed to compose with the tools your teams already use, not replace them.

OpenChoreo is just getting started, and there's a lot to build. If developer platforms for Kubernetes are a problem space you care about, we'd love to have you with us. Try OpenChoreo, explore the getting started guide, or dive straight into the code. We welcome contributors from organizations and individuals alike.

• Get started
• Star us on GitHub
• Join our Slack

The best developer platforms are built by the communities that use them. We're glad you're here. ❤️

Hello everyone. I wanted to share a quick update on OpenChoreo at KubeCon EU 2026, which is just two weeks away. I'm thrilled to tell you that OpenChoreo will be there for the first time as a CNCF Sandbox project. If you're heading to Amsterdam, we'd love to meet you.

Here are some opportunities for you to connect with us in Amsterdam.

CNCF Maintainer Summit​

Sunday March 22nd, 2026

I'll be joining the CNCF Maintainer Summit for the first time, representing the OpenChoreo project. The Maintainer Summit brings together the people behind CNCF projects to collaborate, share best practices, and explore how projects across the ecosystem can work together. I'm particularly looking forward to connecting with fellow maintainers and exploring how OpenChoreo can integrate with other projects in the cloud-native landscape.

Project Pavilion: Kiosk P-2A​

Thursday March 26th, 2026 - 10am-12pm

Come visit us at kiosk P-2A in the Project Pavilion on Thursday. Whether you're a platform engineer exploring developer platform options for Kubernetes, an architect thinking about the right level of abstraction for your teams, or just curious about what OpenChoreo does, stop by and say hi.

We'll be showing how OpenChoreo brings together development abstractions, a programmable control plane, GitOps, observability, and AI-native capabilities into a single, cohesive platform on Kubernetes.

Come say hi​

This is our first KubeCon as a project, and we're looking forward to meeting the community face-to-face. If developer platforms for Kubernetes are a problem space you care about, find me at the conference or come by the booth. We'd love to hear what you're building.

Stay tuned for some exciting news about OpenChoreo during KubeCon week.

See you in Amsterdam!

Motivation – Why Do You Need Abstractions with Kubernetes?​

All modern software is built on many layers of abstraction, and in most cases we’re blissfully unaware of just how deep they go. When you build a simple REST API application, the framework (and the programming language) lets you think in terms of routes, handlers, and responses—not raw socket buffers, TCP handshakes, or parsing packets of data.

You describe what you want, and the abstractions take care of how it happens.

Kubernetes works the same way: it provides an higher-level API that lets you describe the desired state of your infrastructure and applications, and it takes care of the underlying mechanics to match that desired state.

While Kubernetes is a massive leap over managing raw infrastructure, it is still fundamentally a platform for building platforms, not a developer interface. Its many concepts are powerful for cluster administrators and platform engineers that work directly with it, but are overwhelming for application developers.

The developer intent (“deploy my app with port 8080”) usually gets buried under mechanics (“which of the ten different YAMLs should I write?”) resulting in what we call cognitive overload.

Why Abstractions Fail (Sometimes)​

Many developer platforms attempt to solve this problem by hiding Kubernetes configuration behind layers of “magic”. This often results in leaky abstractions, where teams are forced to break out of the platform the moment they need something slightly outside the happy path. On the other end of the spectrum, thin abstractions over Kubernetes still expose too much of its surface area, yielding little-to-no cognitive relief for development teams.

With OpenChoreo, we take a different approach.

OpenChoreo enables platform teams to build declarative, strongly-typed, developer-friendly abstractions that only augment Kubernetes rather than obscure it. Developers work with clear, intent-based interfaces, while platform teams retain full visibility and authority over the underlying Kubernetes resources/configurations that result from those abstractions.

Let’s Start With an Example​

Take a run-of-the-mill REST API server as an example. If you were to deploy this application on Kubernetes, you would need to compose several different resources. And while this list is by no means exhaustive, it might include the following:

• A Deployment to run your container
• A Service to expose the ports of the container to the cluster network
• An HTTPRoute (or Ingress) to expose L7 traffic to the outside world
• One or more ConfigMaps and Secrets to provide environment variables or configuration files
• Optional resources such as:
  • a PersistentVolumeClaim for attaching storage (from a StorageClass in the cluster)
  • a HorizontalPodAutoscaler (HPA) for scaling up
  • a PodDisruptionBudget for improving resiliency during node failures or maintenance

Let’s now look at how we can build a simple developer-facing abstraction using the building blocks OpenChoreo gives us, from a platform engineer’s point of view.

Creating a New Component Type​

Every component type must have a workload type that represents its primary K8s resource (i.e. a Deployment, Statefulset, Cronjob or Job). This enables a MIME-like representation of the component type using the format {workloadType}/{componentTypeName}.

We will now create a new deployment/simple-http-service component type that will represent a K8s Deployment (which is the workloadType), Service, HTTPRoute and also a PDB (Pod Disruption Budget).

We want to expose only the port, image, default replica count and the default resource requests and limits from our developers, so those will be exposed via the resulting Component and Workload to our developers.

apiVersion: openchoreo.dev/v1alpha1
kind: ComponentType
metadata:
  name: simple-http-service
  namespace: default
spec:
  workloadType: deployment

  schema:
    types:
      Resources:
        cpu: "string | default=100m"
        memory: "string | default=256Mi"

    parameters:
      replicas: "integer | default=1"
      port: "integer | default=80"

    envOverrides:
      resources:
        requests: Resources
        limits: Resources
      minAvailable: "integer | default=1"

  resources:
    - id: deployment
      template:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${metadata.name}
          namespace: ${metadata.namespace} # The namespace is provided by OpenChoreo based on the Project
          labels: ${metadata.labels}y
        spec:
          replicas: ${parameters.replicas}
          selector:
            matchLabels: ${metadata.podSelectors}
          template:
            metadata:
              labels: ${metadata.podSelectors}
            spec:
              containers:
                - name: main
                  image: ${workload.containers["main"].image}
                  ports:
                    - name: http
                      containerPort: ${parameters.port}
                      protocol: TCP
                  resources:
                    requests:
                      cpu: ${parameters.resources.requests.cpu}
                      memory: ${parameters.resources.requests.memory}
                    limits:
                      cpu: ${parameters.resources.limits.cpu}
                      memory: ${parameters.resources.limits.memory}

    - id: service
      template:
        apiVersion: v1
        kind: Service
        metadata:
          name: ${metadata.name}
          namespace: ${metadata.namespace}
          labels: ${metadata.labels}
        spec:
          type: ClusterIP
          selector: ${metadata.podSelectors}
          ports:
            - name: http
              port: 80
              targetPort: ${parameters.port}
              protocol: TCP

    - id: httproute
      template:
        apiVersion: gateway.networking.k8s.io/v1
        kind: HTTPRoute
        metadata:
          name: ${metadata.name}
          namespace: ${metadata.namespace}
          labels: ${metadata.labels}
        spec:
          parentRefs:
            - name: gateway-external
              namespace: openchoreo-data-plane
          hostnames:
            - ${metadata.name}-${metadata.environmentName}.${dataplane.publicVirtualHost}
          rules:
            - matches:
                - path:
                    type: PathPrefix
                    value: /${metadata.name}
                  method: GET
              filters:
                - type: URLRewrite
                  urlRewrite:
                    path:
                      type: ReplacePrefixMatch
                      replacePrefixMatch: /
              backendRefs:
                - name: ${metadata.name}
                  port: 80

    - id: pdb
      template:
        apiVersion: policy/v1
        kind: PodDisruptionBudget
        metadata:
          name: ${metadata.name}
          namespace: ${metadata.namespace}
          labels: ${metadata.labels}
        spec:
          minAvailable: ${parameters.minAvailable}
          selector:
            matchLabels: ${metadata.podSelectors}

There are certain fields here that we (as platform engineers) want to override based on the target environment that it’s deployed to (like development, staging or production), so note the envOverrides which we will get to later (OpenChoreo is environment-aware).

The above ComponentType (deployment/simple-http-service) can now be used by developers to create actual instances using a Component + Workload.

apiVersion: openchoreo.dev/v1alpha1
kind: Component
metadata:
  name: foo-api
  namespace: default
spec:
  owner:
    projectName: default
  autoDeploy: true
  componentType: deployment/simple-http-service # Specifying the component type

  parameters: # These are the inputs exposed from the component type
    replicas: 2
    port: 9090
    resources:
      requests:
        cpu: "200m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "1Gi"

apiVersion: openchoreo.dev/v1alpha1
kind: Workload # This would generally be colocated with the source code
metadata:
  name: foo-api-workload
  namespace: default
spec:
  owner:
    projectName: default
    componentName: foo-api

  containers:
    main:
      image: "ghcr.io/openchoreo/samples/reading-list-server:latest"

Creating Traits​

Next, we want to model a volume mount (via a PVC referencing a StorageClass available in the cluster) and a HPA as Traits so they can be used by other component types as well.

Note: The Pod Disruption Budget (PDBs) could also be modelled as a Trait, but we’ve decided to incorporate it into the Component Type to avoid exposing those details to our developers–but this is a subjective design choice; you can decide otherwise.

Similar to ComponentTypes, Traits can also expose a typed set of inputs for the developers, so they can compose them into their applications as needed.

apiVersion: openchoreo.dev/v1alpha1
kind: Trait
metadata:
  name: persistent-volume
  namespace: default
spec:
  schema:
    parameters:
      volumeName: "string | default=true"
      mountPath: "string | default='/var/data'"
      containerName: "string | default=main"

    envOverrides:
      size: "string | default=1Gi"
      storageClass: "string | default=local-path"

  creates:
    - template:
        apiVersion: v1
        kind: PersistentVolumeClaim
        metadata:
          name: ${metadata.name}-${trait.instanceName}
          namespace: ${metadata.namespace}
        spec:
          accessModes:
            - ReadWriteOnce
          storageClassName: ${parameters.storageClass}
          resources:
            requests:
              storage: ${parameters.size}

  patches:
    - target:
        group: apps
        version: v1
        kind: Deployment
      operations:
        - op: add
          path: /spec/template/spec/containers/[?(@.name=='${parameters.containerName}')]/volumeMounts/-
          value:
            name: ${parameters.volumeName}
            mountPath: ${parameters.mountPath}
        - op: add
          path: /spec/template/spec/volumes/-
          value:
            name: ${parameters.volumeName}
            persistentVolumeClaim:
              claimName: ${metadata.name}-${trait.instanceName}

apiVersion: openchoreo.dev/v1alpha1
kind: Trait
metadata:
  name: horizontal-autoscaling
  namespace: default
spec:
  schema:
    parameters:
      minReplicas: "integer | default=2"
      maxReplicas: "integer | default=5"
      targetCpuUtilization: "integer | default=70"

  creates:
    - template:
        apiVersion: autoscaling/v2
        kind: HorizontalPodAutoscaler
        metadata:
          name: ${metadata.name}-${trait.instanceName}
          namespace: ${metadata.namespace}
        spec:
          scaleTargetRef:
            apiVersion: apps/v1
            kind: Deployment
            name: ${metadata.name}
          minReplicas: ${parameters.minReplicas}
          maxReplicas: ${parameters.maxReplicas}
          metrics:
            - type: Resource
              resource:
                name: cpu
                target:
                  type: Utilization
                  averageUtilization: ${parameters.targetCpuUtilization}

And with that, our developers can now use these Traits in their Components.

apiVersion: openchoreo.dev/v1alpha1
kind: Component
metadata:
  name: foo-api
  namespace: default
spec:
  owner:
    projectName: default
  autoDeploy: true
  componentType: deployment/simple-http-service

  parameters:
    replicas: 2
    port: 9090
    resources:
      requests:
        cpu: "200m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "1Gi"
  traits:
    - name: persistent-volume
      instanceName: data-storage
      parameters:
        volumeName: data
        mountPath: /app/data

    - name: horizontal-autoscaling
      instanceName: hpa
      parameters:
        minReplicas: 2
        maxReplicas: 10
        targetCpuUtilization: 65

Environments​

OpenChoreo provides a first-class representation for Environments. An Environment represents a runtime context (e.g., dev, test, staging, production) where workloads are deployed and executed.

OpenChoreo enables a 'build once and promote’ delivery model, where you can promote a workload from one environment to the next while changing environment-specific parameters (synonymous to “storing configuration in the environment” in the 12-factor app methodology).

You’ll remember that we exposed certain fields in the ComponentType and in Traits as ‘envOverrides’. This is where OpenChoreo’s ReleaseBinding comes into play.

If we were to deploy this to the default development environment (which is already installed with the OpenChoreo Data Plane: run kubectl get environments to explore), we, as platform engineers, can override those environment-specific fields in the ReleaseBinding like so:

apiVersion: openchoreo.dev/v1alpha1
kind: ReleaseBinding
metadata:
  name: foo-api-development
  namespace: default
spec:
  owner:
    projectName: default
    componentName: foo-api

  environment: development # Bind to the target environment

  componentTypeEnvOverrides: # Override the env-specific fields exposed in the component type
    resources:
      requests:
        cpu: "50m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"

  traitOverrides: # Override the env-specific fields exposed in the traits
    data-storage: # Instance name of the "persistent-volume" trait
      size: 10Gi
      storageClass: local-path

Putting It All Together​

• Apply all of the above resources in your OpenChoreo control plane cluster:

kubectl apply --server-side -f https://gist.githubusercontent.com/binura-g/1ce4d2bfd2ecf903f5755f6900084e31/raw/ce945e4da0045e2adc377c5afad5ce007a88f2c5/openchoreo-ct-blog-v0.7.yaml

• Check the status of the releasebinding which creates the actual K8s resources in the target environment in the data plane cluster:

kubectl get releasebinding foo-api-development -o yaml | grep -iA 50 "status:"

• Find the namespace created for the target environment in the data plane cluster:

NS=$(kubectl get ns -l openchoreo.dev/environment=development -o jsonpath='{.items[0].metadata.name}')

• Observe that all the resources have been created successfully in the target environment:

kubectl --namespace $NS get all,httproute,pvc

Sample output:

NAME                                                       READY   STATUS    RESTARTS   AGE
pod/foo-api-development-ed312ff3-669778f595-8ktcc          1/1     Running   0          3h37m
pod/foo-api-development-ed312ff3-669778f595-x62rp          1/1     Running   0          3h38m

NAME                                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/foo-api-development-ed312ff3   ClusterIP   10.43.97.66    <none>        80/TCP    3h38m

NAME                                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/foo-api-development-ed312ff3           2/2     2            2           3h38m

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/foo-api-development-ed312ff3-669778f595          2         2         2       3h38m

NAME                                                                   REFERENCE                                 TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/foo-api-development-ed312ff3-hpa   Deployment/foo-api-development-ed312ff3   cpu: 2%/65%   2         10        2          3h38m

NAME                                                                       HOSTNAMES                                                               AGE
httproute.gateway.networking.k8s.io/foo-api-development-ed312ff3           ["foo-api-development-ed312ff3-development.openchoreoapis.localhost"]   3h38m

NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/foo-api-development-ed312ff3-data-storage   Bound    pvc-1b4dbf63-25a2-4212-850d-85db573f3f35   10Gi       RWO            local-path     <unset>                 3h38m

Next steps: Adding Config and Secret Support​

For brevity, we will omit this part in this article but you can find a reference implementation here that incorporates environment-specific configmaps and secrets from an external secret store: https://github.com/openchoreo/openchoreo/tree/release-v0.7/samples/component-types/component-with-configs

Explore Built-in ComponentTypes​

OpenChoreo ships with a set of default ComponentTypes that will cover a majority of common use cases. But these are also fully extensible, so you can customize them or create your own from scratch as we did above.

$ kubectl get ct # or kubectl get componenttypes
NAME              WORKLOADTYPE   AGE
scheduled-task    cronjob        86m
service           deployment     86m
web-application   deployment     86m

$ kubectl get ct service -o yaml

OpenChoreo is still under heavy development and we're shaping it with real-world feedback. If you have any questions, suggestions, or want to contribute, please join us on GitHub Discussions or Discord.

Happy building!

We’ve been actively developing OpenChoreo over the last few months, and we’re aiming for a 1.0 release in Q1 2026. Until then, the project is evolving fast, and we don’t recommend running it in production just yet. But if you’re curious, this is a great time to try it out, see how the model feels, and help us shape it with your feedback.

What’s New (and Coming Soon)​

Modular Architecture​

OpenChoreo has always been built around the idea of separate planes, control plane, data plane, CI plane, and so on. But we’re now taking that modularity a step further.

In the current 0.3.x releases, some data plane components, such as the internal and external API gateways, are built in by default. Going forward, we’re working toward making these capabilities installable and replaceable as modules. This allows you to choose the components that actually make sense for your organization instead of inheriting a fixed stack.

Even the requirement to run Cilium in the data plane will become optional. The goal is to let you compose OpenChoreo rather than adopt a monolithic platform.

ComponentTypes and Traits​

We’ve refined how Components work internally. ComponentTypes define the kind of software being deployed, for example, a backend API, a web application, or a scheduled task, and describe how it should be deployed in a consistent and reusable manner. Traits then layer operational behaviors and policies on top of that base definition. This includes things like scaling rules, traffic configurations, sidecar injection, or observability settings.

The result is a model where platform operators can encode the organization’s preferred ways of running workloads, while developers work with a simple, clean abstraction and never need to deal with the complexity of Kubernetes directly.

There are more details in this discussion: https://github.com/openchoreo/openchoreo/discussions/816

GitOps-Friendly Deployment and Promotion Flow​

With the introduction of ComponentReleases and ReleaseBindings, OpenChoreo is becoming significantly more GitOps-friendly. A ComponentRelease is an immutable snapshot of a component at a specific point in time, capturing the component definition, workload configuration, component type, and traits. A ReleaseBinding then describes where and how that release runs in a particular environment.

This provides a clean, predictable workflow where a release can be created once, tested, and then promoted across environments without configuration drift or unexpected side effects.

OpenChoreo Console (Backstage-Based)​

The current version already includes several Backstage plugins, but we are now building the full OpenChoreo console directly on top of Backstage. This will provide a unified portal to explore components, view logs, inspect releases, and manage environments.

Since it is based on Backstage, you can continue using your existing plugins and integrations. If your organization already has a Backstage-based internal developer portal, you will be able to simply install the OpenChoreo plugins without replacing your UI or workflow.

AI-Native Platform​

We are also working on making OpenChoreo AI-native. In practice, this means your AI agents will be able to interact with the platform as a first-class participant, generating and editing component configurations, reasoning about releases and environments, and even managing parts of the platform itself.

OpenChoreo will include built-in agents to help guide developers and simplify day-to-day workflows.

And More​

There are many more improvements underway. The best way to follow along is to watch the GitHub discussions, where we share design proposals and ongoing development work in the open.

Try It, Explore It, Tell Us What You Think​

OpenChoreo is still under heavy development, we’re shaping it with real-world feedback.

If you’re experimenting with platform engineering, building your own IDP, or evaluating how to simplify Kubernetes developer experience, we’d love your input.

• Try the sample projects
• Browse the CRDs & console
• File issues
• Join discussions
• Or just tell us what feels intuitive vs. awkward

More updates soon. Until then, happy building.

On this blog, we plan to post release updates, upcoming features, community adoption stories, and the occasional off-topic stuff (you’ve been warned).

In the meantime, we’d love to hear your thoughts on the OpenChoreo logo. What comes to your mind when you see it? Feel free to share your impressions, interpretations, or wild guesses in whatever way you can. We’ll write more about the logo soon.

To wrap things up, here’s a roundup of recent posts, talks, and videos that dive deeper into OpenChoreo or explore related ideas in the platform engineering space:

• OpenChoreo GitHub repo
• OpenChoreo Architecture
• Why Companies Fail at Building Internal Developer Platforms (IDPs)
• OpenChoreo: An Open Source Blueprint for Internal Developer Platforms
• Platformless: How Choreo Built a Secure Kubernetes Platform with GitOps

We’re always looking for guest posts, community contributions, and feedback. If you’re building with OpenChoreo or thinking about it, don’t hesitate to reach out.

Until next time — happy hacking, and welcome aboard.