Repository navigation
Hide native (Git-based) deployments in self-hosted instances #4835
Description
Native (Git-based) deployments depend on a build service that is only available on Trigger.dev Cloud. In a self-hosted instance the option is still visible, and a deployment created this way stays in the PENDING state forever (see #3256).
The dashboard and API should not offer native deployments when the instance is self-hosted. Self-hosted users deploy with the CLI or the GitHub Action.
Suggested change: gate the Git-based deployment UI and the enqueueBuild path on the same condition that enables the cloud build client, and return a clear error from the API when the feature is not available.
Activity
MauryaQbit commentedon Aug 30, 2026
@matt-aitken assign me
jankvacek-cell commentedon Sep 8, 2026
@matt-aitken, a concrete regression check for #4835 is a two-layer capability matrix: self-hosted/native-Git => UI unavailable AND direct API request rejected before enqueue; Cloud with build-client capability absent => same; Cloud with capability present => existing authorized build path still works. CLI and GitHub Action deployments should retain their current paths in both environments.
For each unsupported case, assert both “clear unsupported-feature result” and “enqueueBuild call count = 0”; an absent button alone misses callers using the API directly. Include a capability change between page load and submit: the server must re-check its current capability instead of trusting the previously rendered UI. Keep normal authentication/authorization checks in place; this is an additional capability gate.
Those cases are free to use and need no real build or paid API. I haven't run them against Trigger.dev; the first implementation step would be one shared capability predicate with UI and API contract tests. I understand a maintainer vouch is required before any PR. AI-assisted proposal, reviewed before sharing.