OpenChoreo just shipped v1.2.0, and it is a big one. We are talking about a release that fundamentally changes how infrastructure is managed, adds AI-assisted debugging, lets you shell into running components from your browser, secures everything with mutual TLS, and introduces scale-to-zero workloads. This is not a patch release. This is a platform evolution.
Think of OpenChoreo as the control tower for your cloud-native applications. It is an internal developer platform (IDP) built on Kubernetes and Backstage that lets platform engineers define how applications get deployed, secured, and observed across multiple environments — without writing hundreds of lines of Helm and Kustomize. Developers just push code, and OpenChoreo handles the rest: building, deploying, routing traffic, wiring up observability, and now, even helping troubleshoot when things go sideways.
If you have ever spent an afternoon debugging why a namespace was missing a NetworkPolicy or why two teams’ workloads could talk to each other when they absolutely should not, OpenChoreo exists to make that problem disappear. It is built for platform teams who manage multi-tenant Kubernetes environments and want to give developers self-service without losing control.
So why should you care about v1.2.0 specifically? Because it introduces a Project Release Lifecycle that treats shared infrastructure as versioned, immutable artifacts — the same way you already version your application code. Plus interactive shell access, mTLS-secured communication, KEDA-powered scale-to-zero, and Cilium Hubble integration for deep network observability. Let us get into it.
What Is New in OpenChoreo v1.2.0
Project Release Lifecycle: Infrastructure as Versioned Artifacts
This is the headline feature, and for good reason. In v1.2.0, OpenChoreo introduces a completely new way to manage project-scoped infrastructure — things like cell namespaces, NetworkPolicies, ResourceQuotas, and RBAC bindings. Instead of these resources being implicitly created and mutated at deployment time, they are now captured as versioned, immutable snapshots that can be promoted across environments.
Why does this matter? Because it brings the same GitOps discipline you apply to application manifests to the shared infrastructure layer. You can now review exactly what infrastructure a project needs, diff changes between versions, and promote a known-good configuration from staging to production with confidence.
spec:
type: # NEW — required, immutable
kind: ClusterProjectType # defaults to ProjectType if omitted
name: defaultEvery Project must now reference a (Cluster)ProjectType, which defines what infrastructure gets provisioned. A default ClusterProjectType that provisions only the namespace ships with the release, so you can start simple and customize later. See PR #4167 for the CLI commands, PR #3874 for the API endpoints, and PR #3918 for ProjectReleaseBinding support.
Shared infrastructure is now treated as a first-class, versioned artifact — not a side effect of deploying a component.
Shell Access for Components: kubectl exec Without the kubectl
You know the feeling. A container is misbehaving in production. You need to run a quick diagnostic command. So you context-switch to your terminal, figure out which pod it is, which container, construct the right kubectl exec invocation, and pray you are pointing at the right cluster. v1.2.0 eliminates that dance.
You can now open an interactive shell session directly to a running component instance from the Backstage portal. Click a button, get a terminal. It supports optional pod targeting too, so you can pick a specific pod when you have replicas spread across nodes. See PR #3887 for the implementation and PR #3974 for environment-conditionable exec.
Enhanced Security: mTLS and Smarter ABAC
Security got a serious upgrade. Internal communication between components and the Cluster Gateway is now protected with mutual TLS (mTLS), meaning both sides of the connection verify each other’s identity before exchanging a single byte of data. No more relying on network-level trust assumptions for intra-platform traffic.
On top of that, ABAC policies now support authorization conditions based on resource type, component type, and workflow. This means platform administrators can write fine-grained access rules like “only allow deploys of service components to the production environment” without resorting to coarse-grained role assignments. See PR #4256 for the mTLS implementation.
Scale-to-Zero and Smarter Scheduling
Two platform improvements that platform engineers will immediately appreciate:
- KEDA-powered scale-to-zero — Workloads can now automatically scale to zero when idle, saving real money on underutilized compute. The controller was also improved to poll scaled-to-zero workloads more aggressively so scale-up feels instant when traffic returns. See PR #4308.
- Helm affinity and topology spread constraints — You can now configure workload scheduling using native Kubernetes affinity rules and topology spread constraints, giving you control over how pods distribute across zones and nodes. See PR #4232.
Advanced Observability: Kubernetes Events and Cilium Hubble Integration
Debugging distributed systems is hard enough without having to leave your portal to check Kubernetes events or dig through network flow logs. v1.2.0 surfaces Kubernetes events and Cilium Hubble wire logs directly through the Observer API and the Backstage portal. You can now see exactly what the Kubernetes API server is telling you about your workloads and trace network traffic between components — all without switching tools.
Portal Assistant: AI-Powered Troubleshooting
When a build fails or a deployment crashes, the new Portal Assistant provides automated suggestions to help you troubleshoot the issue. It analyzes build and runtime logs and surfaces likely causes and fixes. Behind the scenes, agent LLM calls are now routed through an OpenAI-compatible gateway, so you can plug in your own model provider of choice. See PR #3779.
Breaking Changes: Read This Before Upgrading
v1.2.0 introduces breaking changes that require a staged migration from v1.1.x. This is not a plain Helm upgrade.
- Project.spec.type is now required and immutable — Every Project must reference a
(Cluster)ProjectType. If you have existing Projects from v1.1.x, they need aspec.typebackfill before installing the strict v1.2.0 CRDs. Installing the CRDs first will halt control-plane reconciliation for all existing projects. - Projects must be deployed before their components — The namespace is now part of the project’s released manifests, applied through the Project Release Lifecycle. Existing migrated projects are not affected — the binding’s RenderedRelease adopts the existing namespace rather than recreating it.
The migration is reversible — see the v1.1 to v1.2 upgrade guide for full step-by-step instructions and rollback procedures.
Other Notable Improvements
- Webhook signature verification is now enforced across all Git providers, closing a gap where forged webhook payloads could trigger unauthorized builds. See PR #4239.
- OpenAPI and GraphQL API try-out directly from the Backstage portal — test your APIs without leaving the platform.
- Redesigned deployment workflow — browse and compare releases, review configuration diffs, and manually trigger CronJob releases.
- Workflow template parameter injection was hardened to prevent shell injection attacks in Argo workflows.
Closing
OpenChoreo v1.2.0 is the release where an internal developer platform grows up — versioned infrastructure, AI-assisted debugging, browser-based shell access, mTLS everywhere, and scale-to-zero savings. If you are building a platform on Kubernetes, this is your sign to take a serious look.
