Announcing Git deployment triggers for Appwrite Functions and Sites_
Git deployment triggers let you control which branches and file changes create automatic deployments for Appwrite Functions and Sites.
Git-based deployments make it easy to connect a repository and let Appwrite build from your pushes. That works well for small projects, but many teams quickly move into workflows with staging branches, preview branches, shared packages, and monorepos where a single repository powers several Functions and Sites.
In those setups, not every Git change should create every deployment. A docs-only change should not rebuild a production Site. A backend package change may need to rebuild an API Function, but not a marketing page. A team might want previews from the preview/** branch pattern, while keeping release deploys limited to main.
Today, we are announcing Git deployment triggers for Appwrite Functions and Sites.
Git deployment triggers let you control which branches and file changes create automatic deployments.
What Git deployment triggers give you
- Control over automatic deployments: Choose the branch pushes and file changes that should start a build.
- Cleaner preview workflows: Create deployments from the branches your team uses for previews, staging, testing, or release candidates.
- Better monorepo support: Deploy a Function or Site only when files in the relevant folders change.
- Simple glob patterns: Use familiar patterns like
main,preview/**,apps/web/**, and!docs/**. See the build trigger docs for supported glob pattern formats. - Support for Functions and Sites: Configure the same behavior across both Appwrite compute products.
Branch filters
Branch filters match branch names. Add patterns to limit automatic deployments to specific branches.
| Pattern | Matches | Example use |
|---|---|---|
main | The main branch | Deploy from your production branch |
staging | The staging branch | Deploy from a staging branch |
preview/** | Branches nested under preview/ | Deploy from branches like preview/new-checkout |
Branch filters work alongside your production branch setting. The production branch still controls which deployment becomes active for the Function or Site. Matching non-production branches can still create deployments for preview and testing workflows.
Path filters
Path filters match files changed in a commit or pull request. Leave this field empty to create deployments for all file changes, or add patterns to deploy only when specific files change.
| Pattern | Matches | Example use |
|---|---|---|
apps/web/** | Files nested under apps/web/ | Deploy a Site when its app files change |
packages/ui/** | Files nested under packages/ui/ | Deploy when shared UI components change |
!docs/** | Excludes files nested under docs/ | Skip docs-only changes |
Path filters are especially useful in monorepos. If one repository contains a web app, background Functions, shared packages, and docs, each Appwrite resource can listen only to the files it actually needs.
How to configure build triggers
In the Appwrite Console, open the Function or Site you want to configure, then go to its Git settings and update Build triggers.
- Sites: Go to Sites > your site > Settings > Git repository.
- Functions: Go to Functions > your function > Settings > Configuration > Git settings.
You can also configure the same behavior through the API and Server SDKs using providerBranches for branch filters and providerPaths for path filters.
Get started with Git deployment triggers
Git deployment triggers help keep automatic deployments aligned with how your team ships. They reduce unnecessary builds, make monorepos easier to manage, and give each Function or Site a clearer connection to the branches and files that matter.
