You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/self-hosting/docker.mdx
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -362,6 +362,17 @@ TRIGGER_IMAGE_TAG=v4.5.0
362
362
363
363
We patch the latest released version line only, so keep an eye on new releases to receive security fixes. See [Security & vulnerability reporting](/self-hosting/security).
364
364
365
+
You can also lock the versions of the bundled services, for example with `CLICKHOUSE_IMAGE_TAG`. If you do, or if you bring your own ClickHouse via `CLICKHOUSE_URL`, note that Trigger.dev requires ClickHouse 25.8 or newer.
366
+
367
+
<Note>
368
+
The bundled ClickHouse now uses the official `clickhouse/clickhouse-server` image. Your existing
369
+
data volume carries over automatically. If you previously pinned `CLICKHOUSE_IMAGE_TAG` to a
370
+
Bitnami tag (for example `25.7.5-debian-12-r0`), update it to an official image tag such as
371
+
`26.2` — Bitnami tags don't exist in the official repository. Note the switch is one-way: the
372
+
official image takes ownership of the data files, so rolling back to the Bitnami image requires
373
+
manually restoring their previous owner (`chown -R 1001:1001` on the volume).
374
+
</Note>
375
+
365
376
<Note>
366
377
Trigger.dev 4.5.0 is the last version we officially support for running v3 (SDK v3) tasks. If
367
378
you still have v3 tasks, pin `TRIGGER_IMAGE_TAG` to exactly `v4.5.0` or [migrate to
`helm upgrade` keeps generated secrets, PVCs, and datastore volumes, so most upgrades need no preparation. These chart versions are the exceptions.
86
+
87
+
### 4.5.6: two new required secret keys
88
+
89
+
The webapp now reads `PROVIDER_SECRET` and `COORDINATOR_SECRET`. When you supply `secrets.existingSecret` the chart generates nothing and reads every key from your Secret, so both keys must exist there before you upgrade. Inline `secrets.*` values are ignored while `existingSecret` is set.
The chart checks your Secret in a pre-upgrade hook and aborts with the list of missing keys, leaving the running release untouched. Without that check a missing key surfaces as a `CreateContainerConfigError` partway through the webapp rollout.
99
+
100
+
<Note>
101
+
GitOps tools that render with `helm template` have no cluster access, so the check is
102
+
skipped and a missing key still reaches the rollout. Verify the keys yourself before syncing.
103
+
</Note>
104
+
105
+
### 4.5.6: ClickHouse credentials moved
106
+
107
+
The bundled ClickHouse password moved out of the subchart-generated Secret and into the chart-managed datastore Secret:
The webapp and the ClickHouse server both read the new location, so the upgrade itself needs no action. Repoint anything outside the chart that reads the old Secret — a maintenance CronJob, a Grafana datasource, an external secret sync:
The same move applies to the bundled PostgreSQL (`postgres-password`) and MinIO (`minio-root-user`, `minio-root-password`).
122
+
123
+
### Bitnami ClickHouse to the official image
124
+
125
+
The bundled ClickHouse runs the official `clickhouse/clickhouse-server` image instead of the Bitnami subchart. The chart adopts your existing data volume automatically, with three caveats covered under [ClickHouse](#clickhouse) in external services: rendering without cluster access, pinned Bitnami image tags, and storage that doesn't support `fsGroup`.
126
+
127
+
<Note>
128
+
The data volume is `ReadWriteOnce`, so during the upgrade the new ClickHouse pod may sit in
129
+
`ContainerCreating` with a multi-attach warning for a minute while the old pod still holds the
130
+
volume. This clears itself once the old pod is removed later in the same upgrade - don't abort.
131
+
</Note>
132
+
83
133
## Configuration
84
134
85
135
Most values map directly to the environment variables documented in the [webapp](/self-hosting/env/webapp) and [supervisor](/self-hosting/env/supervisor) environment variable overview.
@@ -138,8 +188,9 @@ secrets:
138
188
# - PROVIDER_SECRET
139
189
# - COORDINATOR_SECRET
140
190
# - MANAGED_WORKER_SECRET
141
-
# - OBJECT_STORE_ACCESS_KEY_ID
142
-
# - OBJECT_STORE_SECRET_ACCESS_KEY
191
+
# Plus s3-auth-access-key-id and s3-auth-secret-access-key if you deploy the
192
+
# bundled MinIO with s3.auth.existingSecret cleared. The chart lists any keys
193
+
# it can't find and fails the install before touching a running release.
143
194
secrets:
144
195
enabled: false
145
196
existingSecret: "your-existing-secret"
@@ -279,26 +330,64 @@ redis:
279
330
280
331
#### ClickHouse
281
332
333
+
<Note>Trigger.dev requires ClickHouse 25.8 or newer.</Note>
334
+
335
+
<Note>
336
+
When upgrading from a chart version that bundled ClickHouse via the Bitnami subchart, the chart
337
+
automatically adopts the existing data volume, so no manual migration is needed. If you render
338
+
manifests without cluster access (for example with GitOps tools that use `helm template`), set
339
+
`clickhouse.persistence.existingClaim`to the old PVC name
340
+
(`data-<release>-clickhouse-shard0-0`) to keep your data — auto-detection can't run there, and
341
+
skipping this starts ClickHouse on a fresh empty volume. If that happened, your old data is
342
+
still on the old PVC: delete the ClickHouse StatefulSet with `--cascade=orphan` (its volume
343
+
configuration is immutable), set `existingClaim`, and sync again. If you render without cluster
344
+
access, pin `clickhouse.persistence.existingClaim` for good once the volume is adopted: a later
345
+
render where the lookup can't see the PVC would otherwise try to re-add `volumeClaimTemplates`,
346
+
which the API server rejects on an existing StatefulSet.
347
+
</Note>
348
+
349
+
<Note>
350
+
If you pinned `clickhouse.image` to a Bitnami repository or tag in your values, update it to
351
+
the official `clickhouse/clickhouse-server` image — Bitnami tags don't exist there. The
352
+
bundled ClickHouse is single-node: the old Bitnami subchart keys (`shards`, `replicaCount`,
353
+
`keeper`) are no longer supported, so use an external ClickHouse for clustered setups.
354
+
</Note>
355
+
356
+
<Note>
357
+
When a volume is adopted from the Bitnami-based chart, a one-time init container fixes its
358
+
ownership for the non-root ClickHouse server. This runs automatically on `helm upgrade` (and
359
+
when you set `clickhouse.persistence.existingClaim`), so storage that doesn't support `fsGroup`
360
+
ownership changes (NFS, hostPath, local-path) works without manual steps. Set
361
+
`clickhouse.volumePermissions.enabled: true` to force it in other cases.
362
+
</Note>
363
+
282
364
**Direct configuration:**
283
365
284
366
```yaml
285
367
clickhouse:
286
368
deploy: false
287
369
external:
288
370
host: "my-clickhouse.example.com"
289
-
port: 8123
371
+
httpPort: 8123
290
372
username: "my-username"
291
373
password: "my-password"
292
374
```
293
375
376
+
<Note>
377
+
An inline external `username`/`password` is percent-encoded into the connection URL for you, so
378
+
store the **raw** value - special characters like `@ : / %` are handled automatically. If you
379
+
previously percent-encoded the password by hand to work around this, switch back to the raw value.
380
+
(Credentials from `existingSecret` are injected at runtime and are unaffected.)
0 commit comments