> ## 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. # Architecture > How the Vantage Kubernetes operator, the Vantage custom resource, and ArgoCD work together to install, configure, and update Vantage 3.0 self-hosted. Vantage 3.0 self-hosted is built around three components: a Kubernetes operator, a single user-facing custom resource (`Vantage`), and ArgoCD. You apply a `Vantage` object describing the desired installation; the operator reconciles the installation state to match the resource, delegating per-component sync to ArgoCD. This page explains the moving parts conceptually. For field-level details, see the [API reference](/vantage/self-hosted/v3.0/api-reference). ## Why this pattern Vantage 2.7 self-hosted ran on ABBYY-provided Ansible playbooks and Azure CLI scripts that installed both the application and supporting infrastructure in one shot. That model is not supported in 3.0. The 3.0 operator separates concerns: * **Infrastructure**: provisioned by you, outside the operator's scope. ABBYY does not provide provisioning automation for 3.0. * **Application**: described declaratively in the `Vantage` resource. The operator handles dependency resolution for the Vantage Core components, artifact migration, and reconciliation through ArgoCD. Third-party software that Vantage relies on, such as ArgoCD, your service mesh and ingress controller, your secrets integration, and your monitoring stack, falls outside both: you install it yourself before installing Vantage. The result: upgrades are performed by installing matching new versions of the `vantage-operator` and `vantage-selfhosted` Helm charts. ## The `Vantage` custom resource The CRD is registered at `vantage.abbyy.com/v1alpha1`. A minimal resource looks like this (illustrative; see the [API reference](/vantage/self-hosted/v3.0/api-reference) for the complete spec): ```yaml theme={null} apiVersion: vantage.abbyy.com/v1alpha1 kind: Vantage metadata: name: vantage namespace: vantage spec: dnsRecord: vantage.example.com mailFrom: noreply@example.com platformAdminEmail: admin@example.com vantageVersion: "3.0.x" secrets: azure: keyVaultName: mykeyvault tenantId: 00000000-... clientId: 00000000-... # client ID of the UAMI with Key Vault read access identityMode: workloadIdentity # workloadIdentity (default) | podIdentity | vmManagedIdentity smtp: host: smtp.example.com port: 587 workloads: configMap: vantage-workloads metadataTemplateKey: metadata secretsKey: secrets workloadsKey: workloads ``` `spec.secrets` is required, and exactly one provider (`azure` or `kubernetes`) must be specified. `spec.smtp` is optional; omit it to use the default SendGrid mail provider (supply a `sendgridApiKey` via your secrets provider). See [Secrets and Key Vault](/vantage/self-hosted/v3.0/secrets-and-keyvault) for the supported providers. In practice you set most of these through the `vantage-selfhosted` Helm chart. See [Azure](/vantage/self-hosted/v3.0/providers/azure) or [Self-Managed Kubernetes](/vantage/self-hosted/v3.0/providers/self-managed). ## Key concepts ### Workloads ConfigMap `spec.workloads` points the operator at a `ConfigMap` containing the manifest of charts and images that make up a Vantage version. The operator reads this manifest, runs OCI migration to copy artifacts into your registry, then generates ArgoCD `Application` manifests for each component. The ConfigMap is built and published by ABBYY as part of every Vantage release. ### Secrets and certificates The operator does not store secrets directly. Two secrets providers are supported (Azure Key Vault via the Secrets Store CSI driver, and pre-existing Kubernetes `Secret` resources), and exactly one is configured per install. See [Secrets and Key Vault](/vantage/self-hosted/v3.0/secrets-and-keyvault) for the supported providers, identity modes, and the full alias inventory. ### OCI migration `spec.ociMigration` declares a one-time job that copies artifacts from one or more configured source registries into your destination registry before install. Once migration completes, every subsequent component pull is from your own registry. ArgoCD pulls the component charts from that registry through a repository connection you configure yourself. Destination authentication supports no auth, basic auth, or Azure Workload Identity with Azure RBAC. Workloads also need pull access through Kubernetes image pull Secrets or, on Azure, `AcrPull` granted to the AKS managed identity. See [Azure image pull access](/vantage/self-hosted/v3.0/providers/azure#image-pull-access) or [self-managed registry access](/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access). ### Skill installation Skills are installed by a separate Kubernetes job in the install namespace, not by one of the operator-generated ArgoCD applications, so ArgoCD does not show skill installation progress. The `Vantage` resource can report `Ready` while the job is still running, and Vantage is usable in the meantime. Monitoring commands are in [Lifecycle](/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately). ## Runtime contract The operator's runtime contract (how it processes the `Vantage` resource, what conditions it publishes back, and how to force a retry) is documented separately from this conceptual overview. See [Lifecycle](/vantage/self-hosted/v3.0/lifecycle). ## What's next Field-by-field reference for every spec and status property. Reconcile phases, status conditions, and forcing a retry. Reference for every Helm value the operator and Vantage charts accept. Diagnose common operator, ArgoCD, secrets, database, ingress, and mesh issues.