こんにちは (Konnichiwa)! I wanted to share a quick update on OpenChoreo at KubeCon + CloudNativeCon Japan 2026, which is just next week. Fresh off our first KubeCon in Amsterdam, we're excited to bring OpenChoreo to the community in Japan as a CNCF Sandbox project. If you're heading to Japan, we'd love to meet you.

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

Find us at the Project Pavilion​

Wed, July 29, 2026 — 10:45–14:45 · Table T-3

Come visit us at Table T-3 in the Project Pavilion. 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 (or お立ち寄りください!).

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.

What we'll be showing​

This trip we're demoing the latest in OpenChoreo v1.2.0, including our already loved typed ComponentType and Trait developer abstractions and the self-service Resource model that lets developers depend on databases, queues, and caches declaratively.

The headline for v1.2.0 is the new Project Release Lifecycle: shared, project-scoped infrastructure — namespaces, NetworkPolicies, ResourceQuotas, and RBAC — is now captured as versioned, immutable snapshots you can promote across environments, bringing the same GitOps discipline you already get for components to the platform layer underneath them.

We'll also be showing off the developer experience improvements landing alongside it — an interactive shell into running components and AI-assisted debugging from the Backstage portal, a redesigned flow to browse and compare releases, and API Try Out for OpenAPI and GraphQL endpoints. If you've been following along, we'd love to hear how these map to the problems you're solving on your own platforms.

Come say hi​

This is our first KubeCon in Japan, 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.

Yokohama でお会いしましょう — see you in Yokohama! 🇯🇵

Key Takeaways​

• OpenChoreo is not a Kubernetes distribution; it installs on top of any existing Kubernetes cluster and provides a unified control plane that orchestrates CNCF tooling across data, observability, and workflow planes.
• Agents are first-class citizens. Two MCP servers (control plane and observability) expose roughly 100 tools, with the same permission model and guardrails applied identically to human users and AI agents.
• The abstraction layer solves the agent context problem by hiding raw Kubernetes internals behind higher-level OpenChoreo concepts; agents get the right context in fewer tokens.
• Pre-built SRE, FinOps, and Architect agents ship out of the box. The SRE agent ingests logs, metrics, and config changes, generates root-cause reports, and can be authorized to apply fixes autonomously.
• The permission model supports incremental agent trust that is read-only by default. Write permissions can be granted per agent identity, enabling a walk-before-you-run adoption path.

You can view the podcast here.

Transcript​

Introduction 0:00​

Bret Fisher: Welcome to DevOps and Docker Talk. On here, we talk about all cloud-native things, and another Kubernetes project has begun and showed up as a CNCF sandbox project this year, and that is OpenChoreo. This project is all about adding AI agents and essentially a new abstraction on Kubernetes itself, that interfaces between what we're all now using as our primary interface to everything software, which is agent harnesses, and what the Kubernetes API and other APIs provide that are typically on Kubernetes, like your monitoring, your observability, or whatever else you might need. This project is adding a new abstraction layer. I'm calling it an abstraction layer because it provides API, MCP, CLI, and web UI to front-end everything else you typically deal with, whether that's your GitOps tools like Argo, your orchestration, your storage, your observability, Kubernetes itself, your authentication, all that stuff.

Bret Fisher: We are now in a world where we're all playing around with agent SDKs and trying to figure out what we can automate in our infrastructure safely with reliable LLM prompts. These are all things we're probably thinking about. If you're not doing it, you're thinking about it, or you're waiting for someone to tell you how to get it done. OpenChoreo is a new project that came out of WSO2, and they were running it on their own SaaS infrastructure and realized it might be useful to others, which was also how the Docker project got started, by a cloud company realizing that their infrastructure tooling was maybe the most useful part of their product, and released it for free. So OpenChoreo came out of a business hosting a legitimate tool for Kubernetes users and felt like it needed to be open source. Now they're going to be running that on their own platform for customers eventually, but for now they're just focused on getting it open source. Now that it's officially a CNCF sandbox project, that means they've met the minimum level of maturity to explore whether this could succeed in the marketplace, whether those of us building or running open source tools on top of Kubernetes would be interested in an agent platform on top of Kubernetes.

Bret Fisher: Specifically, this is about us administrating and managing these environments with agent harnesses through the OpenChoreo abstraction (their MCP, API, and CLI). This is not about running inference or building custom models. This isn't about being an AI ops or MLOps person. And this isn't about running custom agents that we built in pods inside of a cluster, although that's certainly possible. The main focus is on exactly what I talk about on this show as well as my other podcast, Agentic DevOps. This one I'm trying to keep focused on CNCF projects, Kubernetes and Docker projects. The Agentic DevOps podcast is really about the patterns, behaviors, and tools for just being a DevOps or platform engineer or SRE who's using AI to get their job done.

Bret Fisher: On the show this time I have Lakmal and Sameera from the project team over at WSO2, talking about this, getting into the details of what it does and doesn't do, and also explaining to me how it's not what I actually thought it was when we first started talking about it. In the show notes, there are links to the actual demos — we tend to cut those out of the podcast version, but you can see how the product works and how you can use agents to interface with Kubernetes. We could use agents before, but we didn't necessarily have all of that infrastructure in place besides just a raw API. This helps solve a lot of that with a new level of abstraction. Let's get into it. Lakmal, tell us about yourself. Who are you? Why are you here?

Lakmal Warusawithana: I am working as a VP and Distinguished Engineer at WSO2, and also GM of the Choreo BU. I started my career as a systems engineer in 2001 and for the last 25 years I've been engaging with building many platforms. Here we are today.

Bret Fisher: Sameera, how about you?

Sameera Jayasoma: I'm Sameera Jayasoma, one of the co-maintainers of OpenChoreo. I started my career in programming language design, compiler engineering, and platform architecture. You'll hear more about abstractions and compilation throughout this talk — that's me.

Bret Fisher: We'll get a gist by the end of what you're really into. So you all reached out. This is a new project. I'm always excited about new CNCF projects because once they've been accepted into the sandbox process we get an idea, it's like reading the tea leaves a little bit. Not everything is a winner, not every project makes it to graduation. But it's an interesting way to separate the hobby projects from things that teams are taking seriously, because you don't really go for sandbox status unless you're taking things seriously. That's where I wake up and start paying attention to new projects. I'm excited to talk about this today because I'm obsessed with AI agents, how we manage infrastructure with agents involved, how we put MCP in our clusters safely, how we sit on our harness as our primary mechanism for interacting with 20 to 40 years of complexity that we've all built up. The number of abstractions we all have to deal with today is insane, and it's amazing that anyone can go to a conference and have a common conversation because there are a thousand tools we're all using. How did the project get started?

Lakmal Warusawithana: We started this software offering called Choreo SaaS five years back. It started as an iPaaS — an integration platform as a service, then it evolved into something where you could run all other services within the platform itself, so it evolved into an internal developer platform a couple of years later. The name comes from "choreography", we shortened it to "Choreo." It's like choreographing your microservices in a certain way, where Kubernetes does the orchestration and we do the choreography for all your microservices. We were offering this to enterprise customers, fully managed by WSO2. We were running Choreo version 2, and two years back we started the Choreo version 3 project — the next version of our current offering, and eventually it became OpenChoreo. At WSO2 all our software is open source, so we thought: why not open source the software we're running ourselves? That's how OpenChoreo started. This January we donated it to the CNCF foundation and now we are a sandbox project.

Bret Fisher: That's a similar path to how Docker was invented, because it was a platform company saying "this piece of our platform is pretty interesting, but it's maybe a utility at this point — let's just give it away." So it's not a bad idea to do this.

What Makes OpenChoreo Different 8:29​

Bret Fisher: What was the unique problem you were trying to solve? How does the team look at it from the perspective of "this is a unique thing" in a world where we've got dozens of Kubernetes distros? First off, do you even think of this as a distribution of Kubernetes? Do you see it as vanilla Kubernetes with some things bolted on, or how is this different from something like Rancher?

Sameera Jayasoma: OpenChoreo is something we have built on top of Kubernetes. You can use any Kubernetes distro — Rancher, EKS, AKS, any Kubernetes and then just install OpenChoreo on top of it. The idea is that you have Kubernetes and all the other tools, and you have a developer platform. What we've seen in the industry is that you can build this developer platform with Kubernetes and Argo and all the things glued on, and then you expose that layer to developers and build a developer experience around it — portals, MCPs. But we've figured out that that way you expose the platform complexity to your developers. They have to learn Kubernetes, they have to learn all the tools. What's unique here is that we build a middle abstraction layer on top of Kubernetes and other tools. Through six years we've figured out that abstraction layer, and it helps us build a developer experience layer where developers are abstracted away from Kubernetes. They can still see what's going on, but they may not need to learn a lot of things about Kubernetes and other tools. That's one of the unique layers in the platform.

Bret Fisher: So when we talk specifically about OpenChoreo, is it installing all the parts? For the audio audience, we're looking at a visualization. I love diagrams because they help me understand the conceptualness of something. To me it looks like a full-fledged, fully built-out Kubernetes cluster with all the extras — all the necessary things that an enterprise cluster would have. There are components like KEDA for scaling, Cilium for networking, API gateways, Argo Workflows, Buildpacks, observability layers with Prometheus and all the OpenTelemetry stuff. And then over to the side there's OpenChoreo as this control plane. It's almost like the control plane on top of the control plane. Is this really just focused on the OpenChoreo control plane components on the left and showing how it interacts with the rest, or is this actually helping us implement all of this?

Lakmal Warusawithana: The main idea behind having a unified control plane is that platform engineers, developers, or even our AI agents can interact with the control plane via different protocols, and then the control plane does all the orchestration across all those other planes — the data plane with Cilium network policy, scale-to-zero with KEDA, all these things can be orchestrated using a control plane with governance enforced through the control plane. That's the main idea. What I've seen as a problem is that even when we expose all these services to the end user, whether it's a platform engineer or a developer, you can't enforce governance. But having this single control layer, we can have guardrails, policy enforcement, and a single pane of glass. That helps to orchestrate across the different planes. Those planes are built using modular architecture in OpenChoreo. For example, if you take an API gateway, it can come from the WSO2 API gateway, kgateway, Kong gateway — it isn't tied to a single vendor. It's building an entire ecosystem around it. Users can pick and choose what they want to use in their data plane, and the abstraction layer helps orchestrate all those different tooling choices.

Bret Fisher: So if I'm a platform engineer listening to the show, that probably means I have platforms today, I've already got Kubernetes in production, I've already got a lot of these components. Is the idea that this project is for implementing the OpenChoreo control plane components and then including the system components that link or integrate with the APIs of those other things? Is that where you're drawing the boundary of where your project ends?

Sameera Jayasoma: Yes, that's a good way to put it. Our main component is the control plane, and at the same time there are certain system components running in all the other planes as well — data planes, observability plane, workflow planes. If you're already running these projects, it's just a matter of installing our system components and organizing your platform architecture in this way. And what Lakmal said about abstractions is that when you think about this developer platform, the primary users are platform engineers and the primary consumers are developers. They will use the experience plane — UI, MCP server, and things like that. They will say "I want a project, I want a component, I want this component deployed on a dev environment," and the control plane understands that and executes and compiles that into Kubernetes and other projects in a way that those projects understand. That's the idea behind all those arrows in the diagram.

Bret Fisher: When I look at the diagram, from a platform team perspective, I recognize all the names, it's a lot of terminology from different CNCF projects. Are you thinking of AI as the main interaction point? I see there's a web console, but do you think AI is going to be increasingly the way we interact with Kubernetes? When I look at this diagram, all the arrows from how things interact with the Kubernetes cluster seem to go through the OpenChoreo control plane. You've got the Backstage UI, presumably for humans, but then you've got MCP, CLI, and API as other interaction endpoints. When I see this diagram, I think: this allows me to put another abstraction layer for my AI to work through, so I'm not running my AI directly against the Kubernetes native API. I've got this enhanced layer with additional functionality. I see you have authorization and access control, which is a big thing for me lately — how do we minimize the blast radius of giving agents access to different tokens and not giving them root "god" rights to the cluster every day, which I see a lot of people doing by just giving them kubectl admin abilities? Is that the goal of where you see agents being responsible for clusters?

Lakmal Warusawithana: Yes, exactly, that's described correctly. What we want is: when the developer platform gives the golden path, the guardrails, the policies to our human developer. The same way we want to expose this same golden path to the AI agents that interact within the platform.

Agents as First-Class Citizens 16:41​

Lakmal Warusawithana: In OpenChoreo, agents are first-class citizens. In the current release, we're exposing two MCP servers: the OpenChoreo control plane MCP server and the OpenChoreo observability MCP server. External agents can interact with these MCPs as well as internal built-in agents. When they interact with the MCP servers, the permissions and all the guardrails apply the same as for a developer user in the platform. It's a unified experience whether it's a human developer, a human SRE, or an agent working as a developer or SRE.

Bret Fisher: So this shows up as a bunch of MCP tools I could plug into locally. If I've got Claude Code running, I plug in the MCP endpoints. What's the estimated tool count? Are we dealing with 100 tools, 20 tools?

Lakmal Warusawithana: It depends on the user persona interacting with MCP. We have a developer persona and an SRE persona — they get different tooling based on their role, and based on that, they can do different activities.

Sameera Jayasoma: Roughly, I would say roughly 100 tools altogether.

Bret Fisher: Not an insignificant amount of tools. So what you're saying is based on who I'm authing as, which role I'm authing as, I get a scoped set of MCP tools based on my permissions.

Lakmal Warusawithana: Yes, exactly.

Bret Fisher: So these agents are coming. You're listing AI agent modules — you've got SRE, FinOps, and Architect. What does that agent mean to me? If I'm on my local harness, are those long-running agents sitting in the cluster? How do I interact with them?

Sameera Jayasoma: We have internal agents and external agents. They both use the same experience plane, MCP servers, and tools. Claude Code is an external agent. The FinOps, SRE, and Architect agents are platform agents running in the cluster, and they are reacting to certain events. For example, if there's an alert — a lot of 500 errors are going on, the SRE agent will react and give you a report on what's going on and why. You can configure the agent with certain alert types: if you are consuming high memory above a certain limit, the SRE agent will also react. The FinOps agent is similar in that way.

Bret Fisher: So each of those agents comes predefined with a scope, and presumably through the control plane, I'm plugging those into my messaging apps, into Slack or whatever, and those are how the agents reach out to me. Do they go through a middle layer like an alerting system the way Prometheus does for alerts?

Lakmal Warusawithana: Yes, at the moment it's going through a middle layer, the alerting system. We have log-based alerting with OpenSearch and the Prometheus layer for metrics. Agents interact with the same layer. The alerting system can be configured with PagerDuty, Slack channel, or other channels — that's how the architecture currently works.

Bret Fisher: This feels like it's designed to be batteries-included. A lot of the conversations I have, I'm lucky to be in the Agentic DevOps guild I run, and we meet weekly, are around what teams are trying to do right now with agents related to infrastructure. People are in that middle mode right now. The local agent harness has become common knowledge; we've all experimented with GUIs, TUIs, multi-agent management, sessions, and skills. But the minute I have to start running what I call "server agents", these long-running, always-looping agents that are sitting there checking something, continually polling for something, or waiting for a webhook if they're event-driven — these things are probably going to be everywhere, and you're providing a few out of the box defined to do specific things. So I don't have to go find an agent SDK and make up what an agent might do in my cluster, because that's kind of what a lot of us are doing right now — we're writing little agents everywhere, making it up as we go, because we don't really know which parts to automate or which parts they'd be good at. But it feels like this system helps with the context problem, because that's always a really hard problem: what context do I need to give my agent to make it useful and not hallucinate, and how do I get at that stuff at the time it needs it?

Lakmal Warusawithana: Exactly. The main idea is that we have this ecosystem, and within the ecosystem, we have the agents. The community or even OpenChoreo maintainers will release agents, and then our users can pick and choose which agents to run in their OpenChoreo system. For the SRE agent, the intention is: when something happens, the SRE agent can trigger, and we feed all the logs, metrics, config changes, and code changes to the SRE agent within that window. It can then generate a post-incident report, root cause analysis report, and alert the human SRE. When they come into the system, they already have the root cause report. And we're not stopping there, the agent can also provide remediation actions: "This is a quick fix if you want to fix this issue." At the moment, it's human-in-the-loop, so the human SRE can apply those fixes. But we have the permission model where we can give certain agents the ability to automatically apply fixes themselves rather than waiting for a human. We can say: "If this is only a config change, I will allow my SRE agent to apply that change and fix the issue." So eventually it can take on more activity, but it always has human control built in by design. We know what context we need to feed into this agent to provide better results; that's how the built-in agents are acting.

Sameera Jayasoma: And these agents are also a good starting point for you to come up with your own agents, because the context problem is largely solved within the platform. These agents work against the OpenChoreo abstraction layer rather than exposing raw Kubernetes details, and that's what we've figured out — those abstraction fields help us give the right context.

The Future of Agentic DevOps 24:50​

Bret Fisher: I was writing an article over the last week around what an AI Kubernetes platform even means. What I had to define in this newsletter is what I'm calling "type three AI on Kubernetes." If you've been going to KubeCons since the invention of ChatGPT, for most of the history of what we now call Gen AI, we are not talking about AIOps and MLOps. For those of us that go to KubeCon, I've been ranting for a couple of years now that there's been a weird disconnect, when a lot of people in the industry talk about Kubernetes and AI, they're actually talking about running AI, making AI, building models, reinforcement learning, and running inference. That's not my world. To me that's a specialty, and while it might get easier, I feel like there's still a significant majority of us that won't be doing that. Our new job is to build out these agents and understand where the features and the edges of models can be implemented so we can automate and build more.

Bret Fisher: I see this whole thing as just like VMs, the cloud, the invention of the PC. Over my 30-year career, we've had major pivoting points in technology that allowed us to scale ourselves as humans. We went from managing 10 servers in the 90s to 100 servers with VMs to a thousand servers with the cloud. Maybe containers allowed us to run 10,000 pods per admin. And now this is the next level. What you all are building is exactly that layer of abstraction; the agents and their context management and permission management, which is this new level of abstraction that will hide some of the complexity. We don't have to know every kubectl command in the world anymore. In fact, I don't even know how we all get Kubernetes certified, because if we're not going to be running kubectl and knowing every option, what is a Kubernetes admin test other than just understanding architecture?

Bret Fisher: This post took me a week to write because I was trying to theorize: we're really talking about agentic operations. That's the reason I have the new podcast; that's the reason this project is exciting; this is that new layer, the abstraction we're all searching for. I think we've understood the local harness now after having those for a little over a year. But this new nebulous layer sitting in front of our infrastructure is still not fully realized. You all are pretty early in the game in terms of saying, "We can help, we have this defined component." I'm trying to draw a diagram of a maturity path: we started with the agent harness locally, and the end goal is we've maximized the agent assistance — the dozen agents, two dozen agents, maximizing all the functions and features of what models can do for us as DevOps engineers, platform engineers, SREs. We're all managing this infrastructure. There are a dozen tools and a thousand features we now need to learn. We're learning skills and agent files and MCPs that can go awry. But eventually the idea is we're improving productivity, improving management, making things more secure, and reducing outages. A year ago we were all nervous about whether our jobs were going away. But to me, this is the job. This is the new job. Where do the agents help, where do they not help, where do we still need the human in the loop? Does any of that resonate?

Lakmal Warusawithana: I think you're correct. It's evolved in the last one year, within one year we can run agents in production, helping different personas engage within the platform. I believe the generating code problem is almost solved now with Claude Code, Cursor, or Codex. People can generate code and write applications within minutes. We call it "vibe coding", but the moment they hit deployment, the vibe is ending, because the coded application has to be promoted into production, but the platform doesn't support it. They have to go away from the agent, either create a ticket or go to the self-service portal to deploy the application. What we've seen with our skills and the MCP server is that they can use the same agent they're using to develop their code and say, "I want to deploy my application into the development environment, you figure out how to do it." So now we call it "vibe deployment." OpenChoreo tries to fill the gap on the deployment part, the operational side of it. You can write your code using an agent and now use the same agent to deploy your application into production, with the support of OpenChoreo's abstraction as well as the tools supported in the MCP servers. That's where we want to play in this platform engineering side of it.

Sameera Jayasoma: And abstractions help agents, the way I think about that is: more abstractions, fewer tokens. They don't have to learn deep Kubernetes YAMLs and kubectl. The same applies to programming languages — writing assembly versus writing in Java or C# or Go, right? Fewer tokens in that way. They have more context with less token budget. That's what I'm working on these days, whether we can establish that.

Bret Fisher: We're very quickly understanding that tokens are finite, just like early in our Kubernetes journey, we realized how much infrastructure we actually need to just run the apps. When you build out a full-scale Kubernetes cluster, there is a non-insignificant amount of infrastructure to manage the infrastructure, and I don't think we all really understood the eventuality of dozens of different controllers and dedicated nodes in the control plane. I feel like now the same thing is happening with tokens. We got all excited and we're going to put agents everywhere, and we're going to very quickly end up in a world where we've got budgets and we have to optimize our agents. One of the conversations we're having in the Agentic DevOps guild is around evals — how can we use evals to figure out which model to use? If my agents are really just behaving with a bunch of skills and context management stuff, how can I programmatically determine that maybe I could use Gemma or Minimax or Qwen or some openweight model that's super cheap for my very specific niche agent, whereas maybe it doesn't need Opus? None of us want to put these in production and then find out a month later that it's too expensive to run and have to shut it down.

Deploying with Agents: Live Demo 32:55​

Bret Fisher: We've had Innerhive on the show and Mindrol on the show, both AI startups building agents to help with infrastructure CI/CD and fault remediation. The approach I've been seeing everybody take is the normal pattern of engineering: walk before you run, run before you sprint. On day one, you might be read-only. Agents can't do things, they can just look things up, they're a little helper assistant with no control over anything, just here to help you find information in this sea of infinite information about your infrastructure. Then, like with Mindrol, they're now to the point where for very specific use cases they're letting the agent have a tiny bit of control, because it's predictable. They can test to make sure it works, that it's as declarative as possible, and they start to let that happen. Is that something we can do with OpenChoreo? Does it have a default stance of read-only? How do the permissions work?

Lakmal Warusawithana: It's not read-only, you can control it. We have the permission model where you can give different tools to different agents. It can be read-only tools, it can be write/operational tools as well. Based on what you want to do, you can allow these permissions, because agents have their own identity, and within that identity, they have permissions. Based on the permissions, they can use different tools. If you are confident enough that your agent is performing well, you can give it write permissions to do some level of activity — for example, if there is a configuration issue, the agent can go and fix the configuration itself. You can fine-tune how your agent can interact with your platform.

Bret Fisher: I've been wondering about how permissions are going to work — so much of our permission models today feel like they're not designed for an agentic world. And how are we going to track the actions of these things? Every little step they take, hopefully will be put into some sort of observability platform. I'm trying to envision how to correlate this to the things we know today; GitOps repos with Argo CD definition files that get pulled in because Argo or Flux is watching a different repo and looking for YAML changes. Does this change that workflow? I see GitOps on the diagram. How does this correlate to the GitOps loop that so many teams have adopted?

Sameera Jayasoma: The CRDs — you can put all of these in your GitHub repo and then configure Argo CD or Flux, and the normal workflow will work as it is. So there are two modes here. I think we are using more of a click-ops approach in the demo, but you can configure the same thing with your GitOps.

Bret Fisher: For audio listeners, we're looking at a dashboard. We're vibe-opsing, not click-ops, because we're not clicking on the dashboard; we're using the agent. But just to be clear: the agent is causing OpenChoreo to create new resources inside the cluster for deploying the Google microservices demo. That is an alternative to having an agent make a new PR in YAML and push that to GitHub and then have Argo or Flux pick it up later. I could give the agents skills so that they know that's my workflow and I'm using it as a read-only partner. Just like we're not supposed to go into the AWS console and click-ops away, I don't necessarily want OpenChoreo changing my infrastructure outside of my GitOps loop. Do you think the GitOps approach is less important if we have this sort of agent chain of events, or do you see enterprise teams possibly shifting to more of this vibe approach? Or do you think GitOps is here to stay as the more mature, safe approach?

Lakmal Warusawithana: When you come to lower environments, agents directly creating custom resources will play a big role. But maybe in production, when you promote to production, people will use GitOps or a declarative way of defining things. Eventually, if the human is confident enough with their agents and trusts them, I would say agents can directly call the MCPs and create custom resources directly within the cluster itself. Not this year, but maybe in the future.

Sameera Jayasoma: One advantage of GitOps is that you have the tracing — you know exactly what happened over the years. For dev environments, you probably don't need GitOps; you can give developers full capability to do whatever they want. But for other environments, my view is you would still use GitOps to control the workflow.

Bret Fisher: I started to wonder if agents will eventually change this. Everyone's already writing YAML with agents; teams using Claude Code are not handwriting Kubernetes YAML anymore. And there is a mode in Argo where you can do things retroactively, make changes but document them after you're done. I wonder if agents create a future where GitOps is more of a system of record done after the fact, and agents push us into a faster evolution of this.

Sandboxing & SRE Auto-Remediation 39:26​

Bret Fisher: A constant conversation we're having is around sandboxing. Specifically with local agents: every AI I open up by default, even with Claude Code's built-in sandboxing, chances are it has access to my AWS, Docker CLI, kubectl, Terraform, and those keys are all already set up and it could just deploy to things. One of the things I'm trying to work on with some friends is where to draw a boundary around sandboxes. This almost feels like a perfect scenario — these MCP tools and skills, are maybe all in a Docker sandbox, which is more like a VM with a harness running inside it. I only use that particular harness because it has these particular permissions, and I only spin it up when I want to. It's almost like a per-environment configuration and each Docker sandbox has its own isolated configuration, including all your keys. So I'd have my prod harness, my staging harness, and I can interact with those environments and keep them safe away from my normal day-to-day harness. A lot of small teams have too many keys on their local machines — if you're a team of three, chances are you've got the production Terraform key on your machine. Now that we have agents, people are starting to get more concerned: what if it accidentally picks the wrong environment? Can OpenChoreo manage multiple clusters in one instance, or is it per cluster?

Lakmal Warusawithana: You can manage multiple clusters within one OpenChoreo.

Bret Fisher: So I almost treat it like an environmental gateway for my agents. I call this "production" and I have this Docker sandbox where the keys to production are only accessible from that sandbox. And maybe I'll also have some GitHub keys in there so my agents in that sandbox can write to the GitOps repo and make PRs for me. I'm now realizing how these things are coming together: I can have one local agent that can see the infrastructure through OpenChoreo, but can also implement GitOps changes based on the information it's getting out of that infrastructure. If the pods are in a pull-backoff loop, the agent can determine that, write the GitOps diff, push that to a PR, and that's how I'm going to be iterating on my cluster now. Or maybe I'm doing it in Slack while I'm at lunch through a Slack bot. Can we use a private LLM to interact with OpenChoreo instead of Claude Code?

Lakmal Warusawithana: Yes. It's not only Claude Code, it's your model, your choice. You can use any Codex or any other agent. It's just MCP servers you're interacting with. You can use any LLM in your local agent, and in the built-in agents you can also configure your LLM, OpenAI or whatever model you want to configure. It's a configuration for us.

Bret Fisher: Picking the model for the agents is a good thing because I've got a feeling we're going to need cheaper models for the cluster for the always-on activities. Does the agent have visibility into inter-cell dependency traffic, or is it completely blinded to anything outside its assigned project?

Lakmal Warusawithana: It depends on the different agent and what context it's interacting with. For example, the SRE agent, when troubleshooting, can go beyond one project, because some components interact with other components in other projects. If there are interactions, the agent can look at what's happening in those other components in other projects. Based on the context the agent is interacting with, it can go beyond a single project to multiple projects.

Bret Fisher: Just to be clear on the scope — it doesn't appear you're trying to boil the ocean and make OpenChoreo the single control plane for AWS, GCP, and all the other things we manage. It's trying to remain Kubernetes-focused, right? The lowest layer is Kubernetes, and I don't see clouds listed here.

Lakmal Warusawithana: We are running on top of Kubernetes. We are not even managing Kubernetes with OpenChoreo, we build on top of it. You can run OpenChoreo on EKS or AKS, but we are not managing EKS or AKS. That's how we architect it. But OpenChoreo has a resource abstraction where you can manage cloud resources within OpenChoreo. We have integrated with Crossplane, so the OpenChoreo control plane can talk with the Crossplane integration, and via Crossplane, it can create an S3 bucket in AWS and do the lifecycle management of that bucket. It provides a single unified control plane to manage it, but it's up to users if they want to use it that way.

Sameera Jayasoma: Just to add to that, there are multiple planes: control plane, data plane, observability plane. You can run each plane in its own Kubernetes cluster, or all planes in one cluster. You can run your control plane locally and your data plane in AWS. You can configure it the way you want. If the data plane is in AWS and the control plane is somewhere else, you don't have to expose the Kubernetes API server to the Internet, there's a certain agent running in the data plane that creates an outbound connection to the control plane. That's sort of the standard these days.

Bret Fisher: Basically, if you're going to use this to help manage something, it needs to be something running in Kubernetes, probably around the CNCF ecosystem of tooling. This isn't trying to replace Terraform or control CloudFormation or run other infrastructure. That gives me a nice boundary. When we talk about the future of what it means to be an SRE, a DevOps platform engineer, where do the edges of these tools exist? Sure, I could manage everything from Claude Code in theory, but I probably need very scoped things to keep it in line. Having this thing well defined as running on top of Kubernetes means things you can do in Kubernetes it can help with, but maybe it's not the right tool to do everything all in one place. There's a ton of context outside of Kubernetes it would need. At the end of the day we're going to have dozens of agents, and we're going to have an agent management plane where we're all just staring at agent configs and skill files; that's our new job. More markdown.

Getting Started & Wrap-Up 47:04​

Bret Fisher: How can people get started? Is this a Helm chart?

Sameera Jayasoma: Step one: you've got to have Kubernetes running somewhere. If you go to the openchoreo.dev documentation page, there are a couple of ways to get started. First, if you want to just try out OpenChoreo, we have a quickstart guide, you just need Docker. There's one command that will install Kubernetes in Docker and then install OpenChoreo on top. Once it's done you get a UI, you get MCP access, all that — it's just 10 minutes, it won't pollute your local environment, and you can just destroy it when you're done. The second option is to have a Kubernetes cluster on your local machine and install OpenChoreo there. The third option is to install OpenChoreo in cloud environments. That's how we've structured the getting started experience.

Bret Fisher: Does it have databases as part of its deployment — a Redis, or what does the persistence layer look like for those of us deploying this on our clusters?

Sameera Jayasoma: For the whole OpenChoreo control plane, the main persistent layer is etcd, whatever Kubernetes uses. For Backstage, you can configure Postgres or any other database that Backstage recommends. Apart from that, there's no other persistence.

Lakmal Warusawithana: For the SRE agent, you can configure it to save incident history and provide context in future incidents, you can configure Postgres or any other database for that.

Bret Fisher: These agents are doing things and we probably want a history of that. Is it logging through Kubernetes to my existing monitoring and logging platform? If I want to see what my agent did in the last 24 hours, do I just look at my normal monitoring and logging platform?

Lakmal Warusawithana: Yes, it does all the audit logging itself. Depending on the log module it can be OpenSearch with different indices for logs, what the agent did, what the human did, everything is tracked within the logs.

Bret Fisher: Are agents pulling infrastructure data in real time, or is there a caching layer you have to deal with to optimize in the OpenChoreo layer?

Lakmal Warusawithana: At the moment, it's real-time. We are not using any vector DB or caching. We give the agent a time interval context, "Within this time interval you have to pull the logs and metrics," and it will just look in that interval and get all the data to troubleshoot.

Bret Fisher: So once it sees an event, it already knows exactly when that event happened and can limit itself so that you're not burning a bunch of tokens by boiling the ocean and scanning every log to infinity. Does it need to look at Grafana graphs, or is it just doing Prometheus queries and getting data in real time?

Lakmal Warusawithana: It goes to the observability MCP server, it's querying through the MCP servers.

Sameera Jayasoma: This is directly from the observability MCP server talking to OpenSearch and getting the data.

Bret Fisher: So it's a little bit simpler than having to constantly store everything as a cache, which in theory would make the agent faster, but also has a lot of complexity and resource utilization. That gets back to the point that at some point everybody has that infrastructure where they realize they have a cluster with more resources used for the infrastructure than for the actual apps — you know, the app only costs $100 a month to run but the infrastructure costs $10,000 a day.

Bret Fisher: This has been very cool. I could talk to you for another hour about this because I'm really interested in the patterns and architecture design that you've learned. These are things we're going to have to do the same thing for our cloud infrastructure, our line of business apps, we're going to have to figure out how to give agents a deeper understanding of that infrastructure so we can depend on them more and rely less on the human tribal knowledge we all have about how these systems are put together. My friends call it "the sins of the data center" and this thing is going to have to know all that. Viktor Farcic, who runs the DevOps Toolkit channel, talks about how Claude Code is the center of the universe for him and that anybody creating a project that isn't expected to be local-harness-first is creating an outdated project. This feels like it's doing exactly what he was predicting over the last year, the harness is your gateway to all this infrastructure, and everything else needs to be there to support that. All right, people get started at openchoreo.dev and you're on LinkedIn, X, and CNCF Slack?

Lakmal Warusawithana: We have X and LinkedIn pages, and also the CNCF Slack channel. We actively engage there. And we use GitHub Discussions a lot.

Bret Fisher: I love GitHub Discussions. I wish they were used more rather than issues, a lot of things just need to start in discussions before they go to issues. Thank you both so much for being here. Last quick thing, what's next? What big PRs are coming down the pike?

Lakmal Warusawithana: More agents.

Sameera Jayasoma: More agents.

Bret Fisher: Could have guessed it. More AI overlords. Thank you so much for being here. Thanks everybody in chat for being with us and we'll see you in the next one.

Get Started with OpenChoreo​

OpenChoreo is open source and free to use. The best next step is to try it yourself.

• Check out the website
• Try out the quickstart guide
• Star the repository
• Join #openchoreo on Slack

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.