Bring your Sveltos fleet into ConfigHub

1. Preview the setup

Install the cub CLI and the released plugin. The plugin renders charts with helm template, so it also needs Helm v3 or v4 on your PATH.

cub plugin install confighub/sveltos-confighub@v0.15.0

Confirm the management context. Check that kubectl is pointed at the Sveltos management cluster before exporting:

kubectl config current-context

Prepare the inputs. The exports can contain sensitive configuration. Keep Secrets and credentials out of review files. On the confirmed Sveltos management cluster, export the profiles and clusters the first input file should describe:

kubectl get clusterprofiles,sveltosclusters -A -o yaml > my-fleet.yaml

This reads the management cluster; it requires access to a cluster running Sveltos v1.14.0 or newer. For each ConfigMap named by a profile's policyRefs, export that ConfigMap as a separate YAML input and pass it after my-fleet.yaml. For example, if a profile refers to the kyverno-policies ConfigMap in the default namespace:

kubectl get configmap -n default kyverno-policies -o yaml > kyverno-policies.yaml

Once these YAML files are ready, planning is offline and needs no ConfigHub account or cluster mutation:

cub sveltos plan my-fleet.yaml kyverno-policies.yaml --stage-label env --stages staging,prod

The plan shows the shared base, a variant for each selected cluster, the rollout stages, and the objects rendered from charts and policy ConfigMaps. Review its exclusions and warnings too: hooks and unsupported ownership may need a deliberate decision. A hooks refusal is a prompt to review the lifecycle, not a reason to add --include-hooks blindly.

Prepare the example inputs · read the planning reference.

You can stop here. The plan reads the exported YAML and does not change the cluster. To generate setup scripts, connect delivery, or make a reviewed change, open the advanced steps below.

After the preview: save, connect delivery and make a change

2. Review setup before running it

Generate scripts first. This writes files only.

cub sveltos apply my-fleet.yaml kyverno-policies.yaml --stage-label env --stages staging,prod --out onboard

Check what apply wrote

apply writes the objects each base renders to onboard/<base>/<base>.yaml, and apply.sh stores those. Before you run it, you can check them with cub config check from the Workshop plugin. It reads files only. On the published example fleet the three bases are ingress-nginx, kyverno and kyverno-policies:

cub plugin install confighub/cub-workshop@v0.6.61
for base in ingress-nginx kyverno kyverno-policies; do cub config check onboard/$base/$base.yaml; done

On the example it reports 19, 71 and 1 objects, and each passes the schema step. The schema step names any field the API server would reject, so you can fix it before you save.

Read onboard/apply.sh before running it. Running it needs ConfigHub login, cub v0.8.13 or newer and a management-cluster context. In ConfigHub it makes a service account, sveltos-delivery, that can only read its Targets' releases. It can change that cluster: for profiles that are not already live, it creates the gateway Secret, which holds that account's token, and the delivery profiles. Sveltos then begins delivering ConfigHub releases. Existing live profiles are deferred to handover and remain in control until then.

MGMT_CONTEXT=<management-cluster-context> bash onboard/apply.sh

Use a disposable fleet first. A missing Unit can mean a released profile removes objects it no longer holds.

3. Connect live profiles

Only live profiles need handover. The generated script checks the planned render, Helm’s recorded release, cluster reachability, and current ownership before changing a profile.

MGMT_CONTEXT=<management-cluster-context> bash onboard/handover.sh

It is a managed fleet operation, not a universal single-profile shortcut. Keep workload Secrets out of exported review files, review the printed recovery order, and retain backups. The guide records open limits around handover rollback and chart-rendered Secret handling.

Advanced handover and recovery reference.

4. Change, approve, and release

See agents repair a fleet and prevent recurrence in the recorded Deep Dive, then decide whether to run the disposable demonstration.

The released guide shows this field change. Use your generated plan for real Space names. This stores configuration; it does not publish a release.

cub function set --space sveltos-kyverno-base --unit kyverno --change-desc "Admission controller at 4 replicas" -- \
  set-yq '(select(.kind == "Deployment" and .metadata.name == "kyverno-admission-controller") | .spec.replicas) = 4'

To deliver the change, follow the linked reference to create its change order, promote, approve and publish each stage. The starter workflow allows the author to approve; set AllowAuthors: false when independent approval is required.

Live status writes Sveltos observations to ConfigHub:

cub sveltos status --kube-context <management-cluster-context> --watch

Read change, approval, release, and status details.