Dify
-
Hi @timconsidine Thank you very much for packaging and maintaining Dify. It's a fascinating software
During the usage, we have found a limitation to Dify. And here we have included the fix. When possible, please check it. It should be useful to all that are using Dify.
Details >>>
We hit a wall with the new Integration Trigger feature (workflow triggers from external systems, e.g. the Gmail Trigger plugin from the marketplace). Dify generates each subscription's callback URL from the TRIGGER_URL environment variable, which defaults to http://localhost:5001.
So the UI shows and registers:
http://localhost:5001/triggers/plugin/<id>instead of the app's public domain, and Dify itself warns: "This URL appears to be an internal address, which may cause webhook requests to fail. You may change TRIGGER_URL to a public address."
Upstream context (for reference):
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
https://docs.dify.ai/en/self-host/use-dify/nodes/trigger/plugin-trigger - Same symptom seen by self-hosters elsewhere, closed as config-not-passed:
https://github.com/langgenius/dify/issues/28534
The difficulty on Cloudron: start.sh regenerates /app/data/api-env from a heredoc on every boot, /app/code is read-only, and there is no custom env hook (like /app/data/env in some other packages), so there is currently no way for us to inject TRIGGER_URL persistently. Editing api-env or adding /app/data/env.sh does not survive a restart.
Suggested fix (two lines in the api-env heredoc in start.sh) :
TRIGGER_URL=${CLOUDRON_APP_ORIGIN}
ENDPOINT_URL_TEMPLATE=${CLOUDRON_APP_ORIGIN}/e/{hook_id}Rationale:
- TRIGGER_URL: base URL for /triggers/plugin/<id> callbacks. The package nginx already routes /triggers publicly to the API, so only the generated URL string is wrong.
- ENDPOINT_URL_TEMPLATE: same class of problem — defaults to http://localhost:5002/e/{hook_id}. Nginx already routes /e/ to the plugin daemon, so deriving it from CLOUDRON_APP_ORIGIN fixes plugin custom endpoints too.
- Using CLOUDRON_APP_ORIGIN keeps it fully automatic: correct on any domain, no per-install configuration, survives domain changes.
One note from the docs worth mentioning in the changelog: existing subscriptions keep the URL they were created with, so users must recreate trigger subscriptions after upgrading.
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
-
J james marked this topic as a regular topic
-
Hi @timconsidine Thank you very much for packaging and maintaining Dify. It's a fascinating software
During the usage, we have found a limitation to Dify. And here we have included the fix. When possible, please check it. It should be useful to all that are using Dify.
Details >>>
We hit a wall with the new Integration Trigger feature (workflow triggers from external systems, e.g. the Gmail Trigger plugin from the marketplace). Dify generates each subscription's callback URL from the TRIGGER_URL environment variable, which defaults to http://localhost:5001.
So the UI shows and registers:
http://localhost:5001/triggers/plugin/<id>instead of the app's public domain, and Dify itself warns: "This URL appears to be an internal address, which may cause webhook requests to fail. You may change TRIGGER_URL to a public address."
Upstream context (for reference):
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
https://docs.dify.ai/en/self-host/use-dify/nodes/trigger/plugin-trigger - Same symptom seen by self-hosters elsewhere, closed as config-not-passed:
https://github.com/langgenius/dify/issues/28534
The difficulty on Cloudron: start.sh regenerates /app/data/api-env from a heredoc on every boot, /app/code is read-only, and there is no custom env hook (like /app/data/env in some other packages), so there is currently no way for us to inject TRIGGER_URL persistently. Editing api-env or adding /app/data/env.sh does not survive a restart.
Suggested fix (two lines in the api-env heredoc in start.sh) :
TRIGGER_URL=${CLOUDRON_APP_ORIGIN}
ENDPOINT_URL_TEMPLATE=${CLOUDRON_APP_ORIGIN}/e/{hook_id}Rationale:
- TRIGGER_URL: base URL for /triggers/plugin/<id> callbacks. The package nginx already routes /triggers publicly to the API, so only the generated URL string is wrong.
- ENDPOINT_URL_TEMPLATE: same class of problem — defaults to http://localhost:5002/e/{hook_id}. Nginx already routes /e/ to the plugin daemon, so deriving it from CLOUDRON_APP_ORIGIN fixes plugin custom endpoints too.
- Using CLOUDRON_APP_ORIGIN keeps it fully automatic: correct on any domain, no per-install configuration, survives domain changes.
One note from the docs worth mentioning in the changelog: existing subscriptions keep the URL they were created with, so users must recreate trigger subscriptions after upgrading.
@creative567145 great work on the diagnosis and fix building.
Looks good from a skim read, will read it more critically as soon as I get a chance, and fix package.
If you haven't already done so, you could clone the publicly available Dify repo from https://forgejo.tcjc.uk/cca/cloudron-dify.git and implement the change.
Might get you going faster, but maybe you have already done it.Happy to put in the change also.
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
-
Hi @timconsidine Thank you very much for packaging and maintaining Dify. It's a fascinating software
During the usage, we have found a limitation to Dify. And here we have included the fix. When possible, please check it. It should be useful to all that are using Dify.
Details >>>
We hit a wall with the new Integration Trigger feature (workflow triggers from external systems, e.g. the Gmail Trigger plugin from the marketplace). Dify generates each subscription's callback URL from the TRIGGER_URL environment variable, which defaults to http://localhost:5001.
So the UI shows and registers:
http://localhost:5001/triggers/plugin/<id>instead of the app's public domain, and Dify itself warns: "This URL appears to be an internal address, which may cause webhook requests to fail. You may change TRIGGER_URL to a public address."
Upstream context (for reference):
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
https://docs.dify.ai/en/self-host/use-dify/nodes/trigger/plugin-trigger - Same symptom seen by self-hosters elsewhere, closed as config-not-passed:
https://github.com/langgenius/dify/issues/28534
The difficulty on Cloudron: start.sh regenerates /app/data/api-env from a heredoc on every boot, /app/code is read-only, and there is no custom env hook (like /app/data/env in some other packages), so there is currently no way for us to inject TRIGGER_URL persistently. Editing api-env or adding /app/data/env.sh does not survive a restart.
Suggested fix (two lines in the api-env heredoc in start.sh) :
TRIGGER_URL=${CLOUDRON_APP_ORIGIN}
ENDPOINT_URL_TEMPLATE=${CLOUDRON_APP_ORIGIN}/e/{hook_id}Rationale:
- TRIGGER_URL: base URL for /triggers/plugin/<id> callbacks. The package nginx already routes /triggers publicly to the API, so only the generated URL string is wrong.
- ENDPOINT_URL_TEMPLATE: same class of problem — defaults to http://localhost:5002/e/{hook_id}. Nginx already routes /e/ to the plugin daemon, so deriving it from CLOUDRON_APP_ORIGIN fixes plugin custom endpoints too.
- Using CLOUDRON_APP_ORIGIN keeps it fully automatic: correct on any domain, no per-install configuration, survives domain changes.
One note from the docs worth mentioning in the changelog: existing subscriptions keep the URL they were created with, so users must recreate trigger subscriptions after upgrading.
@creative567145 I have checked that, built and pushed a new update.
Thank you for taking the time to report ... and to solve it in the same breath !
NOTE : existing trigger subscriptions keep the URL they were created with, so users must recreate them after upgrading.
- Official docs require setting TRIGGER_URL to a public URL before creating subscriptions:
-
Thank you Tim @timconsidine very much
We have started running more and more of your apps, so anytime we find some bug, we will report it to you with the fix included - so that we can atleast contribute somehow. We understand that your job isn't easy -
Thank you Tim @timconsidine very much
We have started running more and more of your apps, so anytime we find some bug, we will report it to you with the fix included - so that we can atleast contribute somehow. We understand that your job isn't easy@creative567145 that's great, I hope the apps you try are useful.
Bug reports very welcome, solved or not !
Most apps I package are to scratch an itch, and I don't get to test all integrations, so input very welcome. Community !
-
@creative567145
Another Dify package update this morning
Check the CHANGELOG.md or 'Recent Changes' tab on ca.cloudron.io -
Thanks Tim @timconsidine we applied both updates and currently everything is ok
-
Thanks Tim @timconsidine we applied both updates and currently everything is ok
@creative567145 ... phew !
Thanks for letting me know.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login