One Control Plane, Four Operators: What OpenChoreo's MCP Bet Teaches Self-Hosted PaaS Builders

In March 2026, two things happened at once: OpenChoreo entered the CNCF Sandbox and shipped its 1.0 release. Most of the announcement read like a standard internal-developer-platform checklist — Backstage portal, GitOps, observability, multi-environment promotion. But buried in the feature list was the line that actually matters: MCP servers for AI agent integration, plus a built-in SRE agent for root cause analysis. OpenChoreo is the first major IDP to treat an AI agent not as a chatbot bolted onto the dashboard, but as a fourth platform consumer standing next to humans, CLIs, and GitOps — all reading and writing the same Kubernetes system of record.

That is a bet every self-hosted PaaS builder should take seriously, because the agent that deploys your app at 2 a.m. needs the same things your on-call engineer needs: to know who it is, what depends on what, what it is allowed to change, and who can see what it did. Here is the verdict up front, scored against exactly those four requirements:

The short version: OpenChoreo nails the read path for agents and gives you the vocabulary for the write path, but the write path is still a kit, not a guarantee. The rest of this post replays one deployment through all four consumers to prove the "one system of record" claim, then turns the four rows above into a buildable checklist for any Render-compatible self-hosted PaaS.

OpenChoreo in 90 seconds​

OpenChoreo is an open-source (Apache 2.0), Kubernetes-native internal developer platform that started life as WSO2's Choreo and was donated toward vendor-neutral governance — accepted into CNCF Sandbox alongside the 1.0 release in March 2026, with a 1.1 release following in May adding a Cilium module for eBPF networking. WSO2 now sells a supported Developer Platform for OpenChoreo, including an AWS Marketplace listing — the classic open-core pattern, which at least signals someone intends to run this in production, not just demo it.

Architecturally it is a multi-plane system. The Experience Plane is where operators interact: a Backstage-powered console, a CLI, GitOps, and AI agents. The Control Plane sits in the middle, translating high-level intent into Kubernetes reality. The Data Plane is the workload clusters where tenant code actually runs. The Observability Plane collects metrics, logs, and traces and serves them back through platform abstractions. An optional CI Plane builds container images with Cloud Native Buildpacks and Argo Workflows. Crucially, OpenChoreo is not a Kubernetes distribution — it installs on top of clusters you already have, which is exactly the posture a self-hosted PaaS on rented bare metal wants from its tooling.

The numbers that matter: v1.0.0 in March 2026, v1.1 in May 2026, Sandbox maturity (explicitly not production-grade-certified — Sandbox means "promising, still proving itself"), and a docs corpus that already includes MCP server configuration guides, an SRE-agent tutorial path, and a resource-optimization sample that requires both MCP servers wired to an AI assistant. This is not a roadmap slide; the agent interfaces ship.

The system of record: components, traits, and bindings​

Every consumer sees the same model, so the model is worth stating precisely. Platform engineers define component types (what kinds of things can exist: web service, database, scheduled job) and traits (capabilities attached to a component: an observability-alert-rule trait, a public endpoint, scale-to-zero behavior). Developers declare components — an instance of a type with traits attached — grouped into projects, promoted across environments (dev, staging, prod) via ReleaseBindings that carry per-environment trait configuration.

Three properties make this agent-legible in a way raw Kubernetes is not. First, the dependency graph is explicit: components declare dependencies on each other instead of hiding them in environment variables and connection strings, so "what breaks if I restart the database" is a query, not an investigation. Second, environment differences live in one place — the ReleaseBinding's trait overrides — instead of being scattered across overlays, Helm values, and tribal knowledge. Third, operational state is part of the model: alert rules are traits on the component they guard, and firing alerts become incidents persisted in the observability plane, queryable through the Observer API from the portal or the MCP server. An agent asking "is checkout-api healthy, and what changed?" gets a structured answer from the same objects a human clicks through in Backstage.

The honest caveat: this is still Sandbox software. Component types and traits are powerful but young — expect breaking schema changes, thin upgrade tooling, and rough edges where the docs outrun the implementation. Adopt the pattern (typed components, trait-scoped config, incidents as records) even if you hesitate on the dependency.

One deployment, four operators​

The "one system of record" claim is only real if the same deployment is operable from every surface without translation loss. Take a canonical workload: a checkout-api web service with a Postgres dependency, an observability-alert-rule trait watching p95 latency, and a ReleaseBinding promoting it from staging to prod. Here is that deployment through each of OpenChoreo's four consumers:

• Portal (human). The Backstage-powered console renders the component, its dependency edge to Postgres, its environment promotion state, and its alert rules in one view. This is the reference rendering — what the operator sees is the model, not a projection of it.
• CLI (human, scripted). The same component lifecycle — create, bind to an environment, promote — is available as commands. Scripts and runbooks speak the same nouns as the portal, so a runbook step and a click path cannot drift apart.
• GitOps (machine, declarative). Component definitions, trait configs, and ReleaseBindings live in git; the control plane reconciles toward them. This is the surface that makes the audit story work: every intended-state change has a commit, an author, and a diff.
• MCP (agent). Two servers split the world the way the planes do: the Control Plane MCP server exposes components, environments, and deployments (the "what should exist" side), while the Observability Plane MCP server exposes metrics, alerts, and incidents (the "what is actually happening" side). The resource-optimization sample shows the intended loop: an agent reads right-sizing recommendations from observability state and applies them through control-plane operations. And the built-in SRE agent closes the loop on failure: when an alert rule with incident creation and AI RCA enabled fires, the agent analyzes the incident and writes a root cause report back into the observability plane — visible in the portal, no separate tool required.

That last point is the one to steal. Most "AIOps" products analyze in a silo and paste conclusions into Slack. OpenChoreo's RCA writes its conclusions back into the system of record, where the next consumer — human or agent — can build on them. Investigation compounds instead of evaporating.

But notice what the four-surface tour does not show: an agent promoting checkout-api to prod on its own authority. Reading state through MCP is a solved problem in this architecture. Writing state through an agent is where the four checklist items stop being features and start being obligations.

The checklist, split where it matters: read vs. write​

The TODO spec names four things an agent needs — identity, dependency graph, policy, audit trail — but they do not all bite at the same time. Investigating (read) is a much lower bar than changing (write), and a platform should open the two in stages. Here is each requirement, split accordingly and mapped to its OpenChoreo primitive:

Investigate: let the agent read everything, with an identity.

• Identity. The agent needs a stable caller identity with scoped read access — not the cluster-admin kubeconfig someone pasted into its environment. OpenChoreo's Observer API authenticates and authorizes per user, and the MCP servers carry caller context, so "the deploy-agent may read incidents in staging" is expressible. Buildable rule: one service identity per agent role, read-only grants, no shared tokens.
• Dependency graph. Components and their declared dependencies give the agent the blast-radius map for free: restarting Postgres touches checkout-api and nothing else. The test is whether the agent can answer "what depends on this?" without shelling out to grep across a dozen repos. In OpenChoreo's model, it can.
• Audit trail (read side). Past incidents and their RCA reports are queryable records, so the agent starts an investigation with history instead of a cold dashboard. "Has this latency spike happened before, and what fixed it last time?" is the highest-leverage question an agent can ask, and it only works if conclusions were written back into the record — which the SRE agent does.

Change: earn the write path one gate at a time.

• Policy. Traits constrain the shape of a component (this service gets an alert rule, that one gets a public endpoint), but shape is not permission. Before an agent may mutate anything, the platform needs approve-before-mutate semantics: the agent proposes a ReleaseBinding change, a human or a policy engine approves it, and only then does reconciliation proceed. OpenChoreo gives you the vocabulary (environment configs, bindings) but not the gate — that gate is your homework, whether it is a GitOps pull-request check, an admission policy, or a promotion freeze during incidents.
• Dependency graph (write side). Reads use the graph for understanding; writes use it for blast-radius computation. A proposed change should render its affected set — components, environments, downstream dependents — before it applies. The model makes this computable; the platform must make it mandatory in the agent's tool contract (no apply call without an affected-set preview).
• Audit trail (write side). GitOps is the honest audit log: if the agent's change lands as a commit, authorship, diff, and revert come free. The rule is absolute — no direct-to-API agent writes that bypass git. Every mutation the agent performs must be a pull request (or the platform's equivalent proposal object) with the agent's identity on it, so git log answers "who changed prod?" even when who is software.
• Identity (write side). Write credentials must be narrower than read credentials and short-lived: per-task, per-environment, expiring. An agent that can read all of staging should only ever hold a write token for the one component it was asked to fix.

Notice the asymmetry the verdict table previewed: three of the four read gates come largely for free from the architecture, while all four write gates require platform-team work on top. That is the correct way to read OpenChoreo's "AI-native" label — it ships the read path and the data model the write path needs, not the write path itself. Any vendor telling you agents can safely change production on day one is selling you the table without the gates.

What this means for a self-hosted, Render-compatible PaaS​

Map this onto a platform like Bex.co — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API. The Render API is already a machine-readable contract for Create Service, Deploy, List Deploys, Get Logs; adding an MCP surface next to it is the natural third interface, and OpenChoreo's two-server split is the right shape to copy: one server over intended state (services, environments, deploys), one over observed state (metrics, logs, incidents). The dependency graph is smaller than OpenChoreo's — services and datastores rather than arbitrary component types — which makes the affected-set preview cheaper to build. And the GitOps write rule maps directly: agent-proposed changes land as commits or deploy proposals, never as silent API mutations.

The caveats travel too. Sandbox maturity means watching, not vendoring, the implementation — but the pattern (explicit component graph, traits-as-guardrails, incidents as queryable records, RCA written back into the record) ports cleanly onto a Cluster API fleet without importing a single CRD. The deepest lesson is organizational, not technical: the team that models its platform so an agent can operate it has also modeled it so a new hire can understand it. Agent-legibility and human-legibility are the same property — a single system of record with named things, declared dependencies, and recorded history. OpenChoreo just happened to build it agent-first, which is why it is worth studying even if you never install it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources and further reading​

• OpenChoreo 1.0 + CNCF Sandbox announcement and the CNCF Sandbox proposal
• OpenChoreo v1.0.0 release notes — abstractions, programmable control plane, MCP servers, SRE agent
• MCP servers configuration guide and the resource-optimization MCP sample
• Observability and alerting guide — alert-rule traits, incidents, AI RCA
• WSO2 Developer Platform for OpenChoreo 1.0 (SD Times) and the v1.1 release with Cilium