Modules
OpenChoreo is designed from the ground up as a modular Internal Developer Platform (IDP). Rather than coupling to a fixed set of tools, OpenChoreo defines clear integration points where operators can plug in the tools that best suit their organization.
What Are Modules?β
Modules are pluggable integrations that extend OpenChoreo platform capabilities at defined extensibility points. There are two main types of modules:
OpenChoreo Modulesβ
OpenChoreo Modules extend platform-defined extension points across OpenChoreo planes β the Data Plane, Build Plane, Observability Plane, and Control Plane. Each module integrates a third-party tool at one of these extension points, covering areas such as API Gateway, CI, Observability, and GitOps. Modules are packaged as Helm charts, making them straightforward to install and configure on any compatible Kubernetes cluster.
OpenChoreo modules are hosted in the openchoreo/community-modules repository. Some modules are used by default in the OpenChoreo installation, while others are community modules that operators can install to replace or supplement the defaults.
Curated Backstage Modulesβ
Curated Backstage Modules are Backstage plugins that have been validated and bundled into the OpenChoreo Backstage portal. These modules extend the developer portal experience with additional capabilities.
Unlike OpenChoreo modules, Curated Backstage Modules are not installed independently - they are compiled into the portal itself. To add a Curated Backstage Module, you fork the OpenChoreo Backstage portal, add the plugin, and build your own portal image.
You can discover all available modules in the OpenChoreo Modules Catalog.
Why a Modular Architecture?β
Internal Developer Platforms need to serve diverse organizations with different tool preferences, scaling requirements, and existing investments in specific tools and technologies. A prescriptive, monolithic platform forces operators into a single stack, even when parts of it conflict with tools they have already standardized on or built expertise around.
OpenChoreo adopts a modular architecture for three key reasons:
No vendor lock-in
Platform critical capabilities like API gateway, CI, observability, and GitOps are all pluggable. Operators choose the tools they trust and can swap them as the ecosystem evolves without rebuilding their platform.
Lean by default, extensible on demand
OpenChoreo ships with sensible defaults (kgateway, Argo Workflows, OpenSearch, Flux CD) so you can get started immediately. But you can replace or supplement these defaults with alternatives that fit your specific needs, avoiding unnecessary complexity for teams that don't require it.
Community driven ecosystem
Modules are maintained independently of the core platform. The community can build, publish, and maintain integrations without requiring changes to OpenChoreo itself. This keeps the core platform focused and stable while allowing the ecosystem to grow organically.
Extensibility Areasβ
OpenChoreo Modules and Curated Backstage Modules each target distinct extensibility areas. OpenChoreo Modules extend the capabilities of the OpenChoreo planes, while Curated Backstage Modules expand what the developer portal can offer.
OpenChoreo Module Areasβ
The following areas correspond to functional planes in the platform where OpenChoreo modules can be plugged in.
API Gatewayβ
The API Gateway layer routes external and internal traffic to components deployed in data planes. OpenChoreo supports any Kubernetes Gateway API compliant implementation, giving operators the freedom to choose their preferred gateway technology.
| Default module | kgateway - a high-performance, Envoy-based gateway, pre-configured as part of the standard data plane installation |
| Community modules | Kong Ingress Controller, Envoy Gateway, Traefik, Apache APISIX, WSO2 API Platform |
CIβ
The CI Plane provides infrastructure for building container images and running CI workflows. OpenChoreo build system supports different workflow engines through the ComponentWorkflow CRD, and also integrates with external CI systems.
| Default module | Argo Workflows - a Kubernetes-native workflow engine |
| Community modules | Tekton Pipelines; external systems such as GitHub Actions, Jenkins, and GitLab CI are also supported via External CI integration |
Observabilityβ
The Observability Plane aggregates logs, traces, and metrics from across all planes. Each observability signal has its own pluggable module, so operators can mix and match backends independently.
| Signal | Default module | Community modules |
|---|---|---|
| Logs | OpenSearch with Fluent Bit | OpenObserve |
| Tracing | OpenSearch with OpenTelemetry Collector | β |
| Metrics | Prometheus | β |
GitOpsβ
The GitOps module handles continuous delivery, keeping deployed workloads in sync with declarative configuration stored in Git. OpenChoreo's reconciliation controllers work alongside the GitOps engine to detect drift and trigger re-deployments.
| Default module | Flux CD - a CNCF graduated GitOps toolkit |
| Community modules | Argo CD |
Curated Backstage Module Areaβ
Curated Backstage Modules extend the OpenChoreo developer portal. The OpenChoreo Backstage portal ships with a curated set of built-in plugins, and operators can add more by forking the portal repository and bundling additional Backstage plugins.
Any plugin from the Backstage plugin marketplace can be contributed as a Curated Backstage Module - examples include cost visibility plugins, incident management integrations, API documentation renderers, and internal tooling portals.
See Backstage Configuration for details on setting up and customizing the developer portal.
Browsing Available Modulesβ
Visit the OpenChoreo Modules Catalog to browse all available modules by category, including their release status and links to installation guides.
To contribute a new module or integrate a tool not yet in the catalog, see Building a Module.