fix(docker): stop injecting secure=true into CLICKHOUSE_URL

[mangit955]

Closes #3184

✅ Checklist

• I have followed every step in the contributing guide
• The PR title follows the convention
• I ran and tested the code works

---

Testing

Steps taken to test the change:

1. Ran the Trigger.dev Docker setup locally.
2. Confirmed the server previously failed with:
   Error: Unknown URL parameters: secure
3. Removed the logic that automatically injects secure=true into the ClickHouse connection string.
4. Restarted the containers and verified that:
   • ClickHouse migrations run successfully
   • The server starts normally
   • No Unknown URL parameters: secure error occurs.

---

Changelog

Fix Docker entrypoint script to stop automatically injecting secure=true into CLICKHOUSE_URL.
Some ClickHouse clients (including the Node client used by Trigger.dev) do not support this parameter, which causes startup failures.

The script now uses the provided CLICKHOUSE_URL directly.

---

Screenshots

N/A (backend / Docker configuration change)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0a86416

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Hi @mangit955, thanks for your interest in contributing!

This project requires that pull request authors are vouched, and you are not in the list of vouched users.

This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ae6da0a9-d5c0-4907-a1f7-87e0a5e54843

📥 Commits

Reviewing files that changed from the base of the PR and between e64b101 and 0a86416.

📒 Files selected for processing (1)

• docker/scripts/entrypoint.sh

---

Walkthrough

The change removes conditional logic from a shell script that previously ensured the secure=true parameter was present in the ClickHouse connection string. The script now directly exports the GOOSE_DBSTRING environment variable using the provided CLICKHOUSE_URL without any URL modification or parameter appending. This eliminates 11 lines of conditional logic while adding 2 lines of direct assignment.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[devin-ai-integration]

Devin Review found 1 potential issue.

View 1 additional finding in Devin Review.

[devin-ai-integration]

🚩 Breaking change for self-hosting users who relied on implicit secure=true

The old code automatically appended secure=true to CLICKHOUSE_URL if no secure= parameter was present. Self-hosting users who previously omitted the secure parameter from their CLICKHOUSE_URL (relying on the entrypoint to inject it) will now have their goose migrations connect without TLS. This could cause migration failures if their ClickHouse instance requires secure connections. The hosting/docker/.env.example:65 already includes ?secure=false explicitly, and hosting/docker/webapp/docker-compose.yml:71 defaults to ?secure=false, suggesting the self-hosting defaults are fine. However, users with production ClickHouse behind TLS who relied on the auto-injection will need to update their CLICKHOUSE_URL to include secure=true.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[mangit955]

Hi!
I attempted to submit a fix for this issue in PR #3190, but it was automatically closed because I'm not yet a vouched contributor.

Would it be possible for a maintainer to vouch for me so I can reopen the PR?

I verified the issue locally with the Docker setup and confirmed that removing the automatic secure=true injection resolves the Unknown URL parameters: secure error.

[samennis1]

From a community member, thank you for this PR! I was able to replicate and confirm it fixes the issue. Definitely need to get this merged.

[mangit955]

From a community member, thank you for this PR! I was able to replicate and confirm it fixes the issue. Definitely need to get this merged.

Thanks for confirming the fix!

Since the PR was auto-closed due to the vouch requirement, would a maintainer be able to vouch for me so I can reopen the PR?

I'm happy to make any changes needed or update the implementation if required.