Skip to content

Go Live

The base exists, but a base is never deployed. To run CubbyChat you create a deployment: a variant cloned from the base, adapted to a concrete place to run — your dev cluster.

Create the dev deployment

cub variant create dev cubbychat-base \
    --target dev/target \
    --namespace cubbychat

One command did four things:

  • Cloned the base into a new space, cubbychat-dev — every unit copied, and each copy records the base unit it came from, at the exact revision that was cloned. That memory is what lets changes to the base flow into deployments later, while preserving each deployment's own customizations.
  • Attached the target, making this variant a deployment of the dev cluster: releases published from this space go to that target.
  • Filled the placeholder: --namespace cubbychat replaced confighubplaceholder throughout, so this deployment lands in its own namespace.
  • Told the cluster about the deployment. Because the target is a cub cluster up cluster, ConfigHub created the Argo CD Application that makes this deployment live — a unit named cubbychat-dev, added to the cluster's dev-argo-apps space, that points Argo at this deployment's OCI release. The cluster's root "app of apps" picks it up on its next sync. From now on, Argo is watching for CubbyChat releases — there just aren't any yet. (Pass --no-argo-app to skip this and wire the Application yourself.)

Check the upstream relationship on one of the cloned units:

cub unit get --space cubbychat-dev backend

Note the upstream unit and revision fields. The component now has the beginnings of a variant tree: base → dev.

Publish a release

Configuration in ConfigHub never goes live implicitly. To make the deployment live, publish a release: an immutable bundle of the deployment's configuration, served from ConfigHub's OCI endpoint, which Argo pulls and reconciles.

cub release publish cubbychat-dev

Argo CD in your cluster notices the new release on its next sync and applies it. Watch it come up:

kubectl get pods -n cubbychat --watch

What just happened

This is ConfigHub's deployment model, and it's worth pausing on:

  • You never pushed anything at the cluster. ConfigHub published a bundle; the operator inside the cluster pulled it. ConfigHub needs no credentials to your infrastructure.
  • Releases are immutable and deliberate. Editing configuration in ConfigHub does not change what's running. Only publishing a release does. This separation — change config, then release it — is the foundation for everything later in this tutorial: review, promotion, and controlled rollout.
  • The live state is accounted for. Each release records exactly which revision of each unit it contains, so "what is running in this cluster?" always has a precise answer.

Check

cub release list --space cubbychat-dev
kubectl get pods -n cubbychat

One release published; pods Running.

Summary

  • A deployment is a clone of the base: cub variant create <name> <base> --target <target> --namespace <ns>.
  • cub release publish <variant> makes it live by publishing an immutable OCI bundle that the cluster pulls.
  • Changing config and releasing it are separate steps. Nothing goes live implicitly.

Next

Make a Change

Further reading