Deploy to Vercel from CI when the committer isn't a team member

I moved landee into a GitHub organization so that my commits would count toward my own contribution graph. The very next push, production stopped deploying.

Vercel's dashboard just said this — on every push. The native Git integration had quietly turned into a gate:

Deployment Blocked
The deployment was blocked because the commit could not be
matched to a team member.

Why Vercel blocks the deploy

Vercel's native Git integration is a webhook deploy: GitHub sends a push event, Vercel reads the commit author, checks whether that author is a member of the Vercel team, and blocks the deploy if they aren't. It's a security control — it stops a random contributor, or a fork's pull request, from auto-shipping to production.

That's reasonable, right up until the person writing the code isn't a paid seat holder. My GitHub account authors the commits, but it isn't a member of the Vercel team. So every deploy the integration sees is “not a member,” and every deploy is blocked.

Deploy with the CLI, not the Git integration

The CLI is the way out. vercel deploy authenticates with a token, not with the commit author — it never runs the membership check. So disconnect the native Git integration and deploy from GitHub Actions instead: push → the workflow runs → vercel deploy with a token → Vercel builds and ships.

name: Deploy Production (Vercel CLI)

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
    steps:
      - uses: actions/checkout@v7
      - run: npm install -g vercel@latest
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}

Two things make this the only deploy path, so the CLI and the webhook don't race each other: vercel.json disables the native auto-deploy, and you press Disconnect on the Git repo in the Vercel dashboard.

{
  "git": { "deploymentEnabled": false },
  "installCommand": "pnpm install --frozen-lockfile"
}

Keep your GitHub contribution graph

The whole point of the org move was for commits to count toward my graph — so the commit on GitHub must stay authored by me. That's already true here: the CLI deploy runs on a fresh checkout inside the runner, and nothing there is ever pushed back to GitHub.

So I commit as myself, push, and the green squares fill in. The token that authorizes the deploy belongs to the account owner, not to me — which is exactly the point of a CI deploy.

Make the dashboard show who pushed

A plain CLI deploy shows up as a bare hash in Vercel's list — no message, no branch, no author. To get a real git-style row (message + branch + avatar), Vercel has to recognize the deploy as a git commit — and that recognition is exactly what re-runs the author check.

The trick: inside the runner, rewrite HEAD's author to a team member, then deploy. The amend is never pushed back, so on GitHub the commit stays yours. Vercel reads the team-member author from .git — the deploy is recognized and not blocked — and you put the real pusher in the commit message so the row still says who shipped it.

# In the runner only — this amend is NEVER pushed back, so on GitHub the
# commit stays authored by the real pusher (your contribution graph is intact).
MSG="$(git log -1 --pretty=%s)"
git -c user.name="CI Bot" -c user.email="ci@your-org.dev" \
  commit --amend --author="CI Bot <ci@your-org.dev>" \
  -m "[$GITHUB_ACTOR] $MSG"

# Vercel now reads a team-member author from .git → recognized AND not blocked.
vercel deploy --prod --token="$VERCEL_TOKEN"

One service account, everyone deploys through it

Generalize it: one service account owns the Vercel team and holds the deploy token. Everyone commits as themselves; CI re-authors to the service account and deploys with its token. The dashboard row reads [you] your commit message, and GitHub keeps your real authorship.

This is the boring, honest version of what plenty of teams reach for. You pay for the seats that people who need dashboard access hold — not one per contributor. A CI token deploying everyone's code is the model Vercel documents; you don't buy a seat for someone just because their code ships.

The details that bite

A few things that cost me an evening, so they don't cost you one:

• pnpm on Vercel. The build image can pin an old pnpm regardless of your packageManager field. Pass --build-env ENABLE_EXPERIMENTAL_COREPACK=1 to vercel deploy so corepack uses the version you actually pinned.
• Verified commits. Signing is separate from all of this — set up SSH commit signing and register the key on GitHub, and your (real) commits get the green Verified badge. The runner's throwaway amend doesn't need a signature.
• Readable runs. Split the one big shell step into named steps (re-author → deploy → summary) so the Actions UI shows the stage at a glance.
• Tests. The deploy builds on Vercel but never runs your tests — add a separate CI workflow for that, and turn on Dependabot while you're there.

The CLI deploy is authorized by a token, not by whoever wrote the commit. That's the whole unlock — and it's a documented, first-class way to ship.

Where the line is

Let's be honest about the boundary, because it's easy to talk yourself past it. Deploying contributors' code through a CI token is legitimate and intended. Spinning up fake accounts to dodge per-seat billing is not — that's multi-accounting, and it's against the terms of every platform that does it.

Takeaways

• Vercel's native Git integration blocks deploys whose commit author isn't a team member — a security gate, not a bug.
• vercel deploy with a token never checks the author; disconnect the native integration and deploy from CI.
• Commit as yourself and never push the runner's amend, and your GitHub graph stays intact.
• Re-authoring HEAD to a team member in the runner gets a proper dashboard row without a block — put the real pusher in the message.
• You pay for dashboard seats, not per contributor: a CI token deploying everyone's code is the intended model.
• Making sock accounts to dodge billing is multi-accounting. That's the line.

None of these pieces are exotic — the CLI, a token, a git amend that never leaves the runner. The shift is realizing the “not a member” wall isn't telling you to pay for another seat; it's telling you to deploy the way CI is meant to. Disconnect the webhook, hand the token to the runner, and let the person who wrote the code keep the credit for it.