Does Vercel's auto preview build + deploys use the head PR commit or the speculative merge commit?

Discussions
1

I’m realizing from the following links:

On pull_request workflow triggers, actions/checkout uses the speculative mere commit of PR head → base branch head instead of the actual PR head itself. I kinda get why that was decided and in some ways, makes things easy and in some ways, hard.

But I wanted to understand how Vercel auto preview build + deploys behave. I was trying to move to a more GitHub Actions-centric workflow to do all builds + deploys (IDK why this is so difficult to do with Vercel) so was trying out manually building + deploying to Vercel from GitHub Actions using vercel CLI. I observed the following:

CleanShot_2025-12-30T02.15.28_Google Chrome-experiment-ci-driven-vercel-deploys – Deployment Overview@2x
CleanShot_2025-12-30T02.15.28_Google Chrome-experiment-ci-driven-vercel-deploys – Deployment Overview@2x1920×1204 285 KB

where right is after creating vercel project, where the initial commit was deployed to prod, where the links + commit info is all correct. But when I did vercel build + vercel deploy from GitHub workflow, I saw weird stuff which can now be explained because of pull_request behavior.

So, are Vercel auto deploys then always picking the head commit of a PR branch and is that why the branch/commit info is correct? If yes, does this mean that we cannot rely on pull_request events at all when working with Vercel GitHub integration since the results would be different for jobs running on Vercel vs GitHub Actions?

4

Vercel’s auto preview deployments use the actual PR head commit , not the speculative merge commit that GitHub Actions uses by default.

If you want your GitHub Actions workflow to match Vercel’s behavior, you can explicitly checkout the PR head commit in your workflow:

- uses: actions/checkout@v4
  with:
    ref: ${{ github.event.pull_request.head.sha }}

I’ve seen others suggest alternatives like pull_request_target event (but be careful with security implications) or push event on feature branches instead of pull_request

1 Like
5

I see. Is there an option to go for the GitHub behavior? I can understand though why that might be undesirable for preview envs.

6

Using GitHub Actions instead of Vercel’s automatic deployment workflow would give you more control over which commit gets deployed.

There’s a Vercel project git configuration option that will let you disable the automatic deployments so you can handle it GitHub Actions if that’s what you want to do.

1 Like
7

Yeap, we’re leaning strongly towards this now. I can imagine why Vercel’s current approach is unchanged but would be nice to have more GitHub Actions or External CI-first integrations (e.g. custom GH action) to do this.

1 Like