> ## 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.

# Helm charts

> How the vantage-operator and vantage-selfhosted Helm charts fit together, the values you are most likely to set, and how the operator deploys TechCore workers.

Vantage 3.0 self-hosted ships as two Helm charts: `vantage-operator` (the controller that watches the `Vantage` custom resource) and `vantage-selfhosted` (the chart that creates the `Vantage` resource and supporting manifests in your chosen install namespace). This page explains both charts and the values you are most likely to set.

For field-level CRD details, see [API reference](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/latest/api-reference.md). For an install-time procedure, choose [Azure](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/azure.md) or [Self-Managed Kubernetes](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/self-managed.md).

> [!NOTE]
>
> Install matching versions of `vantage-operator` and `vantage-selfhosted`. Defaults on this page are those of the latest release. Some values are not available in earlier artifact versions. Every value and default for a specific release is on that release's Helm chart values page; find your release on [Releases](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/releases.md).

## `vantage-operator`

Installed once per cluster, into a namespace of your choice. The operator reconciles the Vantage installation defined by the `Vantage` custom resource.

> [!WARNING]
>
> **Install only one instance of this chart per cluster.** The chart's ClusterRole and ClusterRoleBinding are cluster-scoped and use fixed names. See [Known Limitations](https://docs.abbyy.com/vantage/self-hosted/v3.0/known-limitations.md#one-operator-instance-per-cluster).

### Top-level stanzas

* **`nameOverride` / `fullnameOverride`**: partially override the chart's full name (keeping the release name) or fully override it. Unset by default.
* **`manager`**: the operator Deployment: `image`, container `args` (leader election is enabled by default), `env` (pod name and namespace via the downward API), `imagePullSecrets`, pod and container security contexts (non-root, no privilege escalation, read-only root filesystem), `resources`, and scheduling (`affinity`, `nodeSelector`, `tolerations`).
* **`rbacHelpers`**: optional admin/editor/viewer roles for managing the custom resources. Disabled by default.
* **`crd`**: CRD lifecycle: install the CRDs with the chart (`enable`) and keep them when the chart is uninstalled (`keep`).
* **`metrics`**: the RBAC-protected `/metrics` endpoint.
* **`certManager`**: cert-manager integration for TLS certificates, required for webhook certificates and metrics endpoint certificates. Disabled by default.
* **`prometheus`**: a Prometheus `ServiceMonitor` for metrics scraping. Requires the prometheus-operator in the cluster. Disabled by default.

### Notable values

Defaults are those of the latest release. To print the values a chart version accepts, see [Inspecting available values](#inspecting-available-values).

| Value | Purpose |
| - | - |
| `manager.replicas` | Default `1`. |
| `manager.image.repository` / `tag` / `pullPolicy` | Operator container image. `pullPolicy` defaults to `IfNotPresent`. |
| `manager.imagePullSecrets` | Pull secrets for the operator image when your registry requires authentication, for example `--set "manager.imagePullSecrets[0].name=my-pull-secret"`. Default `[]`. Not needed on AKS when `AcrPull` is granted to the kubelet identity. See [Image pull access](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/azure.md#image-pull-access). |
| `manager.args` | Container arguments. Default `[--leader-elect]` (leader election enabled). |
| `manager.env` | Environment variables for the operator container. Default: `POD_NAME` from `metadata.name` and `POD_NAMESPACE` from `metadata.namespace` (field references). |
| `manager.podSecurityContext` / `manager.securityContext` | Pod and container security contexts for the operator. Defaults: pod `runAsNonRoot: true` and `seccompProfile.type: RuntimeDefault`; container `allowPrivilegeEscalation: false`, `capabilities.drop: [ALL]`, and `readOnlyRootFilesystem: true`. |
| `manager.resources` | CPU/memory requests and limits. Defaults: requests `10m` CPU / `64Mi` memory, limits `500m` CPU / `128Mi` memory. |
| `manager.affinity` / `manager.nodeSelector` / `manager.tolerations` | Standard Kubernetes scheduling controls for the operator pod. Empty by default. |
| `rbacHelpers.enable` | Install convenience admin/editor/viewer roles for the CRDs. Default `false`. |
| `crd.enable` | Install the `vantages.vantage.abbyy.com` CRD with the chart. Default `true`. |
| `crd.keep` | Keep the CRDs when the chart is uninstalled. Default `true`. |
| `metrics.enable` / `metrics.port` | Expose the RBAC-protected `/metrics` endpoint. Defaults `true` / `8443`. |
| `certManager.enable` | Cert-manager integration for TLS certificates. Required for webhook certificates and metrics endpoint certificates. Default `false`. |
| `prometheus.enable` | Create a Prometheus `ServiceMonitor` for metrics scraping. Requires the prometheus-operator in the cluster. Default `false`. |

Vantage application configuration lives on the `Vantage` custom resource, which is created by the `vantage-selfhosted` chart.

## `vantage-selfhosted`

Installed into a namespace of your choice. This chart contains the `Vantage` custom resource, a ConfigMap containing the Vantage workloads data with its associated RBAC, and the Vantage-related CRDs and roles sourced from ABBYY's upstream infrastructure repository.

Most values map directly to fields on the `Vantage` custom resource. See the [API reference](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/latest/api-reference.md) for the field-level contract.

### Top-level stanzas

* **`operator`**: pointer to the operator install (`namespace` and `controllerManagerServiceAccount`).
* **`ingress`**: the chart's built-in ingress, selected by `ingress.type`. Set `enabled: false` when you manage ingress yourself, for example with Traefik.
* **`mesh`**: Istio mesh resources (`mesh.istio.enabled`). This is a top-level stanza, not a `Vantage.spec` field.
* **`serviceAccounts`**: ServiceAccounts the chart creates for Vantage workloads, the OCI migration job, and individual workloads. This is a top-level stanza, not a `Vantage.spec` field.
* **`vantage`**: the `Vantage.spec` payload: `argocd`, `databaseProvider`, `debug`, `dnsRecord`, `idReadingEnabled`, `keda`, `mailFrom`, `minimalInstall`, `ociMigration`, `platformAdminEmail`, `reportingEnabled`, `reverseProxy`, `secrets`, `serviceAccountName`, `smtp`, `storage`, `techcore`, `updatePolicy`, `vantageVersion`, `workloads`. These values are passed directly to the `Vantage` custom resource.
* **`defaultSkills`**: which default skills from the bundled catalog the skill-installer-operator installs. This is a top-level stanza, not a `Vantage.spec` field.
* **`observability`**: chart-rendered Prometheus `ServiceMonitor` configuration. This is a top-level stanza, not a `Vantage.spec` field.
* **`workloadsConfigMap`**: controls the workloads ConfigMap the chart ships. `create` toggles whether the chart creates it, and `additionalMetadata` holds advanced per-chart overrides. This is a top-level stanza, not a `Vantage.spec` field.

### Required values

| Value | Maps to | Purpose |
| - | - | - |
| `operator.namespace` | N/A | Where you installed `vantage-operator`. Default `vantage-operator-system`. |
| `operator.controllerManagerServiceAccount` | N/A | Operator controller-manager ServiceAccount. Default `vantage-operator-controller-manager`. |
| `ingress.tls.secretName` | N/A | Name of the `kubernetes.io/tls` Secret. Default `vantage-ingress-tls`. Used when `ingress.enabled` and `ingress.tls.enabled` are `true`. With `ingress.type: istio`, the Secret must be in the Istio ingress gateway namespace. With `gateway`, create it in the Vantage namespace, or in the namespace set by `ingress.gateway.certificateRef.namespace`. With `gateway` and `ingress.gateway.create: false`, the chart does not use it; the existing Gateway supplies the certificate. |
| `vantage.dnsRecord` | `Vantage.spec.dnsRecord` | DNS hostname Vantage is reachable at. |
| `vantage.mailFrom` | `Vantage.spec.mailFrom` | Sender for outbound mail. |
| `vantage.platformAdminEmail` | `Vantage.spec.platformAdminEmail` | Email address of the platform administrator. |
| `vantage.secrets.azure` or `vantage.secrets.kubernetes` | `Vantage.spec.secrets` | Exactly one secrets provider is required. See [Secrets and Key Vault](https://docs.abbyy.com/vantage/self-hosted/v3.0/secrets-and-keyvault.md). |
| `vantage.secrets.azure.keyVaultName` / `tenantId` | `Vantage.spec.secrets.azure` | Required with the Azure Key Vault provider: the Key Vault that holds the secrets and the Azure AD tenant that owns it. |

### Optional values

| Value | Purpose |
| - | - |
| `ingress.enabled` | Create the ingress resources for `ingress.type`. Default `true`. Set `false` when you manage ingress yourself, for example with a Traefik `IngressRoute`. |
| `ingress.type` | Ingress resources the chart creates when `ingress.enabled` is `true`: `istio` (default; Istio `Gateway` and `VirtualService`), `kubernetes` (Kubernetes `Ingress`), `gateway` (Gateway API `Gateway` and `HTTPRoute`), or `native` (`gateway` when the cluster serves the Gateway API, otherwise `kubernetes`). `native` detects the Gateway API from the cluster's API versions, so `helm template` needs `--api-versions`, and Gateway API CRDs installed in the same release are not detected on first install. The Gateway API CRDs and controller, or the Ingress controller, must already be installed. With `gateway`, also set `vantage.reverseProxy: true`. With `kubernetes`, set it when the ingress controller terminates TLS. |
| `ingress.tls.enabled` | Terminate TLS with the Secret named by `ingress.tls.secretName`. Default `true`. Set `false` when the ingress controller supplies the certificate. |
| `ingress.istio.ingressGatewaySelector` | Labels that select the Istio ingress gateway. Default `istio: aks-istio-ingressgateway-external`. |
| `ingress.istio.gateway.labels` / `annotations` | Extra labels and annotations on the Istio `Gateway`. Default `{}`. |
| `ingress.istio.internalDNSResolution.enabled` / `destination.host` | Route calls from inside the mesh to `vantage.dnsRecord` back through the Istio ingress gateway when `vantage.dnsRecord` has no public DNS record. Requires Istio [DNS proxying](https://istio.io/latest/docs/ops/configuration/traffic-management/dns-proxy). Use a `vantage.dnsRecord` with a public DNS record where possible. Defaults `false` / `aks-istio-ingressgateway-external.aks-istio-ingress.svc.cluster.local`. |
| `ingress.kubernetes.ingressClassName` | `IngressClass` that implements the chart's `Ingress` resources. Default `""`. Path rewrites rely on nginx annotations, so they happen only with the class `nginx` or with `ingress.kubernetes.nginx: true`; with nginx, each rewritten route gets its own `Ingress`. With other controllers, rewritten routes reach the right backend with the original path, and regular-expression routes get the closest prefix instead. |
| `ingress.kubernetes.nginx` | Treat the ingress class as nginx-compatible when it is not named `nginx`, for example AKS application routing. Default `false`. |
| `ingress.kubernetes.labels` / `annotations` | Extra labels and annotations on the chart's `Ingress` resources, for example to control TLS through the ingress controller. Default `{}`. |
| `ingress.gateway.create` | Create the Gateway API `Gateway`. Default `true`. Set `false` to attach the `HTTPRoute` to an existing Gateway with `ingress.gateway.parentRefs`. |
| `ingress.gateway.parentRefs` | `parentRefs` for the `HTTPRoute` when `create` is `false`, for example `name`, `namespace`, and `sectionName` of a listener on a shared Gateway. The Gateway's `allowedRoutes` must admit routes from the release namespace. Default `[]`. |
| `ingress.gateway.name` / `gatewayClassName` | Name and `GatewayClass` of the Gateway the chart creates. Defaults `vantage-gateway` / `""`. `gatewayClassName` is required when `create` is `true`. |
| `ingress.gateway.meshIntegrated` | Set `true` when the GatewayClass implementation participates in the Istio mesh, for example Istio's own Gateway API implementation. With `mesh.istio.enabled: true`, the chart then uses `STRICT` mTLS (see `mesh.istio.enabled`). Don't set it for an implementation whose gateway pods get an Istio sidecar in the Vantage namespace, for example kgateway with sidecar injection. Default `false`. |
| `ingress.gateway.regexCatchAll` | Render the `/` catch-all route as a `RegularExpression` match (`/.*`) instead of a `PathPrefix` match. Set `true` for implementations that rank every `PathPrefix` match above `RegularExpression` matches, for example Istio, where the `/` prefix would shadow the regular-expression routes. Default `false`. |
| `ingress.gateway.labels` / `annotations` | Extra labels and annotations on the `Gateway`, for example `cert-manager.io/cluster-issuer` to have cert-manager issue the certificate in `ingress.tls.secretName`. Default `{}`. |
| `ingress.gateway.infrastructure` | Gateway `spec.infrastructure`: labels, annotations, and `parametersRef` that the implementation propagates to the resources it creates, such as the load balancer Service. Default `{}`. |
| `ingress.gateway.listeners.httpsPort` / `httpPort` | Ports of the Gateway's HTTPS and HTTP listeners. Defaults `443` / `80`. The Gateway has an HTTPS listener when `ingress.tls.enabled` or `listeners.controllerSuppliedTls` is `true`, and an HTTP listener otherwise. |
| `ingress.gateway.listeners.httpRedirect` | Add an HTTP listener whose requests are redirected to HTTPS, when the Gateway has an HTTPS listener. Applies only when `create` is `true`. Default `false`. |
| `ingress.gateway.listeners.controllerSuppliedTls` / `tlsOptions` | With `ingress.tls.enabled: false`, create an HTTPS listener without `certificateRefs`, instead of an HTTP listener, for implementations that supply the certificate themselves. `tlsOptions` sets the implementation-specific `tls.options` of the HTTPS listener and is required with `controllerSuppliedTls: true`. Defaults `false` / `{}`. |
| `ingress.gateway.certificateRef.namespace` / `createReferenceGrant` | Namespace of the `ingress.tls.secretName` Secret when it is not the release namespace. The Gateway can use a Secret in another namespace only through a `ReferenceGrant` there. `createReferenceGrant: true` has the chart create it; otherwise create it yourself. Apply only when `create` and `ingress.tls.enabled` are `true`. Defaults `""` / `false`. |
| `ingress.gateway.route.labels` / `annotations` | Extra labels and annotations on the chart's `HTTPRoute` resources. Default `{}`. |
| `ingress.gateway.route.timeouts` | `timeouts` for every `HTTPRoute` rule. Default `request: 0s` (no request timeout). Requires implementation support for `HTTPRouteRequestTimeout`. Set `{}` to keep the implementation's default. |
| `mesh.istio.enabled` | Deploy the recommended Istio mesh configuration. Default `true`. The chart's `PeerAuthentication` mode is `STRICT` with Istio ingress or a mesh-integrated Gateway (`ingress.gateway.meshIntegrated`), and `PERMISSIVE` otherwise. With `ingress.type: kubernetes`, this `PERMISSIVE` configuration is not recommended for production without a corresponding Istio `AuthorizationPolicy`. With Istio as the service mesh, use Istio ingress or a mesh-integrated Gateway. |
| `vantage.vantageVersion` | Version of Vantage to install. Maps to `Vantage.spec.vantageVersion`. Default `""`. |
| `vantage.databaseProvider` | Database engine for Vantage services. Accepted values: `SqlServer` (default) or `PostgreSQL`; case-sensitive. |
| `vantage.secrets.azure.clientId` | Client ID of the user-assigned managed identity with read access to the Key Vault. With `identityMode: workloadIdentity` (the default), each workload uses the `azure.workload.identity/client-id` annotation on its ServiceAccount and falls back to `clientId`. Maps to `Vantage.spec.secrets.azure.clientId`. |
| `vantage.secrets.azure.identityMode` | One of `workloadIdentity` (default), `podIdentity`, `vmManagedIdentity`. See [Secrets and Key Vault](https://docs.abbyy.com/vantage/self-hosted/v3.0/secrets-and-keyvault.md#azure-key-vault-provider). |
| `vantage.secrets.azure.userAssignedIdentityID` | Client ID of the UAMI to use when `identityMode` is `vmManagedIdentity`. |
| `vantage.secrets.azure.objects` | Map of secret alias → `{objectName, objectType, objectVersion}` for Key Vault objects whose names don't match the alias. |
| `vantage.secrets.kubernetes` | Use pre-existing Kubernetes `Secret` resources instead of Azure Key Vault. Optional `objects` mapping overrides default secret names. |
| `vantage.smtp.host` / `port` / `useSSL` / `login` / `password` | Outbound SMTP. Used only when set; SendGrid is the default. Maps to `Vantage.spec.smtp`. `port` defaults to `587`; `useSSL` (TLS) defaults to `false`. |
| `vantage.serviceAccountName` | Default ServiceAccount for Vantage workloads. Maps to `Vantage.spec.serviceAccountName`. Default `default`. To pull images with a pull Secret, add the Secret to the `imagePullSecrets` of this ServiceAccount and of every ServiceAccount named in `vantage.workloads.serviceAccounts` (or set `serviceAccounts.imagePullSecrets` when the chart creates them). See [Azure image pull access](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/azure.md#image-pull-access) or [self-managed registry access](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/self-managed.md#configure-registry-access). |
| `serviceAccounts.vantage.create` / `name` / `labels` / `annotations` / `imagePullSecrets` | Have the chart create the ServiceAccount for Vantage workloads. Default `create: false`. The name defaults to the release name and is set as `vantage.serviceAccountName`. |
| `serviceAccounts.ociMigration.create` / `name` / `labels` / `annotations` / `imagePullSecrets` | Have the chart create the ServiceAccount for the OCI migration job. Default `create: false`. The name defaults to `<release name>-oci-migration` and is set as `vantage.ociMigration.serviceAccountName`. |
| `serviceAccounts.labels` / `annotations` / `imagePullSecrets` | Added to every ServiceAccount the chart creates. Labels and annotations set on an individual ServiceAccount take precedence. Pull secrets are added to those set on each ServiceAccount. Default empty. |
| `serviceAccounts.workloads.<chart>.<kind>` | Give one workload its own ServiceAccount instead of the `vantage` ServiceAccount. Keyed by chart name, then workload kind (`migrator`, `deployment`, or `statefulSet`). Each entry supports `create` (default `true`), `name` (default `<chart name without -helm>-<kind>`, for example `mail-migrator`; required when `create` is `false`), `labels`, `annotations`, `imagePullSecrets`, and `roles`. Each ServiceAccount is bound to `roles`, which default to `migration-writer` and `serviceversion-reader` for migrators, and `migration-reader` and `serviceversion-reader` otherwise. Workloads can share a ServiceAccount by using the same name; entries that create a shared ServiceAccount must configure it identically. Sets `Vantage.spec.workloads.serviceAccounts`. Default `{}`. |
| `vantage.workloads.configMap` / `metadataTemplateKey` / `secretsKey` / `workloadsKey` / `additionalMetadataKey` | Keys of the workloads ConfigMap that the chart ships. When `workloadsConfigMap.create` is `true` (default), the chart names the ConfigMap after the chart version and uses `configMap` (default `vantage-workloads`) only as the name prefix. `additionalMetadataKey` (default `additional-metadata.yml`) names the key that holds your `workloadsConfigMap.additionalMetadata` overrides. Maps to `Vantage.spec.workloads`. |
| `vantage.workloads.pods.labels` / `vantage.workloads.pods.charts.<chart>.<kind>.labels` | Labels added to the pods of every workload, or of specific workloads, for example `azure.workload.identity/use: "true"`. Per-chart labels take precedence. Maps to `Vantage.spec.workloads.pods`. `<chart>` is the full chart name from the workloads ConfigMap, for example `mail-helm`. `<kind>` is `migrator`, `deployment`, or `statefulSet`. |
| `vantage.storage.custom.storageClass` / `size` | Use a Kubernetes `StorageClass`-backed backend instead of Azure Blob. Maps to `Vantage.spec.storage.custom`. `size` defaults to `300Gi`. |
| `vantage.idReadingEnabled` | Enables ID reading features. Maps to `Vantage.spec.idReadingEnabled`. Default `false`. The operator never deploys the `worker-id-reading` charts; see [TechCore worker deployment](#techcore-worker-deployment). |
| `vantage.minimalInstall` | Deploy Vantage workloads with minimal resource configurations. Maps to `Vantage.spec.minimalInstall`. Default `false`. Controls workload sizing only. Pair it with `defaultSkills.mode: minimal` or `custom`. |
| `vantage.debug` | Deploy Vantage workloads in debug mode. Maps to `Vantage.spec.debug`. Default `false`. |
| `defaultSkills.mode` | `all` (default; every version of every default skill), `minimal` (newest version of each skill plus versions pinned in the chart), or `custom` (only `defaultSkills.skills`). `all` is the only safe default: skills derived from a default skill break if that default skill is not installed, so trimming the set is always an explicit choice. Installed default skills can't be removed, so choose the set before the first installation. `skill-installer-def-installation` overrides in `workloadsConfigMap.additionalMetadata` take precedence. |
| `defaultSkills.skills` | Skills to install in `custom` mode, as `{id, versions}` entries. Ignored in other modes. Omit `versions` for the newest version, set `all` for every version, or list version numbers. An unknown ID or version fails the render. Default `[]`. |
| `workloadsConfigMap.create` | Create the ConfigMap containing data about the charts and images required to install Vantage, with its associated RBAC. Default `true`. The ConfigMap name includes the chart version, so each chart upgrade changes `Vantage.spec.workloads.configMap` and the operator updates Vantage in place, under `helm upgrade` and under GitOps tools that render with `helm template`. |
| `workloadsConfigMap.additionalMetadata` | Advanced per-chart overrides merged into the rendered workloads metadata. Default `{}`. An entry for `charts.skill-installer-def-installation.values.defaultSkills` takes precedence over `defaultSkills.mode`. See [Additional workloads metadata](https://docs.abbyy.com/vantage/self-hosted/v3.0/performance/additional-workloads-metadata.md). |
| `vantage.reportingEnabled` | Toggle SQL Server reporting features. Default `false`. Must remain `false` with PostgreSQL. |
| `vantage.reverseProxy` | Configure Vantage application services to run behind a reverse proxy that terminates TLS. Default `false`. Set `true` with `ingress.type: gateway`, and whenever the ingress controller or a customer-managed proxy terminates TLS, which is common with `ingress.type: kubernetes`. Maps to `Vantage.spec.reverseProxy`. See [Forwarded HTTPS scheme](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/self-managed.md#forwarded-https-scheme). |
| `vantage.argocd.project` | Argo CD project for the Applications the operator generates. Default `default`. The project must permit the destination cluster and namespace. Maps to `Vantage.spec.argocd.project`. |
| `vantage.updatePolicy.manual` / `auto` | Upgrade policy. Maps to `Vantage.spec.updatePolicy`. Default `manual: {}`: Vantage upgrades only when you install new chart versions. Exactly one policy is required, and the CRD rejects `auto` because automatic updates are not yet supported. See [`updatePolicy`](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/latest/api-reference#vantagespecupdatepolicy). |
| `vantage.ociMigration.enabled` | Run the OCI migration job. Default `true`. |
| `vantage.ociMigration.serviceAccountName` | ServiceAccount the OCI migration job runs under. Maps to `Vantage.spec.ociMigration.serviceAccountName`. To pull the job image with a pull secret, add the secret to this ServiceAccount's `imagePullSecrets`. |
| `vantage.ociMigration.imagePullSecrets` | Pull secrets for the operator image that runs the OCI migration job. |
| `vantage.ociMigration.sources[]` | Source registries that Vantage artifacts are copied from. Set `sources[0].host` and `sources[0].repository` to the ABBYY source registry. Set `sources[].credentialsRef.name` to a Secret with `username` and `password` keys, or to a `kubernetes.io/dockerconfigjson` Secret. |
| `vantage.ociMigration.sources[].username` / `password` | Plaintext credentials for a source registry. Default `""`. For production, use `sources[].credentialsRef.name`, which takes precedence. |
| `vantage.ociMigration.destination.host` / `repository` | Destination registry that artifacts are copied into. Required while `enabled` is `true`. Default host `abbyy.com`. `host` is the registry hostname with an optional port, without a scheme or path. Put the path in `repository`, for example `vantage/images`. |
| `vantage.ociMigration.destination.username` / `password` / `credentialsRef.name` | Destination registry credentials. `username` and `password` are plaintext and default to `""`. For production, set `credentialsRef.name` to a Secret with `username` and `password` keys, or to a `kubernetes.io/dockerconfigjson` Secret. `credentialsRef` takes precedence over `username` and `password`. Maps to `Vantage.spec.ociMigration.destination`. |
| `vantage.ociMigration.concurrency` | Number of artifacts the OCI migration job copies in parallel. Default `5`. |
| `vantage.ociMigration.resources` | Requests and limits for the OCI migration job container. Defaults: requests `100m` CPU / `128Mi` memory, limit `512Mi` memory, no CPU limit. A value replaces the defaults entirely. |
| `vantage.keda.enabled` | Configures whether [KEDA](https://keda.sh/) is used for autoscaling Vantage workloads. Default `false`. The current Vantage workload charts require KEDA 2.17.x. See [Autoscaling with KEDA](https://docs.abbyy.com/vantage/self-hosted/v3.0/performance/autoscaling.md). |
| `observability.prometheus.namespace` | Namespace in which your Prometheus instance is installed. Default `observability`. Vantage KEDA autoscalers query Prometheus at `prometheus-operated.observability.svc.cluster.local:9090`, so keep Prometheus in the `observability` namespace. |
| `observability.prometheus.serviceMonitor.create` | Create Prometheus `ServiceMonitor` resources to scrape Vantage application metrics. Default `false`. |
| `observability.prometheus.serviceMonitor.selectorMatchLabels` | Labels your Prometheus instance requires to register a `ServiceMonitor`. Match your `Prometheus` resource's `spec.serviceMonitorSelector.matchLabels`. Default `{}`. |
| `observability.prometheus.serviceMonitor.interval` | How often Prometheus scrapes Vantage metrics. KEDA reads these metrics, so the interval also limits how quickly TechCore workers react to queued work. Default `15s`, or `60s` when `vantage.minimalInstall` is `true`. See [Autoscaling with KEDA](https://docs.abbyy.com/vantage/self-hosted/v3.0/performance/autoscaling.md#scale-out-responsiveness). |
| `observability.prometheus.serviceMonitor.scheme` | Scheme for the `ServiceMonitor` scrape endpoints. Unset by default (HTTP). Set `https`, with `tlsConfig`, under Istio `STRICT` mTLS, or under Linkerd when an authorization policy blocks plaintext scrapes. Leave unset under Istio `PERMISSIVE` mTLS. See [Monitoring with Prometheus](https://docs.abbyy.com/vantage/self-hosted/v3.0/monitoring/prometheus.md#istio-mtls). |
| `observability.prometheus.serviceMonitor.tlsConfig` | Prometheus `tlsConfig` for the `ServiceMonitor` scrape endpoints (`caFile`, `certFile`, `keyFile`, `insecureSkipVerify`). Unset by default. Use with `scheme: https`. |
| `vantage.techcore.versions` | TechCore versions to deploy. Accepted values: `2`, `3`, `4`. Default `[3, 4]`. The highest version is the current version. See [TechCore worker deployment](#techcore-worker-deployment). |
| `vantage.techcore.nnTrainingWorkers.enabled` / `gpu` | Deploy the neural-network training workers for the current (highest) TechCore version. `gpu: true` deploys the GPU variants instead of the CPU variants. Defaults `false` / `false`. |

## Inspecting available values

The `vantage-operator` chart is generated by the Kubebuilder Helm plugin. In the `vantage-selfhosted` chart, the `Vantage` custom resource and workloads ConfigMap templates are hand-maintained. To print the values a chart version accepts:

```bash theme={null}
# vantage-operator
helm show values $charts_uri/vantage-operator --version $operator_version

# vantage-selfhosted
helm show values $chart_uri/vantage-selfhosted --version $selfhosted_version
```

`$charts_uri`, `$chart_uri`, and the version variables follow the conventions in [Install variables](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/azure.md#install-variables).

To inspect the rendered manifests before applying:

```bash theme={null}
helm template $release_name $chart_uri/vantage-selfhosted \
  --version $selfhosted_version \
  --namespace $install_namespace \
  -f my-values.yaml
```

## Operator vs Vantage configuration

| Concern | Lives on |
| - | - |
| Operator runtime (image, pull secrets, scheduling, CRD lifecycle, metrics) | `vantage-operator` Helm values |
| Vantage application (secrets, SMTP, workloads, storage, techcore) | `vantage-selfhosted` Helm values → `Vantage.spec` |

## TechCore worker deployment

The `vantage-selfhosted` chart applies a `Vantage` custom resource; the operator then deploys a subset of the TechCore worker charts based on `spec.techcore.*`, as shown in the matrices below.

### Naming convention

Worker charts are named `vtc-{version}-worker-{name}-helm`, where `{version}` is a version listed in `spec.techcore.versions`. The version numbers are pure name prefixes; they have no semantic meaning to the operator. The set of available workers comes from the workloads ConfigMap that the `vantage-selfhosted` chart ships.

### Two deployment passes

| Pass | Versions | Charts considered |
| - | - | - |
| Current version | The highest version in `spec.techcore.versions` | `vtc-{version}-worker*` |
| Previous versions | Every other version in `spec.techcore.versions` | `vtc-{version}-worker*` |

Worker charts for versions not listed in `spec.techcore.versions` are not deployed. To keep an earlier TechCore version's workers running next to the current one, list both versions. The chart default, `[3, 4]`, deploys TechCore 4 as the current version and TechCore 3 as a previous version.

### Inclusion matrix: current version pass

| Chart pattern | Included when |
| - | - |
| `worker-id-reading` | Never (excluded in all configurations) |
| `nn-extraction-training` | `nnTrainingWorkers.enabled: true` and `nnTrainingWorkers.gpu: false` |
| `nn-extraction-training-gpu` | `nnTrainingWorkers.enabled: true` and `nnTrainingWorkers.gpu: true` |
| `nn-nlp-model-train` | `nnTrainingWorkers.enabled: true` and `nnTrainingWorkers.gpu: false` |
| `nn-nlp-model-train-gpu` | `nnTrainingWorkers.enabled: true` and `nnTrainingWorkers.gpu: true` |
| All other workers | Always |

### Inclusion matrix: previous version pass

Runs for every version in `spec.techcore.versions` except the highest.

| Chart pattern | Included when |
| - | - |
| `worker-id-reading` | Never |
| `nn-extraction-training*` (CPU and GPU) | Never (NN training only runs on the current version) |
| `nn-nlp-model-train*` (CPU and GPU) | Never (NN training only runs on the current version) |
| All other workers | Always |

> [!NOTE]
>
> ID reading is a platform-level concern, not a TechCore concern. Its flag, `spec.idReadingEnabled`, lives outside `spec.techcore`. The `worker-id-reading` charts are never deployed. See the [`Vantage.spec` reference](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/latest/api-reference#vantagespec).

The matrix only decides inclusion within whatever workers exist in the workloads ConfigMap for the selected version. Charts that are not present in the workloads for that version are simply unavailable to deploy. For example, `worker-ocr-join` only ships in `vtc-2`'s workload set today, so it deploys only when `spec.techcore.versions` includes `2`, as `vtc-2-worker-ocr-join-helm`.

## What's next

> **[API reference](https://docs.abbyy.com/vantage/self-hosted/v3.0/reference/latest/api-reference.md)**
>
> Field-by-field reference for the `Vantage` custom resource.

> **[Install on Azure](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/azure.md)**
>
> The procedural install that uses these charts.

> **[Self-Managed Kubernetes](https://docs.abbyy.com/vantage/self-hosted/v3.0/providers/self-managed.md)**
>
> Install with customer-managed ingress, mesh, secrets, storage, and data services.