Summary
A fresh Trigger.dev deployment on Coolify exposes service URLs that reference the application's internal listening port instead of the externally routed address. Any feature relying on those URLs breaks because clients attempt to connect directly to a port that is never exposed outside the container.
Impact
After deployment:
- The authentication flow redirects users to an address that cannot be reached.
- The Trigger.dev CLI is unable to initialize a development session.
- API responses contain incorrect origin values for external consumers.
Reproduction
- Deploy the Trigger.dev service using Coolify.
- Assign a public domain such as
trigger.example.com.
- Install the CLI and authenticate against the public domain.
- During authentication, observe that the browser is redirected to a URL containing
:3000.
- If the port is manually removed and authentication completes, starting a development session still fails because the server continues returning URLs with the same port.
Actual Result
The application consistently generates links similar to:
https://trigger.example.com:3000
Since port 3000 exists only inside the Docker network, those URLs are unusable from outside the host.
Example CLI output:
Failed to connect to https://trigger.example.com:3000.
Couldn't retrieve settings: Connection error.
Expected Result
Every externally visible URL should resolve to the reverse-proxied hostname without exposing the container's internal port.
Environment
- Coolify: v4.0.0-beta.452
- Deployment: Self-hosted
- OS: Ubuntu 22.04
Findings
The default service definition initializes the application's origin configuration using the variable that includes the container port. Consequently, the backend serializes those values into redirects and API responses.
Replacing the origin configuration with the portless service URL resolves the problem.
Another observation is that modifying the values through the Coolify Environment Variables page has no effect because the Compose template already defines them explicitly. Those definitions override the values managed through the UI, leaving direct edits to the Compose configuration as the only available workaround.
Summary
A fresh Trigger.dev deployment on Coolify exposes service URLs that reference the application's internal listening port instead of the externally routed address. Any feature relying on those URLs breaks because clients attempt to connect directly to a port that is never exposed outside the container.
Impact
After deployment:
Reproduction
trigger.example.com.:3000.Actual Result
The application consistently generates links similar to:
Since port
3000exists only inside the Docker network, those URLs are unusable from outside the host.Example CLI output:
Expected Result
Every externally visible URL should resolve to the reverse-proxied hostname without exposing the container's internal port.
Environment
Findings
The default service definition initializes the application's origin configuration using the variable that includes the container port. Consequently, the backend serializes those values into redirects and API responses.
Replacing the origin configuration with the portless service URL resolves the problem.
Another observation is that modifying the values through the Coolify Environment Variables page has no effect because the Compose template already defines them explicitly. Those definitions override the values managed through the UI, leaving direct edits to the Compose configuration as the only available workaround.