// how it works

One object model. Operators that keep it true.

Most platforms hand you primitives and ask you to compose the rest. Ybor hands you a layered object model, Kubernetes operators that reconcile it, and an addon catalog that runs on every cluster. Here's the shape of the system.

Book a demo Read the architecture docs

Object modelEnterprise → Cluster
OperatorsReconcile every entity
Addon catalogOn every cluster
GitOpsGit is the source of truth

object model · desired state

Enterpriseacme

Organizationmfg

PlatformApplicationpayment-processor

DEVSTGPRD

scheduled on

azure-01DEV · STG

azure-02PRD

operators reconcile

Enterprise · Organizationplatform-organization-operator

Environment · PlatformClusterplatform-cluster-operator

PlatformApplicationplatform-application-operator

AddOninstallation-operator

// object model

The object model: Enterprise to Cluster.

Ownership: what contains what

contains ↓ Enterprise Top-level tenancy boundary.

owns ↓ Organization Owns Applications and Clusters. RBAC scope.

Application A deployable unit. Owns archetype source, CI workflow, manifests.

Runtime: where it runs

Application deploys to environments

ENVdev ENVstaging ENVprod

scheduled onto

AKS

EKS

coming soon

// each Application × Environment gets its own namespace, provisioned by platform-cluster-operator.

Read the object model docs

// operators

Kubernetes operators reconcile every entity.

Each layer of the object model has an operator watching it. Declare the state in Git or Studio; the operator makes the cloud match, and keeps it that way.

~/acme-platform · zshCLI

$ kubectl apply -f organizations/demo-org.yaml

organization.meta.p6m.dev/demo-org created

$ kubectl get events --for organization/demo-org

REASON MESSAGE

Reconciling platform-organization-operator picked up demo-org

NamespaceCreated demo-org

RBACApplied roles: org-admin, developer, viewer

OperatorsDeployed platform-cluster-operator, installation-operator

Ready organization reconciled · 41s

~/acme-platform · zshCLI

$ kubectl describe platformcluster prd-eus

Provider: azure · eastus · kubernetes 1.31

Managed by: Crossplane + Cluster API

Conditions:

InfrastructureReady True VNet, subnets, managed identity

ControlPlaneReady True AKS control plane

NodePoolsReady True general 3/3 · min 3 · max 12

AddonsApplied True handed to installation-operator

Ready True

✓ drift check every reconcile · manual changes reverted to Git · last sync 30s ago

studio.ybor.ai / catalog / installablesStudio UI

1/5Installables catalog

studio.ybor.ai / applications / orders-apiStudio UI

ORDERS-APIdemo-org · orders-platform

DEVHealthy · In Syncv1.1.0 · a41f9c2

STGHealthy · In Syncv1.0.0 · 7c2d1e8

PRDHealthy · In Syncv1.0.0 · 7c2d1e8

Workloads

devrunningdemo-org-orders-api-dev1m ago

stgrunningdemo-org-orders-api-stg3h ago

prdrunningdemo-org-orders-api-prd3h ago

Operator events

operatorreconciledApplication orders-api · 3 environments1m ago

kargopromotedv1.0.0 stg → prd · approvals 2/23h ago

Operator reference docs

// the lifecycle

From archetect render to a production pod.

Eight steps, four operators, one audit trail. Here's a first release of orders-api as Studio records it.

→

Scaffold: archetect render generates the repo + manifests

→

Build: push runs CI: test, build, sign, scan

→

Promote: Kargo gates each hop on policy and approvals

→

Deploy: ArgoCD syncs the Application to its Environment

→

Reconcile: operators provision the Cluster via Crossplane + Cluster API

→

Bootstrap: the addon catalog is installed

→

Schedule: each Environment gets its namespace and RBAC

→

Govern: policies active, audit log written, observability live

studio.ybor.ai / applications / orders-api / activityStudio UI

Activityorders-api · first release, dev → prd

01Scaffoldm.chenarchetect render · repo + manifests created0:00

02Buildci-bottest, build, sign, scan · image v1.0.00:04

03Promotekargopolicy + approval gates passed · stg → prd0:09

04Deployargocdorders-api synced to prd0:11

05Reconcileplatform-cluster-operatorprd-eus Ready0:11

06Bootstrapinstallation-operatoraddon catalog applied · 10/100:12

07Scheduleplatform-cluster-operatornamespace demo-org-orders-api-prd · RBAC0:12

08Governkyverno14/14 policies passing · audit log → SIEM0:13

// elapsed minutes, illustrative first release

// addon catalog

What comes in the box.

Every installable that ships on every workload cluster, applied by the installation-operator. This is the full list, not a highlight reel.

Addon	Category	Purpose	Version
Networking
istio	Networking	Service mesh, mTLS, traffic policy	1.22
cert-manager	Networking	Certificate issuance & rotation	1.15
Policy & Security
kyverno	Policy	Best-practice policy enforcement	1.12
vault	Security	Secret storage & injection	1.17
Observability
opentelemetry	Observability	Traces, metrics, logs collection	0.103
grafana	Observability	Dashboards & alerting	11.1
prometheus	Observability	Metrics store	2.53
CI/CD
argocd	CI/CD	GitOps continuous delivery	2.11
kargo	CI/CD	Environment promotion gating	0.8

Versions illustrative.

// multi-cloud

One control plane. Azure today, AWS next.

One control plane reconciles every workload cluster fleet, each running the same addon stack. Customer deployments run on Azure today; AWS customer accounts are coming soon.

Ybor Control Plane

Azureaks · addons

AWSeks · addons

coming soon

Want the deep architecture walkthrough?

60 minutes with our platform team. We'll go entity-by-entity through the object model on your stack.

Book the architecture walkthrough Read the architecture docs