Skip to main content
A small set of constraints currently apply to Vantage 3.0 self-hosted. Plan around these before you size or schedule a deployment.

​
Architectural constraints

​
One operator instance per cluster

The vantage-operator Helm chart uses cluster-scoped, non-templated resource names: the manager-role ClusterRole, the manager-rolebinding ClusterRoleBinding, and the controller-manager ServiceAccount. Installing the chart twice into the same cluster (even into different namespaces) collides on these resources. Install only one instance of this chart per cluster.

​
Deployment support

​
Supported deployment targets

Vantage 3.0 self-hosted supports AKS and self-managed Kubernetes. The validated integrations are documented on Compatibility. Other Kubernetes versions, service meshes, ingress controllers, database engines, and component substitutions have not been validated; coordinate with your ABBYY account team before using an unlisted combination in production.

​
Database support

​
Reporting requires SQL Server

PostgreSQL is supported for Vantage services, but the reporting workload uses SQL Server-specific migrations and is unavailable with PostgreSQL. Set vantage.databaseProvider: PostgreSQL and keep vantage.reportingEnabled: false for PostgreSQL deployments.

​
Mail delivery

​
SMTP supports basic auth only

SendGrid is the default mail provider: supply a sendgridApiKey secret and Vantage will use it without further configuration. SMTP is used only when you configure spec.smtp, and the SMTP path currently supports only basic auth or no auth. If your mail relay requires another auth scheme and you cannot use SendGrid, plan for an intermediate relay that downgrades to basic auth.

​
Operational notes

​
Alternate ingress controllers require the Vantage route contract

The validated ingress paths are the built-in Istio configuration on AKS and the documented Traefik configuration on self-managed Kubernetes. Another ingress controller must implement the same routes, rewrites, TLS behavior, internal-status protection, and forwarded HTTPS scheme. Validating another controller or route implementation is your responsibility. When TLS terminates before an HTTP backend, the Vantage authentication services must honor X-Forwarded-Proto. If the workload charts do not expose the required environment setting, use a supported admission mutation mechanism as described in Self-Managed Kubernetes.

​
KEDA is limited to 2.17.x

The current Vantage workload charts use a KEDA scaler field removed in KEDA 2.18. Use KEDA 2.17.3. With KEDA 2.18 or later, affected ScaledObject resources cannot create their HPAs and remain degraded. See Autoscaling with KEDA.

​
Skill installation is not surfaced in ArgoCD

Skills are installed by a separate Kubernetes job, not by an operator-managed ArgoCD application, so ArgoCD currently gives no visibility into skill installation progress. The Vantage resource can report Ready while the job is still running; you can use Vantage while skill installation is ongoing. Monitor the job directly with kubectl wait. See Lifecycle for the commands.

​
What’s next

Migrate from Vantage 2.7

Plan a migration from an existing 2.7 self-hosted deployment.

Upgrading

Manual upgrade workflow for moving between 3.0 versions.