Skip to content

Add a Production Deployment

So far the component has one deployment. The point of the base/deployment structure is that adding another one is cheap. In this step you'll bring up a second cluster and stamp out a production deployment of CubbyChat onto it.

Bring up a second cluster

cub cluster up --name prod

Same as before: a local kind cluster with Argo CD, a prod space (plus its prod-argo-apps companion), and an OCI target addressing it.

Create the prod deployment

cub variant create prod cubbychat-base \
    --target prod/target \
    --namespace cubbychat \
    --environment Prod \
    --unit-delete-gate critical

This clones the base into cubbychat-prod: every unit copied and linked upstream, targeted at the prod cluster, namespace placeholder filled. Just as with dev, because the target is a cub cluster, ConfigHub also creates the Argo CD Application in the prod cluster's prod-argo-apps space, so the prod cluster picks up the deployment. --environment stamps the Environment=Prod label so policy can distinguish production, and the delete gate protects the cloned units from accidental deletion — a habit worth forming for production variants.

Confirm nothing is left undecided. get-placeholders lists every remaining placeholder; with the namespace filled in, it lists none:

cub function do --space cubbychat-prod get-placeholders

Release it

cub release publish cubbychat-prod
source ~/.confighub/clusters/prod.env
kubectl get pods -n cubbychat

CubbyChat is now running in two clusters.

Step back and look

You now have the shape that ConfigHub is built around — one component, three variants:

cubbychat-base
├── cubbychat-dev   → dev cluster
└── cubbychat-prod  → prod cluster

cub space list --where "Labels.Component = 'cubbychat'"

In the ConfigHub UI, open the Components view to see this as a promotion tree, with per-deployment badges for pending upgrades and unreleased changes.

Two commands created a production deployment: cub cluster up and cub variant create. The same two commands would give you a third region, a tenant-specific instance, or an ephemeral test environment. That repeatability is the value of keeping a component's configuration as a base plus deployments.

Notice what prod did not get: the replica change from the previous step happened after dev was cloned but is in the base, so prod picked it up at clone time — a fresh clone always starts from the base's current state. From here on, though, the two deployments move independently: a change to the base reaches each of them only when it is promoted there.

Summary

  • A new deployment is a clone of the base: cub variant create <name> <base> --target <target> --namespace <ns>.
  • Label and gate production variants at creation time (--environment Prod, --unit-delete-gate critical).
  • Each deployment releases to its own target independently.

Next

Flow a Change

Further reading