I’m trying to configure my Vercel project so that:
Preview deploys start automatically (on any feature branch commit).
Develop and main deploys are triggered only by my GitHub Actions workflow — not automatically by Vercel.
I know that it’s possible to disable automatic builds for specific branches via Ignored Build Step, e.g.:
[ "$VERCEL_ENV" != "preview" ] && exit 1
or using the “Only build pre-production” option.
However, when I do this, deploys triggered by my GitHub Actions (via deploy hooks) are also skipped/canceled, because of the rule set in Ignored build step.
Current workflow (if “Automatic” is used in Ignored Build Step):
I make code changes → commit → automatic preview deploy starts ( expected).
I merge to develop → automatic develop deploy starts ( unwanted).
GitHub Actions also runs → triggers Vercel deploy ( desired).
Result: I get two deploys for develop — one automatic from Vercel, one from GA via webhook.
Question
How can I:
Disable automatic deploys for develop and main,
But still allow deploys triggered via Vercel Deploy Hook (from GitHub Actions)?
Is there a way for Vercel to recognize deploys triggered by webhook separately from automatic Git commits, or do I need some manual workaround?
Deploy hooks are tied in to Vercel’s git integration. An alternative is to use GitHub Actions to build the project and then use the Vercel CLI to deploy the build artifacts independent of any branch. You lose the connection between the deployment and a commit, though. The example in How can I use GitHub Actions with Vercel? covers how to do that.
That said, this sounds a little like the x/y problem. Stepping back from the solution, what is your goal? Typically, you would have your main build (and develop build) always represent the latest commit, it is atypical to have them diverge. Are you trying to use GitHub’s deployment protection to be able to have a final manual approval for pushing a production build live?
If so, a Vercel “deploy” is actually made up of 2 separate processes: “build” and “promote”. A build can happen (on any branch) and then remain “staged” to be “promoted” later. So, you can tell Vercel to build main (or develop) but have no traffic routed to it. For that workflow, you do not need to change how main is built (turn off “Ignored Build Step”) and instead turn off auto assignment of the production domain via project settings > Environments > “Auto-assign Custom Production Domains”. After turning off auto assignment of the production domain, you’re then in manual control of which deployment is the production deployment. You can then use a GitHub Workflow to promote a build whenever you’re ready (with the vercel promote command).
The full workflow would be:
You merge into main (Production) or develop (a custom Environment) [1]
Vercel’s git integration (no need for a deploy hook) automatically builds for the branch but doesn’t “Auto-assign Custom Production Domains” when the build is done
The build sits in the project, waiting for manual intervention, it doesn’t receive any traffic
You “promote” the build to the environment’s domain via your GitHub Workflow (causing Vercel to route the environment’s traffic to the build)
[1] develop in this example is a custom Environment, not the default development Environment. Custom Environments is a Pro feature.
Thank you for the URLs you provided. and such thorough explanation. Turns out, using GitHub Actions with Vercel CLI is exactly the alternative I needed.
I also realized that the way I asked the question might have led you to think I needed staging workflow. My initial goal was to disable auto builds, and have only GitHub action do the build, which is exactly what I achieved with the alternative you proposed.
The reason I needed GA is to be able to run rollup-critical-plugin. I found the information in this topic:
My workflow now is:
Keep Vercel build for pre-preview
Have GA run the deploy for production (because I only need critical-css in production).
That’s about it, now I can spend time optimizing.
Thank again, and I’ll keep the deploy info you mentioned for future purposes.