Deploy and promote apps on a platform

What an app is

An app is a workload you bring. It declares what it needs from the platform under it, and cub app check reads its own objects to report that.

An app on a stack is checked before anything runs. Certify judges the app's need alongside every component in the manifest, and refuses the stack if the need goes unmet.

An app on a platform is that same app after the stack is uploaded and running under governance. It deploys, promotes, and rolls back there with ConfigHub's own verbs.

A standalone app needs neither. It pulls its own reviewed OCI bundle and reconciles straight onto a cluster through Argo CD or Flux. An app only needs a platform for a dependency a stack carries, such as TLS from cert-manager or an ingress controller.

Try AICR inspects a different kind of platform, one composed of Argo CD Applications instead of a stack manifest.

Try it now

Install the workshop plugin, then ask an app what it needs and whether it fits a platform. Nothing here touches a cluster, and no account is needed.

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

$ cub plugin install confighub/cub-workshop

# what does this app need?
$ cub app check shop-web

# does the app fit the platform?
$ cub stack sandbox shop-platform

cub app check reads the app's own objects and names what they need from the platform under it, such as an ingress controller, cert-manager, or an operator. cub stack sandbox shop-platform renders the app beside the platform parts and refuses the composition if a part conflicts or a need goes unmet.

These three tiers build on each other, and you can stop at any one with a working result.

Follow the demo, step by step

The demo puts an app on a platform whose ingress controller does not match, so certify has something real to catch. Each step is a command you can run yourself.

1. Check the app. cub app check shop-web reads its objects and reports what it needs from the platform under it, such as an ingress controller, cert-manager, and external-secrets.
2. Certify it on the platform. The app's Ingress asks for the nginx class while the platform runs Traefik, and one need has no provider, so certify refuses the composition and names both reasons.
3. Adapt both sides. Change the app's ingress class to match the platform, and grow the platform by the one service the catalog already carries. The app shapes the platform, and the platform shapes the app.
4. Certify again. cub stack sandbox shop-platform now reports the composition certified. Changing the app's ingress class and adding one service was enough.

Read the shop-platform manifest, the shipped apps, and the recorded composition, where an assistant chose the parts and certify judged them. Stacks explains the manifest.

Take it into ConfigHub

The free check and certify answer whether an app fits. ConfigHub is where the reviewed result becomes a shared record that a team can release, promote, and roll back.

Once connected, put the app on the stack

cub app upload puts the app into ConfigHub, and a stack placement clones it next to the platform parts it needs. Each object becomes a Unit, and the app is now a base variant that certify still judges as part of the whole stack.

# a base Unit per object, cloned next to the platform
$ cub app upload shop-web --run

# place it on a cluster's target, in a Space named shop-web-demo-dev
$ cub variant create demo-dev shop-web-base --target demo-dev/target --space-pattern "template:shop-web-demo-dev"

Inside ConfigHub, operate the app on the platform

From here the app uses the same verbs as any platform component. Release it by digest so your reconciler pulls exactly that. Promote it across environments with a dry run that names any withheld change, gate a release on an approval, and roll back to the bytes that ran. Operate saved configuration and Variants carry the detail.

# release by digest; the reconciler pulls it
$ cub release publish shop-web-demo-dev

# preview a promotion, then run it without --dry-run
$ cub variant promote shop-web-demo-dev --dry-run

# gate every Unit in the Space on approval
$ cub trigger create require-approval Mutation Kubernetes/YAML vet-approvedby 1 --space shop-web-demo-dev

# the gate covers every Unit, so approve each one
$ cub unit approve shop-web-deployment --space shop-web-demo-dev

# the release is refused until all its Units are approved
$ cub unit approve shop-web-service --space shop-web-demo-dev

# roll back to a revision that already ran
$ cub unit update --space shop-web-demo-dev shop-web-deployment --restore 2

Each command reuses a verb from Operate. Release publishes by digest, and promote carries a reviewed change forward with a dry run first. A trigger gates the Space on approval. Roll back moves a Unit's head to a revision that already ran. See every verb explained.

Check the current delivery gaps before you rely on gate order across an app's CRDs. Read the known gaps.

Bring an app that already runs

An app you already run carries history, such as old chart versions, hand-created Secrets, and controller-generated fields. Start read-only: record what runs and compare it, and decide only afterward which configuration ConfigHub should keep and which delivery system stays in control.

Variants decides whether a change belongs in the Helm source or in a saved ConfigHub object.

Open working examples