The self-service marketplace of your platform. The platform team publishes, developers — and their AI agents — help themselves; every order approved and on record.
Not a framework to build, not a SaaS to rent: a product that runs on your cluster, on the open source you already use.
A homemade request form, an approval flow in Slack, passwords copied by hand, a spreadsheet that calls itself a catalog. The tools underneath are excellent. The piece that turns them into a service for developers doesn't exist.
Backstage is a framework: it shows a list of what exists, and everything else is a plugin to write. Port and Humanitec are products, but closed, paid, and your platform data is not at home.
Crossplane, kro, Terraform, Helm can build anything. None of them knows what a product, an approval, or a delivered password is.
The layer in between: the marketplace, the approval, the delivery and the record. A product, not a framework. Runs on your own cluster, open source, on the engines above.
| Side by side | Backstage | Port | Humanitec | Crossplane · kroengines | Yonn |
|---|---|---|---|---|---|
| Open source | yes | no | partial | yes | partial |
| Control plane on your cluster | yes | no | partial | yes | yes |
| A product, not a framework | no | yes | yes | no | yes |
| Lifecycle with approvals and reasons | no | partial | partial | no | yes |
| Secrets delivered to the consuming app, never copied | no | no | yes | partial | yes |
| Everything a Kubernetes resource, no hidden database | no | no | no | yes | yes |
| Brings existing workloads in, no big bang | partial | partial | partial | partial | yes |
| AI agents as governed users, proven | no | partial | no | no | yes |
Read from public documentation in September 2026; “partial” means it exists with a caveat — a plugin, an enterprise option, a spec without the runtime. Yonn's own “partial”: Apache 2.0, code public in November 2026 — see Open source. Yonn is not a replacement for the engines: it orders through them. If we got a cell wrong, write to [email protected] and we will fix it.
A developer orders from a menu the platform team wrote. What comes back is delivered to the app — not to a ticket queue.
apiVersion: catalog.yonn.io/v1alpha1 kind: ServiceOrder metadata: name: orders-db namespace: team-payments spec: # which product, from the catalog catalogEntryRef: postgres-ha # which team is ordering projectRef: payments # which app receives the result consumerRef: serviceAccountName: orders-api parameters: tier: small
Each item on the menu has a version, sensible defaults and limits. Developers choose within the paths the platform team certified — they don't write infrastructure.
Requested, approved, being built, ready, retired. A rejection carries a reason. Deleting leaves nothing behind. If someone edits the resource by hand, Yonn notices and repairs it.
Settings land next to the app, ready to use. Passwords go only to the app that needs them. An order that would produce a secret with nobody to receive it is refused.
Everything in Yonn is a Kubernetes resource — every one of them, one API, no hidden database. Orders can come from the web app, the command line, or a Git commit. Read the CRD reference →
Every release has to pass the same twenty-one scenarios, run on a live cluster by scripts that clean up after themselves. A status is a dated observation, not a promise.
| # | Scenario | Status |
|---|---|---|
| 1 | Install from the README to a working platform | proven |
| 2 | A team gets a TLS certificate without opening a ticket | proven |
| 3 | A request is approved — or rejected with a reason | proven |
| 4 | Decommissioning leaves nothing behind | proven |
| 5 | Upgrade Yonn while orders are live | proven |
| 6 | Two teams share one cluster without seeing each other | proven |
| 7 | A connection fails mid-order and recovers | proven |
| 8 | Someone hand-edits a provisioned resource; Yonn repairs it | proven |
| 9 | Audit: who ordered what, approved by whom | proven |
| 10 | An AI agent operates Yonn with no human help | proven |
| 11 | Connect your own Azure subscription — no stored password | in progress |
| 12 | An operator with limited cloud rights connects AWS | next |
| 13 | An app reads its settings without anyone copying them | proven |
| 14 | A team orders by pull request | next |
| 15 | An organisation rule refuses an order | next |
| 16 | A developer adds a service to their workload | proven |
| 17 | A service handed over to a team outside Yonn | proven |
| 18 | An existing workload is brought in and bound | proven |
| 19 | The platform measures its own adoption | proven |
| 20 | Assisted adoption: a plan and a pull request | proven |
| 21 | The assistant drafts, a human approves | proven |
Three of these runs found real bugs before a customer did — an identity that could be faked through the API, a repair that left no trace, a scenario a refactor had quietly broken. That's what the bar is for.
AI shows up twice in a platform: as a new kind of user that asks for infrastructure, and as a new kind of application that needs it. Yonn treats both the way it treats a person and a database — and keeps AI out of the one place it doesn't belong.
An AI agent asks through the same door as an engineer, and gets the same marketplace, the same approval, the same audit line. Scenarios 10 and 21 — an agent running Yonn on its own, the assistant drafting for a human — are on the list.
Model endpoints, vector databases, agent runtimes — ordered like any database: an identity per environment, network kept private, keys delivered only to the app that uses them, every change recorded. The safest way to ship AI fast is to put it on the menu.
Ask Yonn: a request in plain words becomes a draft order, signed by the assistant, approved by a person. It never builds anything on its own. Fleet questions — “which services still run the old blueprint” — and help writing blueprints are the enterprise roadmap.
The line we hold: “the AI did this to your production database” is not a sentence a customer should ever have to say. Governance first is what makes the speed safe.
The split follows the architecture: the marketplace is open source; off-the-shelf products and the certified path from an empty cloud account to a production service are what we will sell.
Publishing and governance. Your platform team puts what developers need on the menu — a database, a certificate, an environment, a repository — built with whichever engine speaks the Kubernetes API, and Yonn makes each one a product: a form, an approval, a delivery, a record. The menu is yours to write; off-the-shelf products are the enterprise tier.
Everything above, plus off-the-shelf certified products and the governed path from a blank cloud account to a production service. Designed, not built yet — the dated line below says where it stands.
Source. Apache 2.0. The code is private while it is readied for publication — history, dependencies, security policy; public in November 2026. Read access on request until then: [email protected].
Self-hosted by design. A regulated company keeps its control plane and its audit trail; we sell the certified path, not a lock-in.
First release. Catalog, orders, lifecycle, delivery, audit — declared on a clean install from the README.
Beta. Settings delivered straight to the app; the thirteen scenarios become the acceptance bar, with scripts that clean up.
Cloud foundations — Azure. Yonn connects to an Azure subscription without storing any password: the cluster proves its own identity and Azure trusts it. Live proof on a real subscription in progress.
Adoption. An existing workload is brought onto the golden path without a rewrite: a plan, a pull request, and the platform measuring what it has won over.
The platform assistant. Ask Yonn in plain words; it drafts an order under its own name and a person approves. Proven on the lab, scenario 21.
Azure and AWS on real accounts, then the onboarding wizard. Provider families installed per service, only the resources you order; a wizard that hands an operator the exact commands to run, even with limited rights.
Source published. The repository opens under Apache 2.0 once the publication review is done; the licence, contributor agreement and notices are already in place.
Enterprise provisioner. Certified blueprints, compliance in view — the paid tier.
AI on the menu. Model endpoints, vector databases, agent runtimes — governed like any other service.
Yonn comes from years of platform engineering in organisations where every change has to be accounted for, and from an active presence in the cloud-native ecosystem — KubeCon, the CNCF projects it builds on, tools evaluated as they ship. The product encodes what that practice teaches: a platform is adopted when ordering is simple, approval is explicit and every secret has one owner. Yonn is built in the open, on a dated roadmap, every scenario proven before it is announced. Questions, a demo, a read of the code: [email protected].