Skip to main content
Azure is the validated provider for Vantage 3.0 self-hosted: Azure Kubernetes Service (AKS) with Azure Key Vault. This page is the complete vertical slice for installing on Azure: prerequisites, identity setup, the Helm install commands, and operational notes. Individual components offer Kubernetes-native alternatives where the CRD supports them, such as the Kubernetes Secrets provider and custom storage.

​
Prerequisites

Before working through this page, confirm the platform prerequisites are in place: Kubernetes, ArgoCD, Helm, and the underlying SQL / Redis / SMTP / OCI registry / object storage services. The Azure-specific items below are layered on top.
ComponentTested versionNotes
Azure Kubernetes Service (AKS)1.33.6The CRD and operator chart are installed into the cluster.
Azure SQL12.0.2000.8 (compatibility level 170, General Purpose Serverless Gen 5)Backs the Vantage databases, one per connection-string alias (23 today). See Database connection strings.
Azure Managed Redis7.4 (EnterpriseCluster)Cache, locks, and client cache usage.
Azure Container Registryn/aDestination registry for OCI migration; your workloads pull Vantage images from it. Migration auth: no auth, basic auth, or Workload Identity + Azure RBAC. For image pulls, see Image pull access.
Azure StorageV2general purpose v2Backs the five storage account connection strings (archive, temporary (old), temporary, permanent, standard). See Storage account connection strings.
Azure Key Vaultn/aHolds every Vantage secret (including the PEM-encoded TLS materials) when using the Azure secrets provider. The identity selected by identityMode must have read access.
AKS Istio Add-onasm-1-28An external ingress gateway must be deployed.
Azure Key Vault Provider for Secrets Store CSI Driver1.7.2 (Helm chart 1.7.2)The CSI provider plugin that fetches secrets at pod startup.
Azure Workload Identityn/aFederate each Vantage chart’s ServiceAccount to a user-assigned managed identity with read access to that chart’s Key Vault aliases. The operator does not create or annotate ServiceAccounts. Also used by the OCI migration job (Workload Identity + Azure RBAC auth) and the in-mesh Prometheus (Azure Monitor). See Secrets and Key Vault.
AKS KEDA Add-on (optional, recommended)2.17.3-5Required for KEDA autoscaling support.
Two more setup tasks must be done before you install. Both are covered below, after the install variables they reference: Connect ArgoCD to your OCI registry and Image pull access.

​
Azure Key Vault secrets

The Vantage operator addresses secrets by alias. The simplest setup on Azure is to create Key Vault secrets named to match each alias; if your provisioning process uses different names, supply an objects mapping under vantage.secrets.azure to remap them. The identity selected by identityMode (see Install variables) must have read access to every secret listed below. The full alias inventory (Platform, Storage, Databases, OAuth) is documented in Secrets and Key Vault. The list below is the same set, reproduced here for the Azure install.

​
Platform

AliasDescription
sendgridApiKeyAPI key for SendGrid. Required unless you configure spec.smtp.
redisConnectionStringConnection string for Redis.
redisCacheConnectionStringConnection string for Redis cache / locks / client cache. May reuse redisConnectionString.
secretStorageUserKeyVaultUriURI to the Azure Key Vault used for secret storage. May be the same vault or a separate one (separate is recommended).

​
Storage account connection strings

AliasDescription
storageArchiveConnectionStringStorage account connection string (“archive”).
storageLegacyTemporaryConnectionStringStorage account connection string (“temporary (old)”).
storageTemporaryConnectionStringStorage account connection string (“temporary”).
storagePermanentConnectionStringStorage account connection string (“permanent”).
storageStandardConnectionStringStorage account connection string (“standard”).
Defer to the base Vantage documentation for what each storage type means.

​
Database connection strings

One alias per distinct database. The database names below are illustrative; use whatever your provisioning process produces, as long as the connection string points to the right database.
AliasDatabase
apiRegistryDatabaseConnectionStringapiregistry
auth2DatabaseConnectionStringauth
authIdentityDatabaseConnectionStringauth-identity
cronServiceDatabaseConnectionStringcron
documentSetStorageDatabaseConnectionStringdocumentset
mailDatabaseConnectionStringmail
securityAuditDatabaseConnectionStringsecurity-audit
storageDatabaseConnectionStringstorage
workflowDatabaseConnectionStringworkflows
catalogStorageDatabaseConnectionStringcatalogstorage
folderImportDatabaseConnectionStringfolderimport
interactiveJobsDatabaseConnectionStringinteractive-jobs
mailImportDatabaseConnectionStringmailimport
permissionsDatabaseConnectionStringpermissions
reportingDatabaseConnectionStringreporting (must support Columnstore Indexing).
secretStorageDatabaseConnectionStringsecretstorage
skillInfoDatabaseConnectionStringskillinfo
skillMonitorDatabaseConnectionStringskillmonitor
subscriptionDatabaseConnectionStringsubscriptions
tokenManagementDatabaseConnectionStringtokenmanagement
transactionsDatabaseConnectionStringtransactions
urlShortenerDatabaseConnectionStringurlshortener
workspaceDatabaseConnectionStringworkspace

​
OAuth

AliasDescription
oAuthGoogleClientIdOAuth Google client ID.
oAuthGoogleClientSecretOAuth Google client secret.
oAuthMicrosoftClientIdOAuth Microsoft client ID.
oAuthMicrosoftClientSecretOAuth Microsoft client secret.

​
Azure Key Vault TLS secrets

The following PEM-encoded TLS materials must be stored as secrets in the Azure Key Vault (not Key Vault certificate objects). The identity selected by identityMode must have read access to all four secret aliases.
AliasDescription
authSigningTlsCrtPEM-encoded certificate for auth signing.
authSigningTlsKeyPEM-encoded private key for auth signing.
authDeactivatedTlsCrtPEM-encoded certificate for auth deactivated tokens.
authDeactivatedTlsKeyPEM-encoded private key for auth deactivated tokens.
The simplest approach is to create two self-signed certificates in Key Vault named auth-signing and auth-deactivated (Common Name = your Vantage dnsRecord value), then create four Key Vault secrets named to match the aliases above. If you use different names, provide an objects mapping in your secrets configuration. For the conceptual model behind how the Secrets Store CSI driver surfaces these into pods, see Secrets and Key Vault.

​
Install variables

Have these values on hand before running the install commands:
VariableDescription
$operator_namespaceNamespace to install the Vantage operator into.
$install_namespaceNamespace to install Vantage into. Any namespace; commonly app.
$operator_versionVersion of the vantage-operator Helm chart.
$selfhosted_versionVersion of the vantage-selfhosted Helm chart.
$charts_uriOCI URI hosting the Vantage operator Helm chart.
$chart_uriOCI URI hosting the vantage-selfhosted Helm chart.
$release_nameHelm release name for vantage-selfhosted.
$your_vantage_hostnameDNS hostname Vantage will be reachable at.
$ingress_tls_secret_nameName of the kubernetes.io/tls secret in the ingress gateway namespace.
$key_vault_name, $tenant_id, $client_idAzure Key Vault name, tenant ID, and client ID of the UAMI with Key Vault read access.
$your_mailfromSender address for outbound mail.
$smtp_host, $smtp_port, $smtp_login, $smtp_passwordOutbound SMTP settings. Optional: omit if using SendGrid (the default; supply sendgridApiKey via your secrets provider).
$your_platformadmin_emailInitial platform admin email.
$your_oci_hostOCI registry host that Vantage artifacts will be migrated into.
$abbyy_oci_source_host, $abbyy_oci_source_repositorySource registry and repository for ABBYY-distributed artifacts. The documented values are abbyy.jfrog.io and abbyy-docker.

​
Connect ArgoCD to your OCI registry

ArgoCD pulls Vantage component charts from your OCI registry, so set up a connection in ArgoCD that gives it access to that registry. ArgoCD is third-party software that you install and maintain, so you create this connection yourself by registering the registry as an ArgoCD repository. See Private Repositories in the ArgoCD documentation. On Azure, the recommended method is Azure Workload Identity, as described in the ArgoCD documentation.

​
Image pull access

Your workloads need to pull images from your registry. Configure pull access in one of two ways. The names my-pull-secret and my-service-account below are example names; substitute your own. Option 1 (Azure): grant AcrPull to the AKS managed identity. Azure deployments can be simplified by granting AcrPull on your Azure Container Registry to the AKS managed identity (the kubelet identity), instead of configuring pull secrets. With this in place you can skip the pull-secret --set flags in Steps 1 and 2. Option 2: Kubernetes image pull secrets. Create a registry pull secret (Kubernetes documentation), then wire it in per component:
ComponentConfiguration
Operator pods--set "manager.imagePullSecrets[0].name=my-pull-secret" on the vantage-operator chart. See Step 1.
OCI migration jobEither run the job under a ServiceAccount that carries the pull secret (vantage.ociMigration.serviceAccountName=my-service-account), or reference the secret on the source entry (vantage.ociMigration.sources[0].credentialsRef.name=my-pull-secret). See Step 2.
Vantage workloadsAdd the pull secret to the imagePullSecrets of the ServiceAccount named by vantage.serviceAccountName. See Step 2.
You create and maintain the role assignments, ServiceAccounts, and pull secrets yourself.

​
Step 1: Install the Vantage operator

Pick a namespace for the operator (it does not need to be app) and install the chart:
If you use pull secrets instead of AcrPull (see Image pull access), append:
See the vantage-operator chart values for additional values you can supply.

​
Step 2: Install Vantage

Install the vantage-selfhosted chart into your chosen namespace, supplying secrets configuration and OCI migration settings:
If you use pull secrets instead of AcrPull (see Image pull access), append the pull configuration for the Vantage workloads and the migration job:
my-service-account is a ServiceAccount you create in $install_namespace with your registry pull secret listed under imagePullSecrets. As an alternative for the migration job, reference the pull secret on the source entry instead:
SendGrid is the default mail provider: supply a sendgridApiKey in your Key Vault and no further mail configuration is needed. To use SMTP instead, append:
vantage.secrets.azure.identityMode defaults to workloadIdentity. To use the legacy pod-identity or VM-managed-identity model, see Secrets and Key Vault.
The --set flags above map directly to fields on the Vantage custom resource and on the vantage-selfhosted chart.

​
Step 3: Monitor installation progress

Wait for the Vantage custom resource to report Ready:
This is the coarse-grained signal; it indicates the Vantage Core installation is complete. Skill installation is tracked by a separate job and may still be running (see below). For finer-grained visibility into the artifact migration, watch the OCI migration job separately:
Once migration is complete, ArgoCD (API or UI) gives the deepest visibility into individual chart sync status. The one exception is skill installation: skills are installed by a separate Kubernetes job that is not surfaced via ArgoCD. You can use Vantage while skill installation is ongoing. Monitor the job directly:

​
Step 4: Access Vantage

Once the resource reports Ready, your Vantage instance is available at:
The skill installer job may still be running at this point. You can sign in and use Vantage while skill installation is ongoing; monitor the job with the commands in Step 3.

​
Azure-specific operational notes

  • Monitoring: On AKS, the recommended pattern is Azure Monitor Workspace + Azure Managed Grafana with an in-mesh Prometheus that scrapes Vantage over Istio mTLS. See Azure Managed Monitoring for the full setup.
  • Workload Identity: The default authentication mode for the Secrets Store CSI driver. Also a supported auth scenario for the OCI migration job (Workload Identity + Azure RBAC) and used by the in-mesh Prometheus that remote-writes to Azure Monitor. See Secrets and Key Vault.

​
What’s next

Architecture

How the operator + ArgoCD + CRD pattern works.

Monitoring

Azure Monitor Workspace + Managed Grafana with an in-mesh Prometheus.

Upgrading

Manual upgrade workflow for moving between Vantage 3.0 versions.

Troubleshooting

Common operator, ArgoCD, Istio, and Key Vault issues.