Skip to content

Target

A Target is an entity in ConfigHub that represents a place configuration is destined for — typically (for now) a Kubernetes cluster.

A Target is an address, not a connection. It names a destination and gives you something to attach Units to, so that ConfigHub knows which configuration belongs to which environment. It does not hold credentials for that environment, and ConfigHub does not reach into it.

How a Target is used

Configuration reaches a Target by being published, not pushed:

  1. Units are attached to a Target, usually because they live in a Space whose release Target (ReleaseTargetID) is set — a variant created with cub variant create --target gets this automatically.
  2. cub release publish bundles those Units into an immutable Release, served from ConfigHub's OCI endpoint.
  3. A GitOps operator running in the cluster — Argo CD, Flux, or Sveltos — pulls that bundle and reconciles it.

The operator holds the cluster credentials, as it already did. ConfigHub holds none. See integrating with GitOps operators for the full setup.

Users with permission to use a Target can attach Units to it, which is how authorization is delegated: a platform team creates the Targets and grants Use permission, and application teams attach their own Units without being able to change the Target itself.

Creating a Target

cub cluster up creates a Target for the cluster it provisions, along with the server-hosted Worker that backs it. To create one by hand:

cub target create --space platform-dev --provider OCI --toolchain Kubernetes/YAML cluster '' platform-dev/server-worker

Targets are created in a Space but may be attached to Units in any Space. Note that a Space's release Target must already exist when the Space is created, so the Target generally cannot live in the Space it releases — see Publishing Releases for the recommended layout.

Provider Type

ProviderType names the delivery mechanism for a Target. In practice you want OCI: the Target's Releases are served from ConfigHub's OCI endpoint for a GitOps operator to pull.

Each Target also declares one or more ConfigTypes — a (ProviderType, ToolchainType, LiveStateType) tuple. The first is inlined into the Target as its top-level ProviderType, ToolchainType, and LiveStateType fields; any others appear in the ConfigTypes array. A Unit's ProviderType and ToolchainType are validated against that combined set when the Unit is attached.

You can inspect a Target's ConfigTypes with:

cub target get --space <space> <target-slug> -o jq=".Target"

Triggers

Triggers may be attached to Targets via filters that select applicable triggers. This is the recommended way to enforce policies that gate releasing configuration to a particular Target — a validation failure produces an Apply Gate, which blocks cub release publish until it clears.