ArgoCD och Vercel: två verktyg, samma arbetsflöde

På ytan ser ArgoCD och Vercel ut som väldigt olika produkter. ArgoCD är en GitOps-controller som synkar Kubernetes-manifest från ett Git-repo in i ett kluster. Vercel är en hostingplattform som bygger och driftar Next.js-appar (och andra ramverk) direkt från ett Git-repo. Olika världar — men tittar man på själva arbetsflödet är de förvånansvärt lika.

Det är just den likheten som gör att team som vant sig vid Vercel snabbt förstår GitOps, och tvärtom.

Git som enda sanningskälla

Bägge verktygen utgår från samma grundprincip: det som finns i Git är det som ska köras. Du beskriver önskat tillstånd deklarativt — manifests, vercel.json, miljövariabler — och plattformen ser till att verkligheten matchar.

• I ArgoCD pekar en Application på en mapp i ett repo. Controllern jämför desired med actual och reconcilar.
• I Vercel pekar ett projekt på en branch. När du pushar bygger Vercel om och deployar.

Båda fall innebär att en git revert är din rollback. Du ändrar inte produktion via klick i ett UI — du ändrar Git.

Preview-miljöer per branch

Det här är kanske den tydligaste likheten i utvecklarupplevelsen. Vercel ger varje pull request en egen preview-URL. ArgoCD, via ApplicationSets eller verktyg som Argo Rollouts och PR-generatorn, kan ge varje branch sin egen ephemeral miljö i klustret.

I båda fallen får team samma sak: en delbar länk där produktägare, designers eller QA kan klicka runt innan merge. Du behöver inte boka "test-miljön" — du får din egen.

Webhook-drivet, ingen manuell deploy-knapp

Varken ArgoCD eller Vercel kräver att någon trycker "deploy". En push utlöser webhooks som triggar synk eller bygge. Det betyder att leveranspipelinen är osynlig i den dagliga rutinen — utvecklare jobbar i Git och plattformen sköter resten.

Det är en stor skillnad mot klassiska CI/CD-flöden där man konfigurerar deploy som ett steg i pipelinen. Här är deploy en konsekvens av att repo-tillståndet ändrats, inte ett separat jobb.

Driftdetektering och reconciliation

ArgoCD jämför kontinuerligt klustertillståndet med Git och visar OutOfSync om någon ändrat något manuellt. Vercel är inte lika explicit, men logiken är densamma: byggartefakten kommer alltid från ett commit-SHA, och en avvikelse syns i deployment-historiken.

För utvecklarna betyder det att man kan svara på frågan "vad körs egentligen i produktion just nu?" genom att titta i Git, inte genom att SSH:a in någonstans.

Var de skiljer sig

Likheten ligger i flödet — inte i räckvidden. ArgoCD bryr sig inte om vad du deployar; det kan vara en backend, en CRD eller en infrastrukturkomponent. Vercel är optimerat för frontend och edge-funktioner och tar bort i princip allt val kring runtime, CDN och bygginfrastruktur.

ArgoCD ger dig kontroll och kräver att du äger plattformen. Vercel ger dig hastighet och tar bort plattformen som problem. Det är två olika positioner på samma axel — inte två olika filosofier.

Varför det spelar roll

När man förklarar GitOps för team som bara känner till Vercel brukar lampan tändas snabbt: "ah, det är samma sak som Vercel, fast för Kubernetes". Och tvärtom — backend-team som lärt sig ArgoCD känner igen sig direkt när de möter Vercel för första gången.

Det är värt att notera, för det betyder att GitOps inte är en exotisk Kubernetes-grej. Det är samma utvecklarflöde som miljontals frontend-utvecklare redan använder varje dag — bara med ett annat mål för deployen.