…external origin
The webapp publishes `API_ORIGIN` to runner pods as `TRIGGER_API_URL`, so
runner-to-webapp traffic flows back through whatever URL is configured for
external clients. Self-hosting behind a tracing-enabled gateway (Envoy,
Istio, kgateway, ...) breaks the parent->child run link in trigger.dev's
run-detail tree because the gateway's W3C `traceparent` rewrite on egress
overwrites the SDK's `triggerAndWait()` span id. The webapp then writes
that gateway-generated span id as the child run's `parentSpanId`, which
never reaches the trigger event store, so the child renders as an orphan
in the UI.
Operators can split the two concerns without sacrificing external auth/
callbacks/UI flows that rely on the public `API_ORIGIN`:
- Set `RUNTIME_API_ORIGIN=http://<service>.<namespace>:<port>` (k8s) or
`http://webapp:3000` (docker) to keep runner->webapp traffic on a
cluster-internal hop that bypasses the gateway.
- Leave `API_ORIGIN` on the public URL so the dashboard, magic-link
emails, waitpoint callbacks, and API `apiUrl` responses keep working
for external clients.
Scope is intentionally limited to MANAGED (deployed) runs. Dev CLI runs
keep the original `API_ORIGIN`/`APP_ORIGIN` chain so a developer running
`trigger.dev dev` from outside the cluster does not lose connectivity.
`STREAM_ORIGIN` is still honored as a dedicated stream endpoint when set;
`RUNTIME_API_ORIGIN` takes precedence over it for `TRIGGER_STREAM_URL`
so the bypass keeps streams on the same internal hop by default.
The new env is optional and falls back to `API_ORIGIN`/`APP_ORIGIN`, so
existing deployments are unaffected. An empty string is normalized to
`undefined` in the zod schema so blank `${RUNTIME_API_ORIGIN:-}`
passthroughs from caller environments do not short-circuit the fallback
chain. Helm chart and Docker Compose are wired to forward the value to
the webapp container.
Refs: triggerdotdev#2821