Upgrading

Vantage 3.0 self-hosted upgrades are operator-driven. Upgrade the vantage-operator and vantage-selfhosted Helm releases to the same new version. The new vantage-selfhosted chart references a versioned workloads ConfigMap, which causes the operator to reprocess the Vantage resource and reconcile the matching Vantage release. Automatic upgrades are not yet implemented.

Upgrade workflow

The operator and Vantage charts are released together and must remain version-aligned. Installing the new operator prepares the compatible controller and CRD; installing the matching vantage-selfhosted chart updates the versioned workloads ConfigMap reference and triggers the in-place update. To perform the upgrade:

Check the installed version

Confirm the version currently running by checking status.installedVantageVersion on the Vantage resource:

kubectl -n $install_namespace get vantages.vantage.abbyy.com $release_name -o yaml

Upgrade both charts

Upgrade the operator first, then upgrade the vantage-selfhosted release to the same version.

helm upgrade --install vantage-operator $charts_uri/vantage-operator \
  --version $new_version \
  --namespace $operator_namespace \
  --wait

helm upgrade --install $release_name $chart_uri/vantage-selfhosted \
  --version $new_version \
  --namespace $install_namespace \
  --values <your-values-file> \
  --wait

If you use GitOps, update both chart revisions to the same version and let your controller render them with your existing values source.

Wait for the resource to reconcile

Watch the Vantage resource for Ready:

kubectl -n $install_namespace wait \
  --for=condition=Ready vantages.vantage.abbyy.com/$release_name \
  --timeout=30m

For finer-grained visibility, watch the OCI migration job and ArgoCD application sync status. Skill installation runs as a separate job that ArgoCD does not track; see Lifecycle. If a chart fails to reconcile, the operator surfaces the cause in status.degradationReasons[].

What’s different from Vantage 2.7

In Vantage 2.7 self-hosted, an upgrade meant running the Ansible installer container against an updated values file and letting it helm upgrade every chart in sequence, an operation that touched both infrastructure and application configuration in one step. In 3.0, the application upgrade is decoupled from infrastructure changes:

Step	2.7	3.0
Trigger an upgrade	Re-run the Ansible installer container	Install matching new versions of the operator and Vantage charts
Apply per-component changes	Ansible iterates `helm upgrade` for each chart	Operator generates ArgoCD `Application` manifests; ArgoCD reconciles

The 2.7 installer model is not supported in 3.0, and there is no in-place upgrade from 2.7. Moving from 2.7 is a migration; see Migrate from Vantage 2.7. The Vantage chart upgrades cover Vantage Core only: software you installed separately, such as your monitoring stack, is upgraded by you on your own schedule.

Upgrade workflow

What’s different from Vantage 2.7

What’s next

Architecture

Known Limitations

​Upgrade workflow

​What’s different from Vantage 2.7

​What’s next

Architecture

Known Limitations

Upgrade workflow

What’s different from Vantage 2.7

What’s next