Summary

On self-hosted Trigger.dev v4.4.3, native deployments can get stuck on PENDING and later time out because the build is never actually enqueued.

Environment

• Trigger.dev self-hosted
• Version: v4.4.3
• API origin: custom self-hosted origin, not cloud.trigger.dev
• Native build / self-hosted deployment flow

Expected behavior

Creating a native deployment should move it from PENDING to INSTALLING / BUILDING automatically.

Actual behavior

The deployment row is created, but the build is never enqueued. The deployment stays on PENDING and later times out.

Reproduction

1. Run self-hosted Trigger.dev v4.4.3
2. Create a native deployment
3. Artifact upload succeeds
4. Deployment remains PENDING
5. Eventually deployment becomes TIMED_OUT

What we found

In the webapp bundle, the path that should enqueue the build depends on a client initialized by initializeClient().

That client is only initialized when isCloud() is true and billing env vars are present.

In self-hosted with a custom origin, isCloud() is false, so the client is never initialized.

Then enqueueBuild() effectively becomes a no-op because it immediately returns when client is missing.

Evidence

Relevant bundle logic in our running container:

• initializeClient() only initializes when isCloud() and billing env vars are set
• enqueueBuild() returns early when client is falsy
• deployment creation path still calls deploymentService.enqueueBuild(...)

Observed DB state for affected deployments:

• status: PENDING
• no startedAt
• no builtAt
• no deployedAt
• no worker attached

Impact

Self-hosted native deploys are not reliable without patching the bundle or bypassing this code path.

Question

Is this an intended limitation of self-hosted native builds in v4.4.3, or is this a bug in the self-hosted code path?