Add three layers for setting environment variables:
- env: plain key-value map for any vaultwarden env var
- secretEnv: shorthand for secretKeyRef without verbose YAML
- extraEnv: raw Kubernetes env spec for complex cases (fieldRef, etc.)
This lets users set any vaultwarden env var without requiring chart
changes, while the structured values (vaultwarden.smtp.*, database.*, etc.)
remain available for validation and existingSecret integration.
The chart provides three layers for setting environment variables, from simplest to most flexible:
**`env`** — plain key-value map for any vaultwarden env var:
```yaml
env:
SIGNUPS_ALLOWED: "true"
INVITATION_ORG_NAME: "My Org"
SENDS_ALLOWED: "true"
```
**`secretEnv`** — shorthand for sourcing env vars from Kubernetes secrets:
```yaml
secretEnv:
ADMIN_TOKEN:
secretName: my-admin-secret
secretKey: admin-token
DATABASE_URL:
secretName: my-db-secret
secretKey: database-url
```
**`extraEnv`** — raw Kubernetes env spec for complex cases (fieldRef, resourceFieldRef, etc.):
```yaml
extraEnv:
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
```
These layers are additive and render in order: structured values (from `vaultwarden.*`), then `env`, then `secretEnv`, then `extraEnv`. Later values override earlier ones for the same env var name.
## Using Existing Secrets
For production deployments, use `existingSecret` references instead of putting credentials in `values.yaml`. All sensitive values support `existingSecret`: