infisical-standalone helm chart hardcodes DB/Redis env vars when bundled PostgreSQL/Redis are enabled, preventing Secret-based configuration

[bykowskiolaf]

Product

Platform/Access controls/Other

Describe the bug

The infisical-standalone Helm chart always renders literal DB_CONNECTION_URI and REDIS_URL environment variables when postgresql.enabled=true and redis.enabled=true.

This makes it difficult or impossible to configure the Infisical application container using Kubernetes Secrets only. Even when infisical.kubeSecretRef points to a Secret containing DB_CONNECTION_URI and REDIS_URL, the explicitly rendered env entries override the envFrom values.

The chart also supports existing Secrets for the Bitnami PostgreSQL/Redis subcharts, but those Secret values are not used when generating the Infisical application’s own DB_CONNECTION_URI and REDIS_URL.

To Reproduce

1. Install or render infisical-standalone with bundled PostgreSQL and Redis enabled:
   infisical:
   kubeSecretRef: infisical-secrets

postgresql:
enabled: true
auth:
username: infisical
existingSecret: infisical-postgresql
database: infisicalDB

redis:
enabled: true
auth:
existingSecret: infisical-redis

2. Create infisical-secrets containing:
   DB_CONNECTION_URI: postgresql://infisical:@PostgreSQL:5432/infisicalDB
   REDIS_URL: redis://:@redis-master:6379

3. Render the chart:
   helm template infisical infisical-helm-charts/infisical-standalone
   --namespace infisical
   --values values.yaml

4. Inspect the rendered Infisical Deployment.

5. Observe that the container has explicit env vars:

• name: DB_CONNECTION_URI
  value: postgresql://...
• name: REDIS_URL
  value: redis://...

These values are generated from Helm values, not from the referenced Kubernetes Secret.

Expected behavior

The chart should allow DB_CONNECTION_URI and REDIS_URL for the Infisical application container to come from Kubernetes Secrets without requiring plaintext passwords in Helm values.

Screenshots

No response

Deployment Type

Self-hosted

Additional context

Chart tested:
infisical-helm-charts/infisical-standalone

chart version: 1.9.0
app version: 1.0.1

This matters because storing passwords directly in Helm values can leak secrets into Git, Helm release history, CI logs, etc.

I can open a PR for this if the direction makes sense.

My suggested fix would be:

• Change the PostgreSQL env rendering from two independent if blocks to if / else if, so DB_CONNECTION_URI is not rendered twice when postgresql.useExistingPostgresSecret.enabled=true.

• Add equivalent SecretRef support for Redis, for example redis.useExistingRedisSecret, so REDIS_URL can also come from a Kubernetes Secret instead of requiring the Redis password in Helm values.

[linear]

ENG-5350

[bykowskiolaf]

the problematic area is helm-charts/infisical-standalone-postgres/templates/infisical.yaml at lines 72-86.

[sehgalaayu]

can i work on this?

[AyushMukkanwar]

can I work on this issue?

[AkhilTrivediX]

I would like to take this on. I can trace the Helm value precedence for the bundled PostgreSQL and Redis settings, then adjust the template so explicitly supplied Secret-based connection settings are not overwritten by chart defaults. I will add or update a focused helm template regression check for the enabled bundled-service path.

Could a maintainer confirm the expected precedence and that this issue is available for an external contribution before I begin?