Vantage custom resource describing the install you want, and the operator handles the Vantage Core install: fetching the Vantage Core dependency set, validating configuration, copying artifacts into your registry, and reconciling Helm releases through ArgoCD.
Why a new installer
Vantage 2.7 self-hosted required ABBYY’s exact specified infrastructure, created and configured by ABBYY-provided Ansible playbooks and Azure CLI scripts running in a Docker container. That model is not supported in 3.0: you provision your own infrastructure, and moving from 2.7 is a fresh install plus a data migration, not an in-place upgrade. The 3.0 installer adopts modern Kubernetes patterns: an operator, a declarative custom resource, and ArgoCD for orchestration. The result is fewer moving parts on day one and simpler upgrades over time. Customers maintain the operator and the custom resource; the operator reconciles the Vantage Core releases from there.Vantage 3.0 uses a different deployment model than 2.7 and earlier. Previous releases required ABBYY’s exact specified infrastructure, created and configured by ABBYY-provided Ansible and Azure CLI scripts. That model is not supported in 3.0:
- You provision your own infrastructure: the Kubernetes cluster, databases, storage accounts, and key vault. ABBYY does not provide provisioning scripts, templates, or other infrastructure automation for 3.0.
- The installer deploys Vantage Core only. Third-party software that Vantage relies on, such as ArgoCD, your service mesh and ingress controller, your secrets integration, and your monitoring stack, is installed and maintained by you, usually via Helm.
- The documented configurations are scenarios ABBYY has tested. You can adapt your installation based on the documented examples; validating an adaptation is your responsibility.
Architecture at a glance
| Component | Role |
|---|---|
| Vantage operator | Kubernetes operator deployed via Helm. Watches the Vantage custom resource and reconciles installation state. |
Vantage custom resource | Declarative spec for the install (vantage.abbyy.com/v1alpha1). DNS, secrets, SMTP, workloads. |
| ArgoCD | Applies and reconciles the per-component Helm releases that make up Vantage. |
| OCI migration job | Copies Vantage artifacts from the ABBYY-distributed source registry into your destination registry before install. |
| Skill installer job | Installs Vantage skills via a separate Kubernetes job. Not tracked by ArgoCD. |
| Secrets provider | Supplies application values through Azure Key Vault and the Secrets Store CSI driver, or through native Kubernetes Secrets. |
| Service mesh | Provides mTLS for Vantage application traffic. The supported deployment guides use Istio on AKS and Linkerd on self-managed Kubernetes. |
| Ingress controller | Terminates public HTTPS and implements the Vantage path-routing and rewrite contract. |
Vantage resource, the process progresses through five phases:
- Preflight: validates configuration. During preflight checks, secrets configuration is validated.
- Secrets: prepares the configured secrets provider. With Azure Key Vault, the operator provisions
SecretProviderClassresources and the CSI driver supplies values at pod startup. With the Kubernetes provider, the operator validates the native Secrets that you pre-created in the install namespace. - OCI Migration: runs the OCI migration job to copy artifacts into your destination registry.
- Installation: generates ArgoCD Application manifests for each component and applies them.
- Sync: watches ArgoCD application status and reports back to the
Vantagecustom resource.
What changes from Vantage 2.7
| Aspect | 2.7 self-hosted | 3.0 self-hosted |
|---|---|---|
| Installer | Ansible playbooks in a Docker container | Kubernetes operator + ArgoCD |
| Infrastructure provisioning | ABBYY-provided Ansible and Azure CLI scripts against ABBYY-specified infrastructure | Provisioned by you; no ABBYY-provided automation |
| Configuration | env_specific.yaml file | Declarative Vantage custom resource |
| Deployment targets | Azure or on-premises VMs | AKS or self-managed Kubernetes |
| Service mesh | Not in the install | Istio on AKS or Linkerd on self-managed Kubernetes, with mTLS on application traffic |
| Secrets | YAML files / environment variables | Cloud key vault via the Secrets Store CSI driver, or pre-existing Kubernetes Secret resources |
| Updates | Re-run the ABBYY-provided installation scripts and Ansible playbooks | Upgrade matching versions of the operator and Vantage charts; the operator reconciles the Vantage Core releases |
Where to go next
Prerequisites
Cluster, services, secrets, and certificates that must be in place before you install.
Architecture
How the operator consumes the
Vantage custom resource.Install on Azure
Step-by-step install on AKS with Azure Key Vault.
Self-Managed Kubernetes
Install with customer-managed ingress, mesh, secrets, storage, and data services.
API reference
Field-level reference for the
Vantage custom resource.