bug: v4.4.6 self-hosted webapp fails to start due to ClickHouse URL secure param mismatch (goose entrypoint + Runs Replication client) #3674

Provide environment information

Provide environment information

• Trigger.dev version: v4.4.6 (self-hosted Docker, ghcr.io/triggerdotdev/trigger.dev:v4.4.6)
• Setup: standard hosting/docker compose, multi-file (webapp/docker-compose.yml + worker/docker-compose.yml)
• ClickHouse: bitnamilegacy/clickhouse:latest, HTTP only (no TLS), port 8123, local container
• Host: Linux amd64
• Previous working version: v4.4.5 (same .env, started healthy)

Describe the bug

After updating the image tag from v4.4.5 to v4.4.6 and running docker compose pull && up -d, the webapp container enters a restart loop. Two separate ClickHouse-URL handling issues block startup, related to but not fully covered by #3184 / #3204.

Issue 1 — entrypoint.sh appends ?secure=true unconditionally, goose now rejects it

docker/scripts/entrypoint.sh constructs GOOSE_DBSTRING from CLICKHOUSE_URL and adds ?secure=true if secure= isn't already in the URL — regardless of scheme. When the URL uses http:// (no TLS), the goose ClickHouse driver in v4.4.6 fails DSN parsing:

+ export GOOSE_DBSTRING=http://default:***@clickhouse:8123?secure=true
+ /usr/local/bin/goose up
2026/05/20 10:13:56 goose run: clickhouse [dsn parse]: http with TLS specify; clickhouse [dsn parse]: http with TLS specify

This appears to be a behavior change in the goose ClickHouse driver between v4.4.5 and v4.4.6 — the same DSN was tolerated by the older driver. entrypoint.sh exits non-zero, container restarts forever.

Issue 2 — RUN_REPLICATION_CLICKHOUSE_URL is NOT stripped before being passed to @clickhouse/client

#3204 added stripping of the secure query param for QUERY_CLICKHOUSE_URL, but RUN_REPLICATION_CLICKHOUSE_URL follows the same path through @clickhouse/client@1.12.1 and doesn't get the same treatment. Workarounding Issue 1 by adding ?secure=false to RUN_REPLICATION_CLICKHOUSE_URL (because the main CLICKHOUSE_URL workaround value is reused as the replication URL in some setups) triggers:

🗃️ Runs replication service enabled
{"url":"http://default:redacted@clickhouse:8123/?secure=false", ...}
Error: Unknown URL parameters: secure
    at loadConfigOptionsFromURL (.../config.js:267:19)
    at prepareConfigWithURL (.../config.js:42:34)
    at new ClickHouseClient (.../client.js:59:65)
    at createClient (.../@clickhouse+client@1.12.1/.../client.js:15:12)
    at new ClickhouseClient (.../webapp/build/index.js:49830:243)
    at new ClickHouse (.../webapp/build/index.js:63805:21)
    at initializeRunsReplicationInstance (.../webapp/build/index.js:190055:20)

To reproduce

1. Self-host v4.4.5 with HTTP ClickHouse (no TLS), CLICKHOUSE_URL=http://...@clickhouse:8123, healthy.
2. Bump TRIGGER_IMAGE_TAG to v4.4.6, docker compose pull && up -d.
3. Observe webapp in restart loop, goose error in logs (Issue 1).
4. Append ?secure=false to CLICKHOUSE_URL and RUN_REPLICATION_CLICKHOUSE_URL — goose now passes, but webapp now crashes on Runs Replication init (Issue 2).

Workaround (currently running in production)

Asymmetric values:

CLICKHOUSE_URL=http://default:***@clickhouse:8123?secure=false
RUN_REPLICATION_CLICKHOUSE_URL=http://default:***@clickhouse:8123

• CLICKHOUSE_URL ends with ?secure=false so entrypoint.sh's grep -q secure= matches and skips appending ?secure=true. goose accepts secure=false + http:// (no conflict). Webapp's own CLICKHOUSE_URL consumption already strips secure via fix(webapp): strip secure param from query ClickHouse URL #3204, so the param is harmless there.
• RUN_REPLICATION_CLICKHOUSE_URL stays clean — it goes to @clickhouse/client without stripping.

This works but is fragile and undiscoverable.

Suggested fix

Two independent things to address:

1. docker/scripts/entrypoint.sh — only append ?secure=true when the URL scheme is https://. Or, simpler: strip the param entirely before calling goose and translate it to the scheme (https:// → secure=true, http:// → no flag). Conflating TLS choice with a query param when the scheme already encodes it is the root issue.

2. initializeRunsReplicationInstance — apply the same secure strip that QUERY_CLICKHOUSE_URL got in fix(webapp): strip secure param from query ClickHouse URL #3204 to RUN_REPLICATION_CLICKHOUSE_URL (and any other URL passed to @clickhouse/client). Centralizing this in a helper used by all client constructors would prevent regressions.

Describe the bug

Provide environment information

• Trigger.dev version: v4.4.6 (self-hosted Docker, ghcr.io/triggerdotdev/trigger.dev:v4.4.6)
• Setup: standard hosting/docker compose, multi-file (webapp/docker-compose.yml + worker/docker-compose.yml)
• ClickHouse: bitnamilegacy/clickhouse:latest, HTTP only (no TLS), port 8123, local container
• Host: Linux amd64
• Previous working version: v4.4.5 (same .env, started healthy)

Describe the bug

After updating the image tag from v4.4.5 to v4.4.6 and running docker compose pull && up -d, the webapp container enters a restart loop. Two separate ClickHouse-URL handling issues block startup, related to but not fully covered by #3184 / #3204.

Issue 1 — entrypoint.sh appends ?secure=true unconditionally, goose now rejects it

docker/scripts/entrypoint.sh constructs GOOSE_DBSTRING from CLICKHOUSE_URL and adds ?secure=true if secure= isn't already in the URL — regardless of scheme. When the URL uses http:// (no TLS), the goose ClickHouse driver in v4.4.6 fails DSN parsing:

+ export GOOSE_DBSTRING=http://default:***@clickhouse:8123?secure=true
+ /usr/local/bin/goose up
2026/05/20 10:13:56 goose run: clickhouse [dsn parse]: http with TLS specify; clickhouse [dsn parse]: http with TLS specify

This appears to be a behavior change in the goose ClickHouse driver between v4.4.5 and v4.4.6 — the same DSN was tolerated by the older driver. entrypoint.sh exits non-zero, container restarts forever.

Issue 2 — RUN_REPLICATION_CLICKHOUSE_URL is NOT stripped before being passed to @clickhouse/client

#3204 added stripping of the secure query param for QUERY_CLICKHOUSE_URL, but RUN_REPLICATION_CLICKHOUSE_URL follows the same path through @clickhouse/client@1.12.1 and doesn't get the same treatment. Workarounding Issue 1 by adding ?secure=false to RUN_REPLICATION_CLICKHOUSE_URL (because the main CLICKHOUSE_URL workaround value is reused as the replication URL in some setups) triggers:

🗃️ Runs replication service enabled
{"url":"http://default:redacted@clickhouse:8123/?secure=false", ...}
Error: Unknown URL parameters: secure
    at loadConfigOptionsFromURL (.../config.js:267:19)
    at prepareConfigWithURL (.../config.js:42:34)
    at new ClickHouseClient (.../client.js:59:65)
    at createClient (.../@clickhouse+client@1.12.1/.../client.js:15:12)
    at new ClickhouseClient (.../webapp/build/index.js:49830:243)
    at new ClickHouse (.../webapp/build/index.js:63805:21)
    at initializeRunsReplicationInstance (.../webapp/build/index.js:190055:20)

To reproduce

1. Self-host v4.4.5 with HTTP ClickHouse (no TLS), CLICKHOUSE_URL=http://...@clickhouse:8123, healthy.
2. Bump TRIGGER_IMAGE_TAG to v4.4.6, docker compose pull && up -d.
3. Observe webapp in restart loop, goose error in logs (Issue 1).
4. Append ?secure=false to CLICKHOUSE_URL and RUN_REPLICATION_CLICKHOUSE_URL — goose now passes, but webapp now crashes on Runs Replication init (Issue 2).

Workaround (currently running in production)

Asymmetric values:

CLICKHOUSE_URL=http://default:***@clickhouse:8123?secure=false
RUN_REPLICATION_CLICKHOUSE_URL=http://default:***@clickhouse:8123

• CLICKHOUSE_URL ends with ?secure=false so entrypoint.sh's grep -q secure= matches and skips appending ?secure=true. goose accepts secure=false + http:// (no conflict). Webapp's own CLICKHOUSE_URL consumption already strips secure via fix(webapp): strip secure param from query ClickHouse URL #3204, so the param is harmless there.
• RUN_REPLICATION_CLICKHOUSE_URL stays clean — it goes to @clickhouse/client without stripping.

This works but is fragile and undiscoverable.

Suggested fix

Two independent things to address:

1. docker/scripts/entrypoint.sh — only append ?secure=true when the URL scheme is https://. Or, simpler: strip the param entirely before calling goose and translate it to the scheme (https:// → secure=true, http:// → no flag). Conflating TLS choice with a query param when the scheme already encodes it is the root issue.

2. initializeRunsReplicationInstance — apply the same secure strip that QUERY_CLICKHOUSE_URL got in fix(webapp): strip secure param from query ClickHouse URL #3204 to RUN_REPLICATION_CLICKHOUSE_URL (and any other URL passed to @clickhouse/client). Centralizing this in a helper used by all client constructors would prevent regressions.

Reproduction repo

?

To reproduce

Provide environment information

• Trigger.dev version: v4.4.6 (self-hosted Docker, ghcr.io/triggerdotdev/trigger.dev:v4.4.6)
• Setup: standard hosting/docker compose, multi-file (webapp/docker-compose.yml + worker/docker-compose.yml)
• ClickHouse: bitnamilegacy/clickhouse:latest, HTTP only (no TLS), port 8123, local container
• Host: Linux amd64
• Previous working version: v4.4.5 (same .env, started healthy)

Describe the bug

After updating the image tag from v4.4.5 to v4.4.6 and running docker compose pull && up -d, the webapp container enters a restart loop. Two separate ClickHouse-URL handling issues block startup, related to but not fully covered by #3184 / #3204.

Issue 1 — entrypoint.sh appends ?secure=true unconditionally, goose now rejects it

docker/scripts/entrypoint.sh constructs GOOSE_DBSTRING from CLICKHOUSE_URL and adds ?secure=true if secure= isn't already in the URL — regardless of scheme. When the URL uses http:// (no TLS), the goose ClickHouse driver in v4.4.6 fails DSN parsing:

+ export GOOSE_DBSTRING=http://default:***@clickhouse:8123?secure=true
+ /usr/local/bin/goose up
2026/05/20 10:13:56 goose run: clickhouse [dsn parse]: http with TLS specify; clickhouse [dsn parse]: http with TLS specify

This appears to be a behavior change in the goose ClickHouse driver between v4.4.5 and v4.4.6 — the same DSN was tolerated by the older driver. entrypoint.sh exits non-zero, container restarts forever.

Issue 2 — RUN_REPLICATION_CLICKHOUSE_URL is NOT stripped before being passed to @clickhouse/client

#3204 added stripping of the secure query param for QUERY_CLICKHOUSE_URL, but RUN_REPLICATION_CLICKHOUSE_URL follows the same path through @clickhouse/client@1.12.1 and doesn't get the same treatment. Workarounding Issue 1 by adding ?secure=false to RUN_REPLICATION_CLICKHOUSE_URL (because the main CLICKHOUSE_URL workaround value is reused as the replication URL in some setups) triggers:

🗃️ Runs replication service enabled
{"url":"http://default:redacted@clickhouse:8123/?secure=false", ...}
Error: Unknown URL parameters: secure
    at loadConfigOptionsFromURL (.../config.js:267:19)
    at prepareConfigWithURL (.../config.js:42:34)
    at new ClickHouseClient (.../client.js:59:65)
    at createClient (.../@clickhouse+client@1.12.1/.../client.js:15:12)
    at new ClickhouseClient (.../webapp/build/index.js:49830:243)
    at new ClickHouse (.../webapp/build/index.js:63805:21)
    at initializeRunsReplicationInstance (.../webapp/build/index.js:190055:20)

To reproduce

1. Self-host v4.4.5 with HTTP ClickHouse (no TLS), CLICKHOUSE_URL=http://...@clickhouse:8123, healthy.
2. Bump TRIGGER_IMAGE_TAG to v4.4.6, docker compose pull && up -d.
3. Observe webapp in restart loop, goose error in logs (Issue 1).
4. Append ?secure=false to CLICKHOUSE_URL and RUN_REPLICATION_CLICKHOUSE_URL — goose now passes, but webapp now crashes on Runs Replication init (Issue 2).

Workaround (currently running in production)

Asymmetric values:

CLICKHOUSE_URL=http://default:***@clickhouse:8123?secure=false
RUN_REPLICATION_CLICKHOUSE_URL=http://default:***@clickhouse:8123

• CLICKHOUSE_URL ends with ?secure=false so entrypoint.sh's grep -q secure= matches and skips appending ?secure=true. goose accepts secure=false + http:// (no conflict). Webapp's own CLICKHOUSE_URL consumption already strips secure via fix(webapp): strip secure param from query ClickHouse URL #3204, so the param is harmless there.
• RUN_REPLICATION_CLICKHOUSE_URL stays clean — it goes to @clickhouse/client without stripping.

This works but is fragile and undiscoverable.

Suggested fix

Two independent things to address:

1. docker/scripts/entrypoint.sh — only append ?secure=true when the URL scheme is https://. Or, simpler: strip the param entirely before calling goose and translate it to the scheme (https:// → secure=true, http:// → no flag). Conflating TLS choice with a query param when the scheme already encodes it is the root issue.

2. initializeRunsReplicationInstance — apply the same secure strip that QUERY_CLICKHOUSE_URL got in fix(webapp): strip secure param from query ClickHouse URL #3204 to RUN_REPLICATION_CLICKHOUSE_URL (and any other URL passed to @clickhouse/client). Centralizing this in a helper used by all client constructors would prevent regressions.

Additional information

No response