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.