Docs
Git & preview deployments
Provider apps, auto-deploy webhooks, and fork-gated PR previews.
Providers
- GitHub App manifest flow
- GitLab, Bitbucket, Gitea with access tokens
- Webhook secrets derived per provider (reveal in Settings when needed)
Auto-deploy
Push webhooks redeploy matching apps, with the signature verified and watch-path filters applied so unrelated files do not trigger a rebuild. A generic org-scoped deploy hook accepts CI with an API key, under the same key scope and 2FA gate as the REST API.
Preview deployments
- PR open / sync creates or redeploys a preview with its own domain
- PR close tears the preview down
- Comments on GitHub / GitLab / Gitea carry the preview URL and are edited in place on later pushes, instead of stacking
- Fork PRs require approval by default — collaborators on the base repo bypass the gate, and an unreachable membership check fails safe toward requiring approval
- Preview-only environment variables, merged over the service layer, so a PR can point at a scratch database
- A per-application cap on simultaneous previews — over the cap the pull request gets a comment instead of a silently evicted preview
- A default lifetime in hours for previews a pull request creates; expired previews are pruned hourly
- Previews carry the PR's commit metadata in their deployment history like any other build
A preview runs the parent's image and merged env, but none of its published ports, volumes or file mounts, as a single replica. Deploy hooks never run for a preview. Compose services have no previews.
Also see the repository guides under docs/ · REST API reference