chore(helm): update ENCRYPTION_KEY docs to reflect automatic fallback

Existing installs no longer need to manually set ENCRYPTION_KEY to their
old JWT secret on upgrade — the server falls back to data/.jwt_secret
automatically. Update values.yaml, NOTES.txt, and chart README accordingly.

chart/README.md

@@ -29,6 +29,6 @@ See `values.yaml` for more options.
 - Ingress is off by default. Enable and configure hosts for your domain.
 - PVCs require a default StorageClass or specify one as needed.
 - `JWT_SECRET` is managed entirely by the server — auto-generated into the data PVC on first start and rotatable via the admin panel (Settings → Danger Zone). No Helm configuration needed.
-- `ENCRYPTION_KEY` encrypts stored secrets (API keys, MFA, SMTP, OIDC) at rest. Auto-generated and persisted to the data PVC if not provided. **Upgrading:** if a previous version used `JWT_SECRET`-derived encryption, set `secretEnv.ENCRYPTION_KEY` to your old `JWT_SECRET` value to keep existing encrypted data readable, then re-save credentials via the admin panel.
+- `ENCRYPTION_KEY` encrypts stored secrets (API keys, MFA, SMTP, OIDC) at rest. Recommended: set via `secretEnv.ENCRYPTION_KEY` or `existingSecret`. If left empty, the server falls back automatically: existing installs use `data/.jwt_secret` (no action needed on upgrade); fresh installs auto-generate a key persisted to the data PVC.
 - If using ingress, you must manually keep `env.ALLOWED_ORIGINS` and `ingress.hosts` in sync to ensure CORS works correctly. The chart does not sync these automatically.
 - Set `env.ALLOW_INTERNAL_NETWORK: "true"` if Immich or other integrated services are hosted on a private/RFC-1918 address (e.g. a pod on the same cluster or a NAS on your LAN). Loopback (`127.x`) and link-local/metadata addresses (`169.254.x`) remain blocked regardless.

chart/templates/NOTES.txt

@@ -4,10 +4,9 @@
    - To generate a random key at install (preserved across upgrades), set `generateEncryptionKey: true`.
    - To use an existing Kubernetes secret, set `existingSecret` to the secret name. The secret must
      contain a key matching `existingSecretKey` (defaults to `ENCRYPTION_KEY`).
-   - If left empty, the server auto-generates and persists the key to the data PVC — safe as long as
-     the PVC persists.
-   - Upgrading from a version that used JWT_SECRET for encryption: set `secretEnv.ENCRYPTION_KEY` to
-     your old JWT_SECRET value, then re-save credentials via the admin panel.
+   - If left empty, the server resolves the key automatically: existing installs fall back to
+     data/.jwt_secret (encrypted data stays readable with no manual action); fresh installs
+     auto-generate a key persisted to the data PVC.
 
 2. JWT_SECRET is managed entirely by the server:
    - Auto-generated on first start and persisted to the data PVC (data/.jwt_secret).

chart/values.yaml

@@ -27,10 +27,10 @@ env:
 # rotatable via the admin panel) — it is not configured here.
 secretEnv:
   # At-rest encryption key for stored secrets (API keys, MFA, SMTP, OIDC, etc.).
-  # Auto-generated and persisted to the data PVC if not set.
-  # Upgrading from a version that used JWT_SECRET for encryption: set this to your
-  # old JWT_SECRET value to keep existing encrypted data readable, then re-save
-  # credentials via the admin panel and rotate to a fresh random key.
+  # Recommended: set to a random 32-byte hex value (openssl rand -hex 32).
+  # If left empty the server resolves the key automatically:
+  #   1. data/.jwt_secret (existing installs — encrypted data stays readable after upgrade)
+  #   2. data/.encryption_key auto-generated on first start (fresh installs)
   ENCRYPTION_KEY: ""
 
 # If true, a random ENCRYPTION_KEY is generated at install and preserved across upgrades