Automation, notifications, and previews

Automatic deployment is a per-project decision. For a Git source, choose it on Review while creating the project, then manage it under Settings → General → Automatic deployment. The project's Settings → Automation page holds webhooks, schedules, preview environments, and traffic alerts. Notification channels shared by projects live under Deployments → Notifications.

Automatic Git deploymentCopy Anchor Link

After the first successful deployment, a remote production branch is checked for new commits and each matching commit deploys. Turn off Deploy automatically before the first release or later to make deployments manual; the project header then reads Manual deployments. Manual mode stops new automatic branch, hook, API-triggered, and scheduled deploy requests; runs already accepted continue unless you cancel them separately. A manual deploy or retry remains possible.

Include paths and Exclude paths limit which changed repository files trigger a release. Enter repository-relative glob patterns, one per line; directory/** covers a directory and everything in it. An empty include list accepts all paths, and an exclude wins over an include. A changed path that was ignored is still part of the later comparison baseline, so a subsequent relevant change is not hidden by an earlier excluded commit. When the remote history or a complete comparison cannot be read, filtered automation pauses and reports why rather than guessing that nothing changed.

The GitHub App can provide private repository clone access and deliver push and pull request events through one signed webhook. The creation screen shows the connected App and CLI identities separately, so choose the one that actually has access to the repository. If you do not connect the App, saved credentials and other supported hooks can still serve their individual uses. See project creation.

Channels and release messagesCopy Anchor Link

Open Deployments → Notifications to add a Discord, Slack, Telegram, E-mail, or Signed webhook channel. Choose which run events each channel receives: Started, Succeeded, Failed, and Cancelled. A channel's menu offers Send test, Pause channel, and Delivery history, and the page lists recent messages. A failed run can notify you even when it never reached a final release step. The same channels also carry traffic alerts, database alerts, and proxy certificate alerts.

Report each release as a GitHub commit status can be turned on for a GitHub project in Settings → General → Automatic deployment. Statuses are best effort and do not change the deployment outcome if GitHub cannot be reached.

Under Settings → Automation, schedules show their next runs and webhooks show recent deliveries. A schedule can deploy, restart, run a backup job, or run a command in a container. The project's Logs page and Settings → Automation can create traffic alerts: Failing requests (the 5xx share), Slow responses (p95 latency), or No traffic for a route that was busy and falls silent. An alert sends on the transition into and out of its firing state rather than once every evaluation minute. It needs at least one enabled notification channel to reach someone.

Test a pull requestCopy Anchor Link

For a GitHub project, an administrator can build a pull request's exact head as a preview. Choose Test a pull request… from the project's menu, or Test this pull request on a row under Pull requests on the project's Overview. The dialog names the head commit and the branches, then Build preview builds it.

• The preview is reachable only on your tailnet, at a port on this server's Tailscale address. It needs a usable Tailscale connection.
• Copy production variables into this preview copies production's current values, secrets included, so the preview can reach anything those secrets can. It is on by default for a branch in the same repository and refused for a fork. Database and other resource references are never copied.
• A head from a fork shows a warning, and Build preview stays disabled until you tick I have reviewed this fork's changes.
• Release tasks configured for production are skipped.

Open preview opens it, Update preview builds a newer head, and Close preview removes its containers, storage, and tailnet address. Merge merges the pull request on GitHub; production then redeploys if automatic deployment is on.

Preview environments from webhooksCopy Anchor Link

A webhook with Create isolated environments for pull requests turned on can request a preview for each pull request, but an administrator must approve the exact full Git revision before any preview build or runtime is created. A new commit makes an older request stale; approve the new revision separately. The approval view warns when the head comes from a fork and opens the preview's own variables before deployment. Approval and deployment are separate actions: Approve and configure sets the preview up, Deploy preview builds and starts it, and Reject refuses a revision for good.

Webhook previews start without production variables, linked databases, or release tasks. In every preview, mounts become separate managed volumes, and a database must be configured separately. Previews use a dedicated Docker bridge, but an approved Dockerfile is still code you chose to run; review the source before approval. Compose previews, host networking, privileged containers, fixed host ports, production mounts, and release tasks are refused for previews. Closing a pull request removes its preview resources and disposable preview storage after cleanup succeeds; if cleanup fails, Retry cleanup runs it again.

If a preview created by an older release is quarantined during upgrade, the project explains the incomplete isolation. After cleanup, redeliver the event and approve the current revision. Rotate any credentials that a former preview shared with production.

When a push did not deployCopy Anchor Link

Check the automatic-deployment state in the project header or on Settings → General. Common reasons are manual deployments, no relevant watched path, a branch the dashboard cannot read, a stale webhook delivery, a stopped live runtime, or a preview still waiting for approval. The run history and the policy's latest decision show which occurred.