openchoreo

openchoreoApache-2.0活跃维护

基于 Kubernetes 的内部开发者平台,把 CI/CD、GitOps、可观测性和 AI Agent 能力整合成一套自助式开发环境,让平台团队统一管理服务交付流程。

OpenChoreo is an internal developer platform for Kubernetes

v1.3.3发布于 2026-10-29 06:42 UTC1,870star +32 / 7 天285fork同步于 2026-11-10 17:48 UTC

怎么上手

由 README 提炼,执行前请确认
README 未给出具体安装命令,仅指向 Quick Start Guide(Dev Container 方式)与 k3d 本地安装文档
硬件要求按 README 说明

README 未说明

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

面向 Kubernetes 的开源内部开发者平台,把开发者意图翻译成平台资源

基于 Kubernetes 的内部开发者平台,把 CI/CD、GitOps、可观测性和 AI Agent 能力整合成一套自助式开发环境,让平台团队统一管理服务交付流程。

核心能力

  • 用 Component、Endpoint 等高层抽象屏蔽 K8s 底层原语
  • 提供 Backstage 驱动的开发者门户与 CLI 自助入口
  • 内置 CI 与 GitOps,默认用 Buildpacks 和 Argo Workflows 构建
  • 按控制面、数据面、可观测面、CI 面多平面架构拆分职责
  • 用 Kubernetes CRD 定义 ComponentTypes、Traits 等平台黄金路径

容易踩的坑

README 未给出安装命令,需按官网 Quick Start 用 Dev Container 或 k3d 部署;CI 面为可选组件,默认依赖 Buildpacks 与 Argo Workflows;需先具备可用的 Kubernetes 集群

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v1.3.3
  1. v1.4.0-m.2pre-release2026-11-06 · 2026-11-06 16:11 UTC
    查看更新说明

    What's Changed

    Full Changelog: https://github.com/openchoreo/openchoreo/compare/v1.4.0-m.1...v1.4.0-m.2

  2. v1.4.0-m.1pre-release2026-10-29 · 2026-10-29 13:41 UTC
    查看更新说明

    What's Changed

  3. v1.3.3最新正式版2026-10-29 · 2026-10-29 06:42 UTC

    What's Changed

    Full Changelog: https://github.com/openchoreo/openchoreo/compare/v1.3.2...v1.3.3

  4. v1.1.92026-10-23 · 2026-10-23 13:06 UTC
    查看更新说明

    What's Changed

    Full Changelog: https://github.com/openchoreo/openchoreo/compare/v1.1.8...v1.1.9

  5. v1.2.82026-10-23 · 2026-10-23 09:12 UTC
    查看更新说明

    What's Changed

    Full Changelog: https://github.com/openchoreo/openchoreo/compare/v1.2.7...v1.2.8

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    License FOSSA Status CNCF Sandbox Twitter Follow Slack

    OpenSSF Best Practices OpenSSF Scorecard CLOMonitor LFX Health Score

    Build and Test E2E Tests Codecov GitHub Release GitHub last commit GitHub issues

    Why OpenChoreo?

    Kubernetes gives you powerful primitives like Namespaces, Deployments, CronJobs, Services, and NetworkPolicies, but they're too low-level for most developers. Platform engineers end up building the actual platform from scratch: defining higher-level abstractions, wiring together tools for delivery, security and observability, and maintaining all of it as an in-house product.

    That means stitching together a developer portal, CI pipelines, GitOps workflows, an observability stack, and access controls and then owning the glue between them indefinitely. The result is a fragile, bespoke system that's expensive to maintain and hard to evolve.

    Developers and platform engineers need different things from the same platform. Developers want a simple, self-service experience. Platform engineers want control over what's running underneath. Most DIY platforms end up optimizing for one side at the expense of the other.

    What is OpenChoreo?

    OpenChoreo, now a CNCF Sandbox project, takes a different approach. Instead of giving you a toolkit to assemble your own platform, it provides a complete, open-source developer platform for Kubernetes with abstractions that translate developer intent into platform reality. So platform engineers don't have to reinvent the wheel, and developers get a self-service experience that stays out of their way.

    Under the hood, OpenChoreo brings together a Backstage-powered developer portal, built-in CI and GitOps, observability, RBAC, and analytics and all of them are organized across dedicated control, CI, data, and observability planes. Platform engineers get a production-ready foundation they can operate and extend, not scaffolding they'll eventually replace.

    OpenChoreo was originally developed by WSO2, based on its experience building the SaaS internal developer platform formerly known as WSO2 Choreo (now WSO2 Developer Platform), bringing its core ideas to the open-source community. It's not a fork or an open-source dump; it's a complete rewrite based on what we learned from Choreo’s users over the years.

    How does OpenChoreo work?

    OpenChoreo is built around a multi-plane architecture, where each plane handles a distinct concern and operates independently.

    • 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. It takes developer intent and platform intent expressed through high-level abstractions like components, endpoints, dependencies, environments, pipelines, and namespaces and translates them into the underlying Kubernetes resources. It also reflects runtime reality back up, so what developers see always matches what's actually running.

    • 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.

    At the center of this is a set of opinionated abstractions. Developers work with components (services, workers, cron jobs, and other types defined as component types), expose functionality through endpoints, and declare dependencies on other endpoints or resources. Platform engineers control what component types are available, what traits can be applied, and how workloads behave, through configuration, not custom code.

    The result is a clear separation of concerns: developers express what they want to run, the control plane figures out how to run it, and platform engineers govern the boundaries.

    Underpinning all of this is the Platform API. It is a set of Kubernetes CRDs that let platform engineers declaratively define the structure and behavior of the entire platform. Instead of writing custom controllers or glue scripts, you configure organizational boundaries, environments, data planes, deployment pipelines, and observability through familiar Kubernetes-native resources. The Platform API also includes programmable abstractions like ComponentTypes, Traits, and Workflows that let platform teams define golden paths for their developers, encapsulate best practices, and enforce organizational standards. Together, they enable OpenChoreo's approach to policy, security, and governance by design.

    The diagram below illustrates some of the core concepts of the Platform API and how they relate to each other. It represents one possible platform topology, not a prescribed structure.

    Getting Started

    The easiest way to try OpenChoreo is by following the Quick Start Guide. It walks you through setting up OpenChoreo using a Dev Container, so you can start experimenting without affecting your local environment.

    For a deeper understanding of OpenChoreo's architecture, see OpenChoreo Concepts.

    Visit Installation Guide to learn more about installation methods.

    Samples

    Explore hands-on examples to help you configure and deploy your applications using OpenChoreo.

    Check out the Samples Directory for more details.

    Join the Community & Contribute

    We’d love for you to be part of OpenChoreo’s journey! Whether you’re fixing a bug, improving documentation, or suggesting new features, every contribution counts.

    We’re excited to have you onboard!

    Roadmap

    We maintain an OpenChoreo Roadmap as a GitHub project board to share what we’re building and when we expect to deliver it.

    The roadmap is organized by calendar quarters, and each column represents a set of features or enhancements planned for that period. This allows contributors, adopters, and maintainers to understand what’s coming up and what’s already being worked on.

    How It Works

    • Quarterly columns: Group features by when we aim to deliver them (e.g., 2025 Q2 – Apr–Jun).
    • Future column: Tracks ideas or initiatives we intend to explore but haven’t scheduled yet.
    • Each card links to a GitHub issue with context and discussion.
    • We continuously update the roadmap as priorities evolve, and completed features may remain in their quarter for historical visibility.

    OpenChoreo Roadmap

    License

    OpenChoreo is licensed under Apache 2.0. See the LICENSE file for full details.

    FOSSA Status