Controlling Netlify Deploy Triggers Without Breaking Your Branch Workflow

Every Branch Push Triggers a Build—And That Is Not Always What You Want

Connect a repository to Netlify and the default behavior is often to build every push. For a team working with feature branches, this means CI noise, wasted build minutes, and confusion about which URL is actually production. The useful takeaway: Netlify lets you separate production deploys from preview builds through branch rules and a netlify.toml configuration file, and getting that separation right is usually the first real engineering decision after the initial Git connection.

What the Git Integration Actually Controls

Netlify's continuous deployment works by installing a webhook in your Git provider. When you push to a branch that Netlify watches, the provider notifies Netlify, and Netlify starts a build. The trigger is not magic; it is a combination of the repository link you create in the Netlify UI and the branch patterns you configure.

Two concepts matter here. A production deploy is the build that serves your primary domain. A deploy preview is a temporary build generated for a pull request or non-production branch. Both use the same build pipeline, but they can run different commands and environment variables.

Pinning the Build with netlify.toml

Rather than relying solely on UI settings, you can commit a netlify.toml file to the root of your repository. This makes the build configuration versioned and reviewable. The file tells Netlify which command to run, which directory to publish, and how to handle different contexts.

Here is a minimal example for a static site generated by a common build tool:

[build]
  command = "npm run build"
  publish = "dist"

[context.production]
  command = "npm run build:prod"
  environment = { NODE_VERSION = "20" }

[context.deploy-preview]
  command = "npm run build:preview"
  environment = { NODE_VERSION = "20" }

Run this by committing the file to your repository root and pushing. No special permissions are required beyond write access to the repo. The expected check is that your next deploy log in the Netlify dashboard shows the context-specific command executing. The risk is that a typo in the TOML file will fail the build before it starts, so validate the syntax locally if your build tool supports it.

The Trade-off: Preview Fidelity vs. Build Budget

Deploy previews are valuable because reviewers see the actual rendered site, not a local screenshot. However, every preview consumes build minutes and, if your site uses Netlify Functions, invokes serverless resources. A pragmatic middle ground is to enable previews only for pull requests targeting your production branch, and to skip previews for routine feature-branch pushes.

You can enforce this in the Netlify UI under Site Settings > Build & Deploy > Continuous Deployment. There is no universal "correct" setting; a documentation site might preview every PR, while an application with expensive end-to-end tests might restrict previews to release candidates.

Limits That Bite During Builds

Netlify Functions run in a managed runtime with defined execution time and memory ceilings. If your build process shells out to a function to prerender pages or fetch data, a slow or memory-hungry function can fail the entire deploy. The static assets might be fine, but because Netlify treats the deploy as a unit, the site does not go live until the build succeeds.

There is also a dependency on your Git provider's webhook delivery. Because the trigger depends on the connected repository settings, an outage or rate-limit on the provider side means no build starts. The dashboard will simply show no new activity.

How to Verify the Configuration

After changing branch settings or committing a new netlify.toml, push a commit to a non-production branch and confirm a deploy preview appears in the pull request. Then push to your production branch and check the dashboard build logs for the production context. If the log shows the wrong command or environment, the netlify.toml context blocks are the first place to look.