fix: security release 2026-07-08 (#4316)

docs/self-hosting/docker.mdx

@@ -75,12 +75,23 @@ git clone --depth=1 https://github.com/triggerdotdev/trigger.dev
 cd trigger.dev/hosting/docker
 ```
 
-2. Create a `.env` file
+2. Create a `.env` file and generate secrets
 
 ```bash
 cp .env.example .env
+
+# Fills the required secrets in .env with strong, unique values.
+# Safe to re-run - it never overwrites a secret you've already set.
+./generate-secrets.sh
 ```
 
+<Note>
+  The stack ships no working default credentials. `generate-secrets.sh` fills the
+  application secrets and the bundled datastore passwords with strong, unique values.
+  Keep them safe - rotating the encryption key or session secret later will invalidate
+  existing sessions and encrypted data.
+</Note>
+
 3. Start the webapp
 
 ```bash
@@ -130,6 +141,13 @@ docker compose up -d
 
 4. Configure the supervisor using the [environment variables](/self-hosting/env/supervisor) in your `.env` file, including the [worker token](#worker-token).
 
+<Warning>
+  For a split webapp/worker setup, set `MANAGED_WORKER_SECRET` on the worker to
+  the **same** value as the webapp's `MANAGED_WORKER_SECRET`. Don't run
+  `generate-secrets.sh` on the worker host - it would create a mismatched value
+  and the worker would fail to authenticate.
+</Warning>
+
 5. Apply the changes:
 
 ```bash

docs/self-hosting/env/webapp.mdx

@@ -11,7 +11,8 @@ mode: "wide"
 | `SESSION_SECRET`                                 | Yes      | —                     | Session encryption secret. Run: `openssl rand -hex 16`                                                             |
 | `MAGIC_LINK_SECRET`                              | Yes      | —                     | Magic link encryption secret. Run: `openssl rand -hex 16`                                                          |
 | `ENCRYPTION_KEY`                                 | Yes      | —                     | Secret store encryption key. Run: `openssl rand -hex 16`                                                           |
-| `MANAGED_WORKER_SECRET`                          | No       | managed-secret        | Managed worker secret. Should be changed and match supervisor.                                                     |
+| `MANAGED_WORKER_SECRET`                          | Yes      | —                     | Managed worker secret. Must be set and match supervisor. Run: `openssl rand -hex 32`                               |
+| `ALLOW_INSECURE_DEFAULT_SECRETS`                 | No       | false                 | Boot even if a secret is still a known-insecure published default. Temporary escape hatch for values you can't safely rotate yet (see [Secret generation and rotation](/self-hosting/kubernetes#secret-generation-and-rotation)). |
 | **Domains & ports**                              |          |                       |                                                                                                                    |
 | `REMIX_APP_PORT`                                 | No       | 3030                  | Remix app port.                                                                                                    |
 | `APP_ORIGIN`                                     | Yes      | http://localhost:3030 | App origin URL.                                                                                                    |

docs/self-hosting/kubernetes.mdx

@@ -121,8 +121,10 @@ The default values are insecure and are only suitable for testing. You will need
 Create a `values-custom.yaml` file to override the defaults. For example:
 
 ```yaml
-# Generate new secrets with `openssl rand -hex 16`
-# WARNING: You should probably use an existingSecret instead
+# Leave these unset to have the chart auto-generate strong values on first
+# install (retained across upgrades). Set them explicitly only if you need to
+# control the value - e.g. sharing MANAGED_WORKER_SECRET with an external
+# supervisor - or use an existingSecret.
 secrets:
   enabled: true
   sessionSecret: "your-32-char-hex-secret-1"
@@ -133,6 +135,8 @@ secrets:
 # - SESSION_SECRET
 # - MAGIC_LINK_SECRET
 # - ENCRYPTION_KEY
+# - PROVIDER_SECRET
+# - COORDINATOR_SECRET
 # - MANAGED_WORKER_SECRET
 # - OBJECT_STORE_ACCESS_KEY_ID
 # - OBJECT_STORE_SECRET_ACCESS_KEY
@@ -176,6 +180,24 @@ helm upgrade -n trigger --install trigger \
   -f values-custom.yaml
 ```
 
+### Secret generation and rotation
+
+Application, control-plane, and bundled-datastore secrets left unset are generated on
+first install and **retained across `helm upgrade`** - they are never rotated
+automatically, so sessions, encrypted data, and datastore volumes survive upgrades.
+
+<Warning>
+  GitOps tools that render with `helm template` (e.g. Argo CD) cannot read the existing
+  secret, so they regenerate these values on every sync - which rotates them. If you
+  deploy via GitOps, always supply your own `secrets.existingSecret` (and datastore
+  credentials) so nothing is generated in-cluster.
+</Warning>
+
+There is no clean migration for a compromised `ENCRYPTION_KEY`: changing it makes
+existing encrypted data unreadable. If a deployment is still running a previously
+published default and cannot rotate yet, set `ALLOW_INSECURE_DEFAULT_SECRETS=true` on
+the webapp to keep booting while you plan a migration.
+
 ### Extra env
 
 You can set extra environment variables on all services. For example: