Første gang jeg deployet en Next.js-app til Vercel, tok det under to minutter. Koble til GitHub, velg repo, klikk deploy. Ingen Dockerfile, ingen nginx-konfigurasjon, ingen CI/CD-pipeline å sette opp. Det bare fungerte.
Den opplevelsen er både Vercels største styrke og største fare. Det er så enkelt at du glemmer å tenke over hva du gir opp i bytte. Denne guiden handler om begge sider — hvorfor jeg bruker Vercel, og når jeg velger noe annet.
Hvorfor Vercel for Next.js?
Det korte svaret: Vercel er bygget av teamet som lager Next.js. Ingen andre plattformer forstår Next.js sine features like godt.
Edge Functions. Middleware kjører på edge — nært brukeren, med minimal latens. For denne nettsiden betyr det at språkdeteksjon og omdirigering skjer på under 10ms, uansett hvor i verden du er.
Preview Deployments. Hver pull request får sin egen URL med en komplett versjon av appen. Jeg bruker dette aktivt for code review — istedenfor å sjekke ut branchen lokalt, klikker jeg på preview-lenken og ser endringene live.
Inkrementelle builds. Vercel cacher build-resultater aggressivt. Når jeg endrer én bloggpost, bygger den bare den siden på nytt — ikke hele appen. For et prosjekt med mange statiske sider er dette en enorm tidsbesparelse.
Analytics og Web Vitals. Innebygd overvåking av Core Web Vitals gir meg reelle ytelsesdata fra faktiske brukere, ikke bare syntetiske tester.
Konfigurering med vercel.json
For de fleste Next.js-prosjekter trenger du ingen konfigurasjon i det hele tatt. Men når du trenger å tilpasse noe, er vercel.json der du gjør det:
{
"framework": "nextjs",
"regions": ["arn1"],
"headers": [
{
"source": "/api/(.*)",
"headers": [
{ "key": "Cache-Control", "value": "no-store, must-revalidate" },
{ "key": "X-Content-Type-Options", "value": "nosniff" }
]
},
{
"source": "/(.*)",
"headers": [
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" }
]
}
],
"rewrites": [
{ "source": "/cv", "destination": "/api/cv" }
]
}regions: ["arn1"] deployer til Stockholm, som gir lavest latens for norske brukere. Headers-seksjonen setter sikkerhetshoder — noe mange glemmer, men som er viktig for produksjon. Rewrites lar deg mappe URLer uten å eksponere den underliggende API-strukturen.
Miljøvariabler og secrets
En ting Vercel gjør bra er håndtering av miljøvariabler. Du kan definere forskjellige verdier for Production, Preview og Development:
# Vercel CLI — legg til en miljøvariabel
vercel env add DATABASE_URL production
vercel env add DATABASE_URL preview
vercel env add DATABASE_URL development
# Pull miljøvariabler til lokal utvikling
vercel env pull .env.localvercel env pull er spesielt nyttig. Istedenfor å manuelt kopiere .env-filer mellom utviklere, kan alle på teamet kjøre denne kommandoen for å få riktige verdier. Secrets er kryptert og aldri eksponert i logger eller build-output.
Sammenlignet med Firebase Hosting
Jeg bruker Firebase Hosting for noen prosjekter, spesielt de som allerede er dypt integrert med Firebase-økosystemet (Firestore, Authentication, Cloud Functions). Men for Next.js-prosjekter er Vercel overlegen.
Server-side rendering. Firebase Hosting er primært for statiske filer. For SSR må du sette opp Cloud Functions eller Cloud Run, noe som krever betydelig mer konfigurasjon. Vercel håndterer SSR, SSG, ISR og streaming ut av boksen.
Deploy-hastighet. En typisk deploy til Vercel tar 30-60 sekunder. Firebase Hosting med Cloud Functions kan ta 3-5 minutter.
Developer experience. Vercel CLI, preview deployments, og integrasjonen med GitHub er vesentlig mer polert enn Firebase sin tilsvarende opplevelse.
Men Firebase har fordeler Vercel mangler. Firebase sitt gratistilbud er mer sjenerøst for backend-tjenester. Firestore og Realtime Database har ingen direkte ekvivalent hos Vercel. Og Firebase Authentication er enklere å sette opp enn å bygge auth selv på Vercel.
Begrensningene — og når du bør velge noe annet
Vendor lock-in. Vercel-spesifikke features som Edge Config, KV, og Blob er proprietære. Hvis du bruker dem tungt, er du låst til plattformen. Jeg holder meg bevisst til standard Next.js-features der det er mulig.
Prising. Gratisplanen er sjenerøs for hobbyprosjekter, men Pro-planen til $20/måned per teammedlem kan bli dyrt for team. Og datautgifter utover gratiskvoten er ikke billige. For Tuli vurderte jeg Vercel, men endte med Cloud Run for backend fordi kostnadsstrukturen var mer forutsigbar.
Serverless-begrensninger. Funksjoner har en maksimal kjøretid (10 sekunder på Hobby, 60 på Pro). Ingen WebSockets — du trenger en ekstern tjeneste for sanntidskommunikasjon. Og cold starts kan merkes for sjeldent brukte API-ruter.
Egress-kostnader. Vercel sin prising for båndbredde kan overraske. Hvis du serverer store filer eller har mye trafikk, kan kostnadene eskalere raskt. For bilder og media bruker jeg Cloudflare R2 eller Firebase Storage istedenfor å servere dem direkte fra Vercel.
Min tilnærming
Vercel er mitt standardvalg for Next.js-frontender. Denne nettsiden, porteføljen min, og flere sideprosjekter kjører der. For backend-tjenester, databaser og tung prosessering velger jeg andre plattformer — Google Cloud Run, Supabase, eller Firebase avhengig av behovet.
Nøkkelen er å bruke Vercel for det det er best på: rask, pålitelig hosting av Next.js-applikasjoner med god developer experience. Ikke prøv å presse hele stacken inn på plattformen — da møter du begrensningene raskere enn du tror.
Oppsummering
Vercel gjør deploy enkelt. For Next.js-prosjekter er det vanskelig å slå kombinasjonen av zero-config, preview deployments og edge-infrastruktur. Men gå inn med åpne øyne — forstå prismodellen, vær bevisst på vendor lock-in, og ha en plan for hva som ikke passer på plattformen. Den beste arkitekturen bruker riktig verktøy for riktig jobb.