Prerequisites

Infrastructure that must be in place before installing Vantage 3.0 self-hosted.

This page covers the prerequisites for a Vantage 3.0 self-hosted install. You provision everything on this page in your own subscription and cluster; this page describes what to create, not tooling that creates it. For a complete procedure, choose Azure or Self-Managed Kubernetes.

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.

Operator requirements

The Vantage operator runs on top of Kubernetes and ArgoCD.

Component	Version	Tested version	Notes
Kubernetes	See the supported-version matrix	AKS 1.33.6; self-managed Kubernetes 1.36.1	See Compatibility for the full list.
ArgoCD	>= 2.6.0	v3.3.2 on AKS; v3.4.3 on self-managed Kubernetes	The ApplicationSet Progressive Syncs feature must be enabled. ArgoCD also needs a repository connection to your OCI registry so it can pull Vantage component charts.
Helm	>= 3.0.0	v4.2.0 on AKS; v3.21.1 on self-managed Kubernetes	Used to install the operator and Vantage charts.

Cluster-level requirements

These services and components must be present in the cluster before you install Vantage. Concrete tested versions are listed on Compatibility.

Component	Notes
Service mesh	Istio on AKS or Linkerd on self-managed Kubernetes. The mesh must provide workload-to-workload mTLS in the Vantage namespace. Enable the appropriate namespace injection before installing Vantage.
Ingress controller	The chart includes an Istio ingress path. With another controller, disable the built-in ingress and implement the Vantage routing, rewrite, TLS, and forwarded-scheme requirements documented on Self-Managed Kubernetes.
Secrets Store CSI driver¶	The driver itself plus the Azure Key Vault Provider plugin. Required when using the Azure secrets provider. Surfaces secrets and certificates from your cloud key vault into pods at runtime.
TLS certificates	Must be signed by a public CA. A kubernetes.io/tls-type secret valid for your dnsRecord value, in the same namespace as the Istio external ingress gateway.
OCI registry	Destination registry for Vantage artifacts. The operator’s migration job copies artifacts into it from the ABBYY-supplied source registry; obtain the registry host and repository from your ABBYY account team. Your workloads pull Vantage images from this registry: configure pull access with Kubernetes image pull secrets or, on Azure, by granting AcrPull to the AKS managed identity. See Image pull access.
KEDA 2.17.3 (optional, recommended)	An autoscaling component. When KEDA support is enabled, workload replicas are automatically scaled up and down based on system utilization. The current Vantage workload charts require KEDA 2.17.x; do not use 2.18 or later. See Autoscaling with KEDA.

KEDA Support

Some Vantage KEDA ScaledObject resources depend on a Prometheus instance in the observability namespace. The Prometheus service must be reachable at http://prometheus-operated.observability.svc.cluster.local:9090, and it must scrape Vantage application metrics through the chart-created ServiceMonitor. See Autoscaling with KEDA for trigger behavior and verification, and Monitoring for the metrics pipeline.

Kubernetes Node Requirements

Vantage schedules its workloads across three node pools: a default pool for UI, API, and platform services, a TechCore pool for document processing workers, and a training pool for training-related workers. Label and taint the TechCore and training pools as described below so that processing work is isolated from the rest of the application.

TechCore Worker Nodes

Vantage includes several workloads referred to as “techcore workers”. These workloads carry out much of the main processing of the application (as opposed to workloads running UI and API applications). It is recommended to dedicate a pool of Kubernetes nodes specifically to these workloads. Do so by adding the label k8s.abbyy.com/techcore=true to the set of nodes on which techcore worker workloads should be scheduled, and by tainting those nodes with:

- key: k8s.abbyy.com/techcore
  value: "true"
  effect: NoSchedule

Training Worker Nodes

Further segment TechCore worker nodes by designating specific nodes that should run training-related work. Training-related workloads possess the following toleration:

- key: k8s.abbyy.com/techcore
  operator: Equal
  value: training
  effect: NoSchedule

Taint the nodes that should run training workloads with k8s.abbyy.com/techcore=training:NoSchedule. Only training-related workloads tolerate this taint, so no other Vantage workloads are scheduled on those nodes.

See official Kubernetes documentation for more details on taints and tolerations.

Kubernetes Node Sizes and Counts

Node counts and sizes depend on the install profile and on which optional components you enable. See the Sizing guide for per-node-pool CPU, memory, and pod-count requirements for minimal and production installs.

External services

Provision these before installing. Concrete tested products are listed on Compatibility.

Service	Notes
Database server	SQL Server or PostgreSQL. Vantage needs one distinct logical database per connection-string alias listed under Secrets and Key Vault. The databases do not need to exist ahead of time: each service’s migrator creates its database on first run. The SQL Server reporting database must support Columnstore Indexing. Reporting is unavailable with PostgreSQL.
Redis	Used for cache, locks, and client cache.
SendGrid†	Default mail provider. Required unless you configure SMTP (spec.smtp) instead. Provide a sendgridApiKey via your secrets provider.
SMTP server†	Optional alternative to SendGrid; used only when spec.smtp is configured. Only basic auth or no auth is supported. See Known Limitations.
Object storage	Connection strings come from your secrets provider. See Secrets and Key Vault. If you use a custom storage backend (spec.storage.custom) instead of the default Azure Blob, the referenced Kubernetes StorageClass must be configured in the cluster before you install Vantage, and its provisioned volumes must be writable by a non-root user. See Configure persistent storage.
Secret backend¶	Azure Key Vault when using the Azure provider. With the Kubernetes provider, pre-create native Kubernetes Secrets directly or materialize them from your existing secret store with a tool such as External Secrets Operator. See Secrets and Key Vault.

† SendGrid and SMTP are mutually exclusive; only one is required.

¶ Required only when using the Azure secrets provider (vantage.secrets.azure). The Kubernetes Secrets provider (vantage.secrets.kubernetes) reads from pre-existing Secret resources in the install namespace and needs neither the CSI driver nor a cloud key vault.

What’s next

Install on Azure

AKS prerequisites, identity setup, and the install procedure.

Self-Managed Kubernetes

Bring-your-own mesh, ingress, secrets, data services, and registry.

Compatibility

Supported Kubernetes versions, distributions, and dependency versions.

Sizing

CPU, memory, and pod-count requirements per node pool.