StagingReservationSign in →
Reference

Trigger patterns

Every slot has a trigger type (branch, tag, or deployment) and a trigger pattern. When something on GitHub matches that combination, the slot's currentRef and currentStatus update in place.

branch — track a Git branch

A slot of type branch follows pushes to a matching branch. The pattern is either an exact name or a glob.

| Pattern | Matches | |----------------|-----------------------------------------------| | main | exactly the main branch | | develop | exactly the develop branch | | staging-1 | exactly staging-1 — single reserved slot | | release/* | any branch under release/ (release/2025-12, ...) | | feature/* | any feature branch | | pr-* | pull-request branches that match | | * | any push to any branch — wildcard pool |

Glob characters supported: * (zero or more, no /). Patterns are case-sensitive. Slashes inside the branch name are literal.

When a push matches, the slot's:

  • currentRef becomes the branch name
  • currentSha becomes the commit SHA
  • currentStatus becomes Deploying (until your CI sends a deployment_status update)

tag — track a Git tag

A slot of type tag follows tag creation. The pattern is exact or globbed against tag names.

| Pattern | Matches | |----------|----------------------------------------| | v* | any semver-ish tag (v1.0.0, v2.1) | | prod-* | any prod release tag | | v1.* | the v1 minor line only | | latest | a specific named tag |

Most teams use tags for production releases — pair a tag: v* slot with a CD pipeline that deploys to prod when the tag pushes.

deployment — track a GitHub Deployment

A slot of type deployment doesn't follow Git refs at all. It listens for deployment_status webhook events from GitHub Actions (or any process that creates GitHub Deployments). The pattern is an exact match on the deployment's environment field — no globs.

| Pattern | Matches | |----------------|-----------------------------------------------| | staging | deployment events with environment=staging | | production | deployment events with environment=production| | prod-eu | a custom-named environment |

Use deployment when your CI already creates GitHub Deployments and you'd rather mirror their lifecycle than guess from branch pushes. The slot tracks each deployment's URL into currentUrl.

How patterns map to your workflow

The four workflow templates each pick a sensible combination:

  • Single staging — both slots use branch: main. Pushes to main light up Staging then Prod.
  • Multi-slot pool — Staging slots use exact branch names (staging-1, staging-2, staging-3); team reserves a slot by pushing to that branch.
  • Trunk + preview — Preview uses branch: pr-* (glob, catches every PR branch); Prod uses branch: main.
  • GitFlow — Staging uses branch: develop; Prod uses tag: v*.

You can mix freely — e.g. a Staging env with one slot tracking develop and another tracking hotfix/*.

Common gotchas

  • Globs don't match across slashes. release/* matches release/2025-12 but not release/2025/12-rc1. Use release/** if you need that — but ** is not yet supported; use a more specific exact-match instead.
  • Deployment patterns are exact only. No prod-* glob; pick a consistent environment string on your CI side.
  • Protected branches (main, develop) can be tracked by a slot, but the app's "Create branch" and "Delete branch" controls refuse to write to them.