If you have spent serious time with Kubernetes, you know the feeling. Self-healing workloads. Declarative state management. Network policies enforced at the kernel level. A rich CNCF ecosystem that composes cleanly. Kubernetes is genuinely one of the most capable pieces of infrastructure the industry has ever produced.
And then a developer asks you how to deploy a new service.
And you realise the path from “I wrote a microservice” to “it is running in production with observability, ingress, and environment-aware config” involves six or seven separate tools that your team has to wire together, maintain, and explain to every new engineer that joins.
That is the gap OpenChoreo fills. Not by replacing Kubernetes, but by sitting on top of it as the product layer your developers actually interact with.
<h2>What Kubernetes Gives You</h2>
The primitives are excellent. Deployments, StatefulSets, CronJobs. Declarative reconciliation that continuously drives toward your desired state. eBPF-level network policy enforcement with Cilium. CRDs and operators that let you extend the API with your own abstractions. Health checks and readiness probes that plug directly into the workload management loop.
The problem is that they are primitives. They are too low-level for most developers to work with directly, and building the abstraction layer on top of them is a full-time job most organisations have not staffed explicitly.
<h2>The Hidden Tax</h2>
Here is what platform teams actually end up building when they want to give developers a good experience on Kubernetes.
A developer portal. A CI pipeline per service. A GitOps workflow so changes go through Git and not someone’s laptop. An observability stack wired together from Prometheus, Grafana, and Loki. An ingress strategy with TLS and environment-aware routing. A promotion workflow for moving workloads from dev to staging to production without it being a manual process.
Each of these is solvable. The issue is that solving all of them together, keeping them coherent, and maintaining that as underlying tools evolve is a significant ongoing investment. Most platform teams are doing this while also being on call and onboarding new services.
OpenChoreo is the argument that this layer should be built once, open source, and shared.
<h2>OpenChoreo’s Architecture: Kubernetes All the Way Down</h2>
OpenChoreo is not an abstraction that hides Kubernetes. It is a set of higher-level abstractions that compile down to Kubernetes resources. Every component you deploy becomes a Deployment, a Service, network policies, ingress rules. The platform generates and manages those resources so you do not write them by hand.
It is built around four planes that each handle a distinct concern:
The Control Plane watches developer- and platform-defined CRDs and translates intent (“deploy this component to staging”) into concrete Kubernetes resources.
The Data Plane is your cluster, where Cilium enforces workload isolation and traffic policies at the eBPF level.
The Observability Plane collects logs, metrics, and traces via Fluent Bit into OpenSearch and surfaces them through a unified Observer API. Every component gets this automatically, no per-service wiring needed.
The Workflow Plane handles builds with cloud-native Buildpacks and Argo Workflows and is modular if you already have a build system you prefer.
On top of this, developers work with four abstractions: components (the unit of deployment, one per service), projects (the logical boundary for a team or domain), endpoints (how components expose functionality with visibility controls), and dependencies (how components declare what they consume, resolved by the platform per environment).
At runtime, each project becomes a Cell: a secure, isolated unit enforced by Cilium and eBPF where components within the same cell communicate freely and all external traffic flows through well-defined paths. The boundary is not a convention in your application code. It is a network policy the infrastructure guarantees.
<h2>What This Looks Like in Practice</h2>
We built an eight-service e-commerce platform to test this: user, product, cart, order, payment, notification, review, and a React frontend. Three storage types. Five services coordinating in a single checkout flow.
In raw Kubernetes, <code>order-service</code> needs hardcoded or manually managed addresses to reach <code>cart-service</code>, and those addresses differ between environments. With OpenChoreo, it declares a dependency and the platform injects the correct address for wherever you are deploying. Staging talks to staging. Production talks to production. You do not manage that mapping.
Observability across the checkout flow, logs and traces for all five services in one view, happens automatically because every component is enrolled in the observability pipeline at deploy time. Storage backing for four Postgres instances and one Redis is provisioned and wired per environment. Environment promotion goes through the platform, not through a manual diff of staging and production manifests.
And if your workloads do not fit the standard component types (services, workers, cron jobs), you can define custom component types through configuration, not custom code. They get the same observability, GitOps wiring, and environment support as everything built in.
<h2>The Trade</h2>
Building this yourself on raw Kubernetes is absolutely possible. Backstage for the portal, Argo CD for GitOps, Argo Workflows for CI, Prometheus and Grafana for metrics, Cilium for network policies, Envoy for routing. Teams do it every day. The question is whether assembling and maintaining all of that is the best use of your platform team’s time, or whether you would rather start from a working foundation and extend it for your specific needs.
OpenChoreo gives you that foundation. The planes are there. The abstractions are there. The extension model means you are not locked into decisions that do not fit your organisation. And because it is open source, you own it in the way that matters: you can see what it is doing, contribute to it, and run it on your own infrastructure.
Kubernetes’ power is real. OpenChoreo is what makes that power accessible to the rest of your team.
Go try it. Fork the repo, spin it up against your own workloads, and see how far the defaults get you. If it clicks, star it and share it with someone on your team who is still writing manifests by hand.
OpenChoreo docs:<a href="https://openchoreo.dev/" target="_blank" rel="noopener nofollow">https://openchoreo.dev/</a>
The repo is here: <a href="https://github.com/openchoreo/openchoreo" target="_blank" rel="noopener nofollow">github.com/openchoreo/openchoreo</a>

savi saluwadana

OpenChoreo is an open-source internal developer platform that sits on top of Kubernetes, providing higher-level abstractions that compile down to Kubernetes resources. It addresses the hidden tax platform teams pay when building developer experience layers from scratch — portals, GitOps workflows, observability stacks, ingress strategies, and promotion pipelines. The platform is organized into four planes (Control, Data, Observability, Workflow) and exposes four developer abstractions: components, projects, endpoints, and dependencies. At runtime, projects become isolated Cells enforced by Cilium and eBPF. A demo with an eight-service e-commerce app shows automatic observability enrollment, environment-aware dependency injection, and storage provisioning without manual manifest management. The argument is that assembling Backstage, Argo CD, Prometheus, Grafana, and Cilium yourself is possible but costly — OpenChoreo offers a pre-integrated, extensible, open-source foundation instead.

Kubernetes Is the Foundation. OpenChoreo Is What You Build on Top of It.