Check for existing issues

• I have searched existing issues and this appears related to (but not resolved by):
  • #13544
  • #21716

What happened?

When deploying litellm-helm 1.1.0 via ArgoCD with bundled Postgres (db.deployStandalone=true) and postgresql.auth.existingSecret set, LiteLLM still uses/creates litellm-dbcredentials in a way that drifts from the intended secret.

In our test, litellm-credentials had the correct password, but litellm-dbcredentials ended up with a different/default value (e.g. NoTaGrEaTpAsSwOrD). LiteLLM then failed Prisma DB auth (P1000) and stayed in CrashLoopBackOff.

What I expected

• If db.dbCredentialsSecretName and postgresql.auth.existingSecret are both set to the same Secret, all DB auth values should remain consistent.
• The chart should not render or preserve conflicting DB credentials that make LiteLLM fail against the bundled Postgres.

Environment

• Chart: litellm-helm:1.1.0
• Deployment method: ArgoCD Application
• Cluster: k3s
• LiteLLM image: ghcr.io/berriai/litellm:main-v1.83.14-stable
• Postgres image: bitnamilegacy/postgresql

Steps to Reproduce

1. Create litellm-credentials secret with consistent values (password, postgres-password, redis-password, etc.).
2. Deploy with:
   • db.useExisting: false
   • db.deployStandalone: true
   • db.dbCredentialsSecretName: litellm-credentials
   • postgresql.auth.existingSecret: litellm-credentials
3. Sync ArgoCD app and wait for pods.
4. Observe LiteLLM pod logs and secret values.

Relevant ArgoCD Application YAML (sanitized minimal repro)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: litellm
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: agents
  source:
    repoURL: registry.registry.svc.cluster.local:5000/helm-charts
    chart: litellm-helm
    targetRevision: 1.1.0
    helm:
      releaseName: litellm
      valuesObject:
        image:
          repository: m.daocloud.io/ghcr.io/berriai/litellm
          tag: main-v1.83.14-stable
        migrationJob:
          enabled: false
        db:
          useExisting: false
          deployStandalone: true
          disableSchemaUpdate: true
          dbCredentialsSecretName: litellm-credentials
        postgresql:
          auth:
            username: litellm
            database: litellm
            existingSecret: litellm-credentials
            secretKeys:
              userPasswordKey: postgres-password
              adminPasswordKey: postgres-password
        redis:
          enabled: true
          auth:
            enabled: true
            existingSecret: litellm-credentials
            existingSecretPasswordKey: redis-password

Relevant log output

PrismaClientInitializationError: Authentication failed against database server ... (P1000)

(After this, LiteLLM repeatedly restarts.)

Temporary workaround that unblocks us

Patch litellm-dbcredentials to match litellm-credentials.password/postgres-password, then restart LiteLLM pod:

PASS=$(kubectl get secret -n agents litellm-credentials -o jsonpath='{.data.password}')
kubectl patch secret -n agents litellm-dbcredentials --type merge -p "{\"data\":{\"password\":\"$PASS\",\"postgres-password\":\"$PASS\"}}"
kubectl delete pod -n agents -l app.kubernetes.io/name=litellm

After this patch, LiteLLM starts successfully and serves traffic.

Request

Could maintainers clarify intended precedence and fix chart behavior so standalone mode does not generate/retain conflicting DB credentials when existingSecret is explicitly provided?