Fix Vercel 'Git author must have access to the project'

TL;DR#

For a private repository owned by a GitHub organisation, GitLab group or non-personal Bitbucket workspace, Vercel only deploys a commit whose author it can match to someone allowed to deploy: the owner of a Hobby team, or a member of a Pro team. If the commit is yours, the usual cause is a local git config user.email that matches neither your Git provider account nor your Vercel account; fix the email and push a new commit. If the commit is a collaborator's on a Hobby project, the block is the plan itself: move the project to a Pro team and add them, or make the repository public.

The error#

Vercel reports the block on the Git provider, and the Stack Overflow question behind this page quotes it like this:

Error: Vercel - Git author must have access to the project on Vercel to create deployments

The asker's setup is the classic trigger: a private repository in the company's GitHub account, the asker added there as a collaborator, the project in the company's Vercel account. One branch deployed after the GitHub connection was re-authenticated, then the next push was blocked again.

Why Vercel checks the commit author#

Vercel's Git documentation describes it as a security measure under deploying private Git repositories: commits on a private repository "will only be deployed if the commit author also has access to the respective project on Vercel". The check runs on every commit, which is why one branch can deploy and the next one fail with nothing changed in the project settings. What counts as access depends on the plan of the team that owns the project:

The same page notes that the rule only covers commit authors on GitHub organisations, GitLab groups and non-personal Bitbucket workspaces, not collaborators on personal Git accounts.

To decide who authored a commit, Vercel looks up the Vercel user behind the commit author through its Login Connections. The collaboration troubleshooting page adds that when an account has no Git provider connected, the Vercel account email has to match the email on the commit. The commit's author email is whatever user.email was set to on the machine that made it, and Vercel's guide to commits that do not trigger deployments warns that a plus-address counts as a different identity: dev+work@example.com is not dev@example.com, even though both reach the same inbox.

Fix#

1. Read the author of the blocked commit#

Run this in the repository, on the branch that failed to deploy:

git log -1 --format="%an <%ae>"
git config --get user.email

The first line is the identity Vercel was shown; the second is the identity your next commit will carry. Compare both with the verified emails in your GitHub (or GitLab, Bitbucket) account settings and with the emails listed in your Vercel account settings. Then pick the case below.

2. Your own commit: fix the identity#

When the commit is yours but its email is not one Vercel can tie to you, correct the email, then make the commit Vercel looks at carry it. Changing user.email does not rewrite commits that already exist. In a local test run on 3 October 2026, the existing commit kept its old author until it was amended:

$ git log -1 --format="%an <%ae>"
Dev Example <dev+work@example.com>
$ git config user.email "dev@example.com"
$ git log -1 --format="%an <%ae>"   # unchanged: the commit keeps its old author
Dev Example <dev+work@example.com>
$ git commit --amend --no-edit --reset-author
$ git log -1 --format="%an <%ae>"
Dev Example <dev@example.com>

Amending only suits a commit you have not pushed. For a commit already on the remote, leave history alone and push a new commit with the corrected identity:

git config user.email "you@your-verified-domain.example"
git commit --allow-empty -m "chore: redeploy with the linked author"
git push

If you deliberately commit with several addresses, the troubleshooting page's alternative is to register them as secondary addresses: with your Git provider when the repository is linked to the project, otherwise on your Vercel account, which accepts three addresses at most, no more than two on the same domain. Also confirm your Git provider is listed under Login Connections in your Vercel account settings, under Authentication.

3. A collaborator's commit on a Hobby project: change the plan or the repository#

This is the Stack Overflow case, and no Git setting fixes it. Vercel's troubleshooting page states that the Hobby plan "does not support collaboration for private repositories". The documented ways out are:

• Transfer the project to a Pro team and have the collaborator join it. From then on, the Pro rule applies to their commits.
• Make the repository public. The accounts documentation notes that collaboration on public repositories is free, and the private-repository check does not apply to them.

For a company project there is a second reason to move: Vercel's Hobby plan page says the plan is restricted to non-commercial, personal use.

4. A Pro team: the author is not a member yet#

On a Pro team, the commit author needs a Vercel account with their Git provider linked. Vercel's collaboration settings, under team Settings, Members, Collaboration, decide what happens next. With auto approval, the author is added as a Developer, which is a paid seat. With manual approval, the deployment is blocked and owners get a request to approve. After an approval, the committer has to redeploy their changes. If the author has no linked Vercel account, the deployment fails whichever mode is set, until they create one and connect their Git provider.

Workarounds to treat with care#

Two answers on the question are popular and need context. Setting git config user.email to the project owner's address is reported in the top answer to get the deployment through; it cannot help when the repository belongs to an organisation and the project is on Hobby, since that combination cannot deploy at all. It also makes Git and GitHub credit your commits to that person, and on a Hobby project it routes around a plan limit instead of fixing it.

The other answer creates a Deploy Hook and calls it from a GitHub webhook. Deploy Hooks are a documented feature: a URL that triggers a deployment of one branch, with no authentication, so the URL has to be kept as secret as a password. Vercel does not document them as a way past the author check. Its own troubleshooting section for hooks says to look at the status check on the commit associated with the hook and points to the same collaboration troubleshooting page, so expect the commit author to matter there too.

Confirm deployments are back#

After the fix, run git log -1 --format="%an <%ae>" again and check that it shows the identity you linked. Push, then open the commit on GitHub: the Vercel status should move to a deployment in progress instead of the access error, and the deployment appears in the project's Deployments list. If the build now starts but fails, that is a different problem: builds that pass locally and fail on Vercel usually come down to case-sensitive imports, path aliases or devDependencies.

Once the first deployment succeeds, two follow-ups often surface on the same day. NEXT_PUBLIC_ variables added while deployments were blocked are only inlined into a new build, as explained in why Next.js env variables stay undefined on Vercel until you redeploy. And if the project uses Supabase Auth, the preview URLs that start deploying again need to be allowed as redirect targets, which is what fixing Supabase redirectTo on Vercel preview deployments covers.

Further reading: Fix /tmp/chromium libnss3.so Error on Vercel and Lambda. Also see Fix Vercel 404: NOT_FOUND Deploying an Express App.