Skip to content

Make a Change

CubbyChat is live. Now let's change it — the right way: make the change on the base, flow it to the deployment, and release it. This loop — change → promote → release — is the daily rhythm of working with ConfigHub.

Change the base

Configuration in ConfigHub is data, not text, so you change it with functions that operate on specific fields rather than by editing YAML by hand. Bump the backend's replica count on the base:

cub function do --space cubbychat-base --unit backend set-replicas 2

The base has a new revision. The dev deployment is unchanged — and ConfigHub knows it's behind. List its units and note the upgrade column:

cub unit list --space cubbychat-dev

The backend unit shows that an upgrade is needed: its upstream has moved ahead of what was last merged.

Promote to dev

Preview which units would flow down, then promote:

cub variant promote cubbychat-dev --dry-run
cub variant promote cubbychat-dev

Promotion merges the base's changes into the deployment while preserving the deployment's own customizations — the namespace it filled in, and any local overrides it has accumulated. It is a merge, not an overwrite.

Release it

The deployment's configuration has changed, but the cluster is still running the previous release. Publish a new one:

cub release publish cubbychat-dev
kubectl get pods -n cubbychat

Two backend replicas. The full loop: change the base, promote to the deployment, release to the cluster.

Why three steps?

With one deployment this may feel like ceremony — why not just edit and be done? The payoff comes from what each boundary gives you:

  • Base vs. deployment: one place to make a change that many deployments will receive.
  • Promote: each deployment picks up the change on its own schedule, with a preview, without losing its local differences.
  • Release: what's running only changes when you say so, and each release is a precise, immutable record of what went out.

The next step makes the payoff concrete by adding a second deployment.

Summary

  • Change config with functions on the base.
  • cub variant promote merges upstream changes into a deployment, preserving its customizations.
  • cub release publish makes the change live.

Next

Add a Production Deployment

Further reading