Historical Kubara v0.12.0 app rollout

Delivery authority superseded. The force-sync behavior below is accurate for this retained v0.12 proof, but it is not the current adapted-lane design. The v0.13 lane leaves spec.syncPolicy.automated absent, treats targetRevision: latest as discovery-only, pins argobot to refresh-only Kubernetes mode, and lets the ConfigHub reconciler submit only the exact revalidated release ManifestDigest with Kubernetes identity compare-and-set. Use the current guide for operational adoption.

This example shows two things. First, ConfigHub manages Argo CD across four clusters and rolls out, promotes, and rolls back an app for the operator. Second, a real Kubara-generated platform (cert-manager and traefik) is delivered the same way on one cluster, and the app runs on it and uses it: reachable through the platform's ingress with a cert-manager certificate. cub cluster up provides the Argo CD that owns delivery on each cluster.

What ran

cub cluster up created four kind clusters: hx-app-dev, hx-app-staging, hx-app-prod-a, and hx-app-prod-b. On each cluster it installed Argo CD and argobot. In this historical proof, argobot is a ConfigHub bot that force-syncs the matching Argo CD Application the moment a release is published. That historical mechanism is preserved as evidence, not recommended as the current deployment-authority model.

The app is a small nginx service. It is stored as three literal-YAML Units, one resource per Unit: a Namespace, a Deployment, and a Service. The base Space hx-web-base holds the reviewed app.

The delivery path

Each cluster receives the app the same way:

1. cub variant create clones the base into a per-cluster Space bound to that cluster's Argo target, and auto-creates the cluster's Argo CD Application.
2. cub release publish bundles the Space's Units as an OCI release.
3. Argo CD pulls that exact release, and argobot force-syncs it.

The promotion chain is base -> dev -> staging -> prod-a and prod-b.

What the run proved

• Initial rollout. The app reached all four clusters. Every Argo CD Application reported Synced/Healthy at 2/2 pods.
• Fleet promotion. One change in the base, set-replicas 2 -> 3, promoted through dev and staging, then to both production clusters as one wave. All four clusters reached 3/3.
• Rollback. A revision restore returned prod-a to 2/2 while prod-b stayed at 3/3.
• Optional staging sandbox. A SANDBOX_URL env var was added to staging only. It appeared on the staging cluster and was absent on dev and both production clusters.
• Departures survive promotion. A later base annotation was promoted into staging. Staging kept its SANDBOX_URL while adopting the annotation.

Production Units carry prod-critical delete and destroy gates.

The app on a real Kubara platform

The rollout above shows delivery. This part shows the app running on an actual Kubara-generated platform and using it.

Two Kubara platform services were rendered from Kubara's own generated umbrella charts and delivered to all four clusters through the same ConfigHub path, one variant Space per cluster:

• cert-manager v1.21.0 - three Deployments Running on each cluster.
• traefik 41.0.2 - one Deployment Running on each cluster, with its traefik IngressClass.

The app then used the platform on every cluster. A traefik Ingress routes hx-web.local to the app's Service. A cert-manager Certificate issued the app's TLS certificate (Ready=True, SAN DNS:hx-web.local). On all four clusters an HTTPS request through traefik returned HTTP 200 and the nginx page, served with the cert-manager certificate rather than traefik's default.

Bringing these up taught the platform's shape. Kubara's charts assume the whole platform exists: they guard their ServiceMonitor behind the Prometheus-operator CRD, and cert-manager's ClusterIssuer is a custom resource that needs its CRD established first. So the bring-up order is CRDs, then controllers, then custom resources.

What this does not prove

This proof delivered cert-manager and traefik on all four clusters. The fuller platform (all seven Kubara services, and monitoring) is covered in the single-platform write-up. Kubara's ClusterIssuer is Let's Encrypt ACME, which needs a public-reachable ingress, so a self-signed issuer was used for TLS on kind. The app is a minimal nginx service, not a production workload.

Production requires approval

The two production clusters carry a require-approval gate. A Trigger in the hx-platform Space runs vet-approvedby, attached to the production Spaces through a Filter. When a change is promoted to production, cub release publish is refused with HTTP 422 until every Unit in the Space is approved. After a cub unit approve, the release publishes and argobot delivers it. The gate covers every Unit in the Space, so a namespace or service Unit must be approved alongside the workload.

Check the evidence

The committed receipt records the clusters, Spaces and their IDs, the OCI release digest for each cluster, the promotion and rollback steps, argobot health, and the final fleet state.

npm run kubara-app-rollout:verify