Vantage), and ArgoCD. You apply a Vantage object describing the desired installation; the operator reconciles the installation state to match the resource, delegating per-component sync to ArgoCD. This page explains the moving parts conceptually. For field-level details, see the API reference.
Why this pattern
Vantage 2.7 self-hosted ran on ABBYY-provided Ansible playbooks and Azure CLI scripts that installed both the application and supporting infrastructure in one shot. That model is not supported in 3.0. The 3.0 operator separates concerns:- Infrastructure: provisioned by you, outside the operator’s scope. ABBYY does not provide provisioning automation for 3.0.
- Application: described declaratively in the
Vantageresource. The operator handles dependency resolution for the Vantage Core components, artifact migration, and reconciliation through ArgoCD.
vantage-operator and vantage-selfhosted Helm charts.
The Vantage custom resource
The CRD is registered at vantage.abbyy.com/v1alpha1. A minimal resource looks like this (illustrative; see the API reference for the complete spec):
spec.secrets is required, and exactly one provider (azure or kubernetes) must be specified. spec.smtp is optional; omit it to use the default SendGrid mail provider (supply a sendgridApiKey via your secrets provider). See Secrets and Key Vault for the supported providers.
In practice you set most of these through the vantage-selfhosted Helm chart. See Azure or Self-Managed Kubernetes.
Key concepts
Workloads ConfigMap
spec.workloads points the operator at a ConfigMap containing the manifest of charts and images that make up a Vantage version. The operator reads this manifest, runs OCI migration to copy artifacts into your registry, then generates ArgoCD Application manifests for each component. The ConfigMap is built and published by ABBYY as part of every Vantage release.
Secrets and certificates
The operator does not store secrets directly. Two secrets providers are supported (Azure Key Vault via the Secrets Store CSI driver, and pre-existing KubernetesSecret resources), and exactly one is configured per install. See Secrets and Key Vault for the supported providers, identity modes, and the full alias inventory.
OCI migration
spec.ociMigration declares a one-time job that copies artifacts from one or more configured source registries into your destination registry before install. Once migration completes, every subsequent component pull is from your own registry. ArgoCD pulls the component charts from that registry through a repository connection you configure yourself. Destination authentication supports no auth, basic auth, or Azure Workload Identity with Azure RBAC. Workloads also need pull access through Kubernetes image pull Secrets or, on Azure, AcrPull granted to the AKS managed identity. See Azure image pull access or self-managed registry access.
Skill installation
Skills are installed by a separate Kubernetes job in the install namespace, not by one of the operator-generated ArgoCD applications, so ArgoCD does not show skill installation progress. TheVantage resource can report Ready while the job is still running, and Vantage is usable in the meantime. Monitoring commands are in Lifecycle.
Runtime contract
The operator’s runtime contract (how it processes theVantage resource, what conditions it publishes back, and how to force a retry) is documented separately from this conceptual overview. See Lifecycle.
What’s next
API reference
Field-by-field reference for every spec and status property.
Lifecycle
Reconcile phases, status conditions, and forcing a retry.
Helm chart values
Reference for every Helm value the operator and Vantage charts accept.
Troubleshooting
Diagnose common operator, ArgoCD, secrets, database, ingress, and mesh issues.