# Vault warm standby on the VPS - Phase 2 of the VPS plan.
#
# This is NOT an independent Vault with its own root of trust. It exists
# purely to periodically absorb home Vault's raft snapshots (already
# flowing to this VPS's own MinIO via infrastructure/vault/manifests/
# raft-snapshot-cronjob.yaml) so it can be promoted quickly during a real
# home outage. See manifests/restore-cronjob.yaml for the restore loop.
#
# Deliberately scoped-down from home Vault's offline-Shamir-share posture:
# single node, single-key auto-unseal via a key copied to this cluster
# (kubectl, not git - see manifests/restore-cronjob.yaml's header comment
# for why a copy of the real key, not a fresh one, is required here).
# Acceptable because this is a read-only standby, not the root of trust,
# and there's no independent data at stake - restoring a raft snapshot
# overwrites everything here with home's actual state (and keyring) on
# every cycle.
server:
  standalone:
    enabled: true
    config: |
      ui = true
      listener "tcp" {
        address     = "0.0.0.0:8200"
        tls_disable = 1
      }
      storage "raft" {
        path = "/vault/data"
      }
      disable_mlock = true

  ha:
    enabled: false

  dataStorage:
    enabled: true
    size: 5Gi
    storageClass: local-path

  resources:
    requests:
      cpu: 50m
      memory: 128Mi
    limits:
      memory: 512Mi

  # No ingress/public exposure - reached over Netbird from home while it's
  # up, or directly on the VPS during an actual promoted-standby incident.
  service:
    enabled: true

injector:
  enabled: false  # no sidecar-injection use case on a restore-only standby

ui:
  enabled: true