Deploya till Vercel från CI när den som committar inte är teammedlem
Flytta ett repo till en GitHub-organisation och Vercel börjar tyst blockera dina deployer: committen ”kunde inte matchas mot en teammedlem”. Så här deployar jag i stället från GitHub Actions med Vercels CLI — mina committar räknas fortfarande i min egen GitHub-graf, dashboarden visar fortfarande vem som pushade, och jag köper inte en plats per bidragsgivare.
Jag flyttade landee till en GitHub-organisation så att mina committar skulle räknas i min egen bidragsgraf. Vid nästa push slutade produktionen deploya.
Vercels dashboard sa bara det här — vid varje push. Den inbyggda Git-integrationen hade tyst blivit en spärr:
Deployment Blocked
The deployment was blocked because the commit could not be
matched to a team member.Varför Vercel blockerar deployen
Vercels inbyggda Git-integration är en webhook-deploy: GitHub skickar en push-händelse, Vercel läser commit-författaren, kollar om den är medlem i Vercel-teamet och blockerar deployen om inte. Det är en säkerhetskontroll — den hindrar en godtycklig bidragsgivare, eller en forks pull request, från att automatiskt gå ut i produktion.
Det är rimligt — ända tills den som skriver koden inte är en betald platsinnehavare. Mitt GitHub-konto står som författare till committarna, men det är inte medlem i Vercel-teamet. Så för integrationen är varje deploy från en ”icke-medlem”, och varje deploy blockeras.
Deploya med CLI:t, inte Git-integrationen
CLI:t är utvägen. vercel deploy autentiserar med ett token, inte med commit-författaren — det kör aldrig medlemskapskontrollen. Så koppla bort den inbyggda Git-integrationen och deploya från GitHub Actions i stället: push → workflowet körs → vercel deploy med ett token → Vercel bygger och släpper.
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 }}Två saker gör detta till den enda deploy-vägen, så att CLI:t och webhooken inte tävlar: vercel.json stänger av den inbyggda auto-deployen, och du trycker Disconnect på Git-repot i Vercels dashboard.
{
"git": { "deploymentEnabled": false },
"installCommand": "pnpm install --frozen-lockfile"
}Behåll din GitHub-bidragsgraf
Hela poängen med org-flytten var att committar skulle räknas i min graf — så committen på GitHub måste förbli författad av mig. Det är redan så här: CLI-deployen körs på en färsk checkout inne i runnern, och inget därifrån pushas någonsin tillbaka till GitHub.
Så jag committar som mig själv, pushar, och de gröna rutorna fylls i. Tokenet som auktoriserar deployen tillhör kontoägaren, inte mig — vilket är just poängen med en CI-deploy.
Låt dashboarden visa vem som pushade
En vanlig CLI-deploy dyker upp i Vercels lista som en naken hash — inget meddelande, ingen gren, ingen författare. För att få en riktig git-liknande rad (meddelande + gren + avatar) måste Vercel känna igen deployen som en git-commit — och just den igenkänningen är det som kör om författarkontrollen.
Tricket: inne i runnern, skriv om författaren till HEAD till en teammedlem, och deploya sedan. Amenden pushas aldrig tillbaka, så på GitHub förblir committen din. Vercel läser teammedlem-författaren från .git — deployen känns igen och blockeras inte — och du lägger den som faktiskt pushade i commit-meddelandet så att raden fortfarande säger vem som släppte den.
# 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"Ett servicekonto som alla deployar genom
Generalisera: ett servicekonto äger Vercel-teamet och håller deploy-tokenet. Alla committar som sig själva; CI:t skriver om författaren till servicekontot och deployar med dess token. Dashboard-raden lyder [du] ditt commit-meddelande, och GitHub behåller ditt riktiga författarskap.
Det här är den tråkiga, ärliga versionen av det många team sträcker sig efter. Du betalar för platserna åt dem som behöver dashboard-åtkomst — inte en per bidragsgivare. Ett CI-token som deployar allas kod är modellen Vercel dokumenterar; du köper ingen plats åt någon bara för att deras kod går ut.
Detaljerna som biter
Ett par saker som kostade mig en kväll, så att de inte kostar dig en:
- pnpm på Vercel. Byggavbilden kan låsa en gammal pnpm oavsett ditt
packageManager-fält. Skicka--build-env ENABLE_EXPERIMENTAL_COREPACK=1tillvercel deployså att corepack använder versionen du faktiskt låste. - Verifierade committar. Signering är fristående — sätt upp SSH-signering av committar och registrera nyckeln på GitHub, så får dina (riktiga) committar den gröna Verified-märkningen. Runnerns slit-och-släng-amend behöver ingen signatur.
- Läsbara körningar. Dela upp det enda stora shell-steget i namngivna steg (re-author → deploy → summary) så att Actions-gränssnittet visar stadiet i ett ögonkast.
- Tester. Deployen bygger på Vercel men kör aldrig dina tester — lägg till ett separat CI-workflow för det, och slå på Dependabot medan du ändå är där.
CLI-deployen auktoriseras av ett token, inte av den som skrev committen. Det är hela upplåsningen — och det är ett dokumenterat, förstklassigt sätt att släppa på.
Var gränsen går
Låt oss vara ärliga om gränsen, för det är lätt att prata sig förbi den. Att deploya bidragsgivares kod via ett CI-token är legitimt och tänkt så. Att sätta upp fejkkonton för att kringgå platsdebiteringen är det inte — det är multi-kontoande, och det bryter mot villkoren på varje plattform.
| Det du gör | Legitimt | Över gränsen |
|---|---|---|
| Deploya bidragsgivares kod via ett CI-token | ✓ dokumenterat | |
| Betala en plats åt den som sköter dashboarden | ✓ | |
| Committa som dig själv; serviceidentiteten bara i CI | ✓ ärlig statistik | |
| Skapa fejk-/servicekonton för att slippa betala platser | ✗ multi-kontoande | |
| Dela en inloggning så att många sköter utan platser | ✗ delade inloggningar |
Slutsatser
- Vercels inbyggda Git-integration blockerar deployer vars commit-författare inte är teammedlem — en säkerhetsspärr, inte en bugg.
vercel deploymed ett token kollar aldrig författaren; koppla bort den inbyggda integrationen och deploya från CI.- Committa som dig själv och pusha aldrig runnerns amend, så förblir din GitHub-graf intakt.
- Att skriva om författaren till
HEADtill en teammedlem i runnern ger en riktig dashboard-rad utan block — lägg den som pushade i meddelandet. - Du betalar för dashboard-platser, inte per bidragsgivare: ett CI-token som deployar allas kod är den tänkta modellen.
- Att skapa fejkkonton för att kringgå debitering är multi-kontoande. Där går gränsen.
Inget av det här är exotiskt — CLI:t, ett token, en git amend som aldrig lämnar runnern. Skiftet är att inse att ”icke-medlem”-väggen inte ber dig köpa ännu en plats; den ber dig deploya så som CI är tänkt att göra. Koppla bort webhooken, ge tokenet till runnern — och låt den som skrev koden få äran för den.
Hittade du ett fel?
Ett felaktigt faktum, en skev översättning, något som känns falskt i den här artikeln? Skriv till mig — på ditt eget språk.