Overview

Architecture overview of ABBYY Vantage 3.0 self-hosted: a Kubernetes operator-driven, declaratively configured deployment of the Vantage platform.

ABBYY Vantage 3.0 self-hosted is a customer-hosted deployment of the Vantage platform built around a Kubernetes operator. You declare a single 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.

ABBYY ships the Vantage operator, the OCI migration job, and the skill installer job. ArgoCD, the service mesh, ingress controller, secrets integration, and monitoring stack are third-party prerequisites that you install and maintain before installing Vantage.

When the operator reconciles a Vantage resource, the process progresses through five phases:

1. Preflight: validates configuration. During preflight checks, secrets configuration is validated.
2. Secrets: prepares the configured secrets provider. With Azure Key Vault, the operator provisions SecretProviderClass resources 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.
3. OCI Migration: runs the OCI migration job to copy artifacts into your destination registry.
4. Installation: generates ArgoCD Application manifests for each component and applies them.
5. Sync: watches ArgoCD application status and reports back to the Vantage custom resource.

Skill installation runs as a separate Kubernetes job that ArgoCD does not track; Vantage is usable while the job completes. See Lifecycle.

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.