> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # Known Limitations > Current limitations and constraints customers should plan around when running Vantage 3.0 self-hosted. 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](/vantage/self-hosted/v3.0/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](/vantage/self-hosted/v3.0/providers/self-managed#forwarded-https-scheme). ### 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](/vantage/self-hosted/v3.0/performance/autoscaling). ### 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](/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately) for the commands. ## What's next Plan a migration from an existing 2.7 self-hosted deployment. Manual upgrade workflow for moving between 3.0 versions.