Put an app on a platform

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@v0.6.61

# 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 the check 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. It names an ingress controller, cert-manager, and a Prometheus operator.
2. Check it on a platform that does not fit. cub stack check kubara-shop-first-try places the app on the Kubara platform. The app's Ingress asks for the nginx class while that platform runs Traefik, and its ServiceMonitor needs a Prometheus operator the platform does not carry. The check reports REFUSED and names both needs.
3. Adapt both sides. cub app check shop-web-kubara shows the adapted app. Its Ingress uses Traefik's class, and it reads its secret through external-secrets, so the platform grows by that one service. The app shapes the platform, and the platform shapes the app.
4. Check again. cub stack sandbox kubara-shop-platform reports CHECKED with 135 objects. cub stack sandbox shop-platform shows the other answer, a platform that carried nginx and the Prometheus stack from the start.

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

Deploy the first app, end to end

This path uses one Namespace, ConfigMap, Deployment, and Service. It is deliberately small enough that you can relate the four source objects to the ConfigHub Base and dev variant, the immutable Release, the Argo CD Application, and the live workload.

What you need: cub, Docker, kind, kubectl, and a ConfigHub Cloud account. The first check is local. The cluster and ConfigHub writes begin only when the commands say so.

1. Download and check the exact input

$ cub plugin install confighub/cub-workshop@v0.6.61

$ curl -fsSLo acme-web.yaml https://confighub.github.io/helm-expt/site/examples/acme-web.yaml

$ cub config check ./acme-web.yaml
four Kubernetes objects; no account or cluster write

Open the downloaded YAML. The Namespace is part of the app rather than an undeclared prerequisite. The retained import proof records the same four-object set and its limits.

2. Create one local destination

$ cub auth login

$ cub cluster up --name workshop

$ source ~/.confighub/clusters/workshop.env

$ cub target get workshop/target
the ConfigHub target that represents this cluster

cub cluster up creates the kind cluster, installs Argo CD and the live-status helper, and creates workshop/target. Sourcing the generated file selects that cluster for the kubectl checks below.

3. Save the Base and make the dev deployment

# save the four reviewed objects; nothing deploys yet
$ cub variant upload --component acme-web --variant base ./acme-web.yaml

# clone the Base and attach it to the real target
$ cub variant create dev acme-web-base --target workshop/target --namespace acme-web

$ cub component open acme-web

The component view should show acme-web-base and its target-bound acme-web-dev child. Upload stores configuration; variant creation chooses where the child belongs. Neither command should be described as a successful deployment yet.

4. Publish, then prove every boundary

$ cub release publish acme-web-dev

# controller proof
$ kubectl get application -n argocd acme-web-dev
the row must report Synced and Healthy

# workload proof
$ kubectl -n acme-web rollout status deployment/acme-web --timeout=5m

# running objects
$ kubectl -n acme-web get deployment,service,pods

Read these as separate checkpoints: ConfigHub published a Release; Argo CD reports its Application; Kubernetes reports the Deployment ready. A green result at one boundary does not substitute for the next one. The product's maintained deploy-path test also checks the observed revision, ready replicas, ConfigHub origin metadata, and live-status feedback; this four-object Workshop fixture has a retained import receipt, while a fresh joined live receipt remains separate evidence.

Continue with promotion, approval, and rollback

From here the app uses the same verbs as any platform component. The commands below are separate operation examples, not a sequence that installs an approval gate. For gated delivery, first configure the workflow and bind the ChangeOrder, then record the qualifying approval before attempting the gated operation. Operate saved configuration and Variants carry the detail.

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

# read the attestation prerequisite schema before configuring the ChangeWorkflow
$ cub changeworkflow create --help

# review selected revisions, then approve this Space's targeted Units
$ cub variant approve acme-web-dev

# inspect revision history before restoring an earlier one
$ cub unit list --space acme-web-dev

Each command reuses a verb from Operate. Release publishes by digest, and promote carries a reviewed change forward with a dry run first. Approval attestations satisfy a configured ChangeWorkflow prerequisite; recording an approval alone does not add a gate. This example assumes the reviewed workflow is already bound to the ChangeOrder when gated delivery is required. 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.

What an app is, in full

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. The check 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.

Open working examples