# Authentik warm standby on the VPS - Phase 2. The CNPG replica cluster # (manifests/cnpg-cluster.yaml) continuously replays WAL from home in the # background. The app itself DOES run continuously (replicas: 1, reachable # at auth.vps.huskypup.net - see manifests/ingress.yaml) so the replicated # data is browsable/verifiable at all times, even though the underlying DB # is a read-only CNPG replica - writes (new logins, session creation) will # error until a deliberate manual promotion. Promotion runbook: flip the # CNPG cluster's spec.replica.enabled to false (see cnpg-cluster.yaml). # # The `authentik:` block below (secret_key/postgresql "env://" indirection) # is copied VERBATIM from infrastructure/authentik/values.yaml on purpose - # the authentik chart deterministically renders its own generated Secret # from these literal values.yaml strings (not randomly), so keeping this # block byte-identical between home and VPS means both clusters # independently arrive at the same AUTHENTIK_SECRET_KEY without needing to # manually copy it - required for promotion to work, since that key # decrypts things (stored provider secrets, cert private keys) that live # encrypted in the DB being replicated. authentik: secret_key: env://AUTHENTIK_SECRET_KEY postgresql: host: env://AUTHENTIK_POSTGRESQL__HOST port: 5432 name: env://AUTHENTIK_POSTGRESQL__NAME user: env://AUTHENTIK_POSTGRESQL__USER password: env://AUTHENTIK_POSTGRESQL__PASSWORD global: envFrom: - secretRef: name: authentik - secretRef: name: pg-authentik-app prefix: AUTHENTIK_POSTGRESQL__ env: - name: AUTHENTIK_URL value: "https://auth.vps.huskypup.net" - name: AUTHENTIK_POSTGRESQL__HOST valueFrom: secretKeyRef: name: pg-authentik-app key: host - name: AUTHENTIK_POSTGRESQL__NAME valueFrom: secretKeyRef: name: pg-authentik-app key: dbname - name: AUTHENTIK_POSTGRESQL__USER valueFrom: secretKeyRef: name: pg-authentik-app key: username - name: AUTHENTIK_POSTGRESQL__PASSWORD valueFrom: secretKeyRef: name: pg-authentik-app key: password - name: AUTHENTIK_POSTGRESQL__PORT value: "5432" server: replicas: 1 # Default failureThreshold: 3 (40s runway) is too strict running against # a read-only CNPG replica - the worker constantly retries a scheduled- # task query that needs a write lock (harmless, expected, logged as # 'cannot execute SELECT FOR UPDATE in a read-only transaction'), and # any transient DB hiccup during that trips the server's health check # and gets it killed (confirmed live: CrashLoopBackOff, 'connection # refused' during a brief blip). Widened so brief hiccups don't kill it. livenessProbe: failureThreshold: 10 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 5 readinessProbe: failureThreshold: 10 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 5 containerSecurityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: - ALL seccompProfile: type: RuntimeDefault resources: requests: cpu: 50m memory: 512Mi limits: memory: 1Gi metrics: enabled: false worker: replicas: 1 containerSecurityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: - ALL seccompProfile: type: RuntimeDefault resources: requests: cpu: 50m memory: 512Mi limits: memory: 1Gi metrics: enabled: false # Disable bundled Postgres - using the CNPG replica cluster instead postgresql: enabled: false