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:

1. You merge into main (Production) or develop (a custom Environment) [1]
2. 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
3. The build sits in the project, waiting for manual intervention, it doesn’t receive any traffic
4. 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.

https://vercel.com/docs/deployments/promoting-a-deployment

vercel.com

Promoting Deployments

Learn how to promote deployments to production on Vercel.

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:

https://community.vercel.com/t/libnss3-so-missing-in-node-22-x/2533

Vercel Community

Libnss3.so missing in Node 22.x

I am trying to use the npm package critical (npmjs.com/package/critical). It uses headless chromium through puppeteer. It used to work in node 14.x, but with...

My workflow now is:

1. Keep Vercel build for pre-preview
2. 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.