You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hide native (Git-based) deployments in self-hosted instances #4835
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.
@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.
Hi @matt-aitken — I've submitted a vouch request in Discussion #5010 and prepared a complete, GPG-signed fix in #5064 (branch khoap1220-hue:fix/hide-native-deployments-self-hosted-4835, including the follow-up items from Devin Review in commit 2165583):
Build Enqueue Guard (apps/webapp/app/services/platform.v3.server.ts): Throw new Error("Platform client not configured") in enqueueBuild when !client instead of returning undefined so native deployments cannot get stuck in PENDING.
API Validation (apps/webapp/app/v3/services/initializeDeployment.server.ts): Reject payload.isNativeBuild && !isBillingConfigured() with ServiceValidationError(..., 400) and added .server-changes/hide-native-deployments-self-hosted.md.
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.
fix(webapp): gate native Git-based deployments and enqueueBuild on cl…
fix(webapp): gate ProjectSettingsPresenter and deploy-now on isBillin…
khoap1220-hue commentedon Oct 25, 2026
Hi @matt-aitken — I've submitted a vouch request in Discussion #5010 and prepared a complete, GPG-signed fix in #5064 (branch
khoap1220-hue:fix/hide-native-deployments-self-hosted-4835, including the follow-up items from Devin Review in commit2165583):GitHubSettingsPresenter,ProjectSettingsPresenter,DeploymentListPresenter,resources...github.tsx,resources...deploy-now.ts): Gate GitHub App native deployment settings and redeploy actions onisBillingConfigured()alongsideenv.GITHUB_APP_ENABLED === "1".apps/webapp/app/services/platform.v3.server.ts): Thrownew Error("Platform client not configured")inenqueueBuildwhen!clientinstead of returningundefinedso native deployments cannot get stuck inPENDING.apps/webapp/app/v3/services/initializeDeployment.server.ts): Rejectpayload.isNativeBuild && !isBillingConfigured()withServiceValidationError(..., 400)and added.server-changes/hide-native-deployments-self-hosted.md.