Vercel vs Netlify vs Cloudflare Pages – hvilken host føles mindst i vejen?

Det korte svar er at du højst sandsynligt bliver glad for enten Vercel eller Netlify til dit næste frontend-projekt. Men det længere svar er mere interessant.

For nogle projekter er Cloudflare Pages faktisk det mest fornuftige valg, selvom deres UI ligner noget en backend-ingeniør har fået lov til at bestemme. Og forskellen på de tre mærker du først, når du rammer routing-fejl, mærkelige 404-sider og env-vars der pludselig er tomme i dine deploy-previews.

Hvad du faktisk vælger mellem (ikke bare logoer og marketing)

Jeg vil starte med at skære alle tre ned til, hvad du konkret mærker som udvikler:

1) Hvordan du deployer: er det bare “push til main” og færdig, eller skal du kæmpe lidt med byg-scripts og indstillinger?

2) Hvordan routing opfører sig: især hvis du bygger en SPA (single page app) med React, Vue, Svelte osv. eller en SSR-app (server side rendered) med Next.js/Nuxt.

3) Hvordan environment variables fungerer: hvilke er tilgængelige i buildet, hvilke i serverless/edge functions, og hvad sker der i deploy previews.

4) Deploy previews: hvor nemt det er at få et link til en PR, som du kan sende til en ven, lærer eller kunde.

5) Hvad du betaler med: enten i kroner eller i tid/irritation.

Jeg bruger de tre sådan her i praksis:

– Vercel til alt der er Next.js-tungt, SSR, edge-funktioner og små projekter med få besøgende.

– Netlify til simple SPA’er, statiske sider, små sideprojekter med forms og hvor deres UI giver mening for klienter/medstuderende.

– Cloudflare Pages når jeg vil tæt på kanten (edge), har brug for Cloudflare Workers eller i forvejen ligger bag Cloudflare og vil have gratis performance.

Lad mig folde dem ud en ad gangen, med fokus på hvad du mærker, ikke hvad marketing-siderne siger.

Vercel vs Netlify vs Cloudflare Pages i hverdagen

Vercel: super strømlinet til moderne frameworks, men pas på prisen

Vercel føles som at spille på hjemmebane, hvis du arbejder med Next.js. De har bygget hele platformen rundt om idéen om “framework-aware” hosting: du forbinder dit GitHub-repo, de gætter ofte rigtigt på framework, build-kommando og output-mappe, og du har et deploy kørende efter et par minutter.

Typisk setup for et React/Next-projekt:

// package.json
{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

På Vercel er det ofte nok bare at have “build”-scriptet, så kører det. De laver automatisk:

– Deploy previews for hver PR.

– “Production” deploy når du merger til main/master.

– Gode logs og mulighed for at se build-logs og function-logs i UI’et.

Hvor Vercel virkelig skinner:

– SSR og edge: Next.js + Vercel føles næsten som én ting. API routes, middleware, edge functions, image optimization, alt det tunge er tydeligt tænkt sammen.

– Routing: du definerer det i frameworket (Next-routes, file based routing), og Vercel oversætter det til deres hosting-setup. Du behøver næsten aldrig selv pille ved redirects/rewrites i en config-fil.

– DX (developer experience): CLI’en, UI’et, previews og logs føles generelt ret glatte.

Men der er bagsider:

– Pris: gratis-planen er fin til hobby, men så snart du har lidt trafik, mange serverless-kald eller team-features, begynder regningen at løbe. Spørgsmålet “hvad koster Vercel” er ikke altid nemt at svare på, før du faktisk har haft noget kørende i en måned.

– Vendor lock-in følelse: bygger du tungt på Vercel-specifikke features som edge-config, image-optimering og deres function-miljø, er det ikke altid trivialt at flytte væk igen.

– Serverless timeouts og limits: du rammer typisk begrænsninger hurtigere på Vercel end på en “rigtig” server. Til hobby er det fint, til tungere backend-arbejde får du brug for en separat backend.

Til en studerende eller en der bygger små freelance-projekter vil jeg sige: hvis du bruger Next.js, vælg Vercel først, med mindre du på forhånd ved, at trafik og pris bliver en faktor.

Netlify: frontend-venlig, god til simple apps og forms

Netlify var i mange år “default” for JAMstack: Git repo, statisk build, deploy til CDN. Simpelt, hurtigt og ret tilgængeligt for begyndere.

Hvis du har en typisk Vite + React SPA, ser det sådan her ud:

// package.json
{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

I Netlify UI sætter du:

– Build command: npm run build

– Publish directory: dist

Så kører det. De laver også:

– Deploy previews for hver PR.

– Automatisk SSL, CDN, basale logs.

Styrker i praksis:

– Simple projekter: dokumentationssider, personlige porteføljer, små single page apps. Her føles Netlify rart og gennemsigtigt.

– Forms: deres inbyggede forms-funktion kan være ret handy, hvis du vil have en kontaktform uden backend. Du tilføjer bare netlify attribute på en form, så samler de submissions.

– Redirects og rewrites via _redirects-fil eller netlify.toml: ret tydelig og simpel model (når man lige kender den).

Men routing er også der, flest nybegyndere løber panden mod muren.

Hvis du bygger en SPA, så browseren selv håndterer routing (React Router, Vue Router osv.), og du ikke sætter rewrites korrekt, får du:

– 200 OK på /

– 200 OK på /about, hvis du klikker derhen inden fra siden.

– 404, hvis du refresher på /about eller går direkte ind på URL’en.

Det svarer til den klassiske fejl “det virker på min maskine” bare i hosting-version.

Løsningen er at tvinge alle ukendte routes tilbage til /index.html, så din SPA-router får chancen for at matche stien.

Typisk _redirects-fil til en SPA:

/*  /index.html  200

Det lille stykke tekst har reddet mange React/Vue apps fra evig 404.

På pris-siden er Netlify lidt mere afslappet for mindre projekter. Du får ret meget for gratis, men deres build-minutter kan blive en flaskehals, hvis du har mange projekter og ofte deployer.

Cloudflare Pages: hurtigt, tæt på brugerne og lidt mere low-level

Cloudflare Pages er den nyeste spiller i forhold til frontend-hosting, men Cloudflare selv har jo været “internettets network-lag” i lang tid.

Pages føles mere som et lag oven på deres eksisterende infrastruktur end et klassisk “vi gør alt for dig” produkt. Det er både godt og lidt skræmmende, hvis du er ny.

Her er hvor Cloudflare Pages giver mening:

– Statiske sites: dokumentation, blog, marketing-sider. Hurtige, billige og distribueret ud på Cloudflares store edge-netværk.

– Edge-funktioner via Cloudflare Workers: hvis du vil lave lette API’er, A/B-tests, redirects, auth-checks tæt på brugeren.

– Hvis du i forvejen bruger Cloudflare DNS, cache og regler: så bliver alt samlet et sted, og du slipper for at rode med flere platforme.

Typisk setup for Vite/React på Cloudflare Pages:

– Build command: npm run build

– Build output directory: dist

Routing for en SPA klarer du via en _routes.json eller via redirects i Pages-projektet, afhængig af hvad du laver.

Det føles en smule mere “her har du værktøjerne, du må selv samle dem” end Vercel/Netlify. For nogle er det fedt. For andre er det bare ekstra mentale steps.

Til gengæld er gratis-planen ret generøs, og performance er svær at sætte en finger på, fordi du ligger så tæt på kanten rent netværksmæssigt.

Routing: hvor de fleste frontend-projekter vælter

Inden vi går helt ned i env-vars og deploy previews, bliver vi nødt til at rydde op i routing-typerne. For meget af forskellen på Vercel vs Netlify vs Cloudflare Pages handler om, hvordan de serverer filer og responses.

Tre måder at tænke routing på

1) Statisk site:

– Hver URL svarer til en genereret HTML-fil: /about -> /about/index.html.

– Hosting-platformen skal bare finde den rigtige fil og sende den.

– Typisk bygget med Astro, Gatsby, Hugo, Jekyll eller Next.js i “static export” mode.

2) SPA (single page app):

– Der findes i praksis kun én HTML-fil: /index.html.

– JavaScript’en i browseren håndterer routing, fx React Router.

– Hosting-platformen skal returnere 404, bare fordi den ikke har en fysisk fil til /profile/123. Den skal give dig /index.html og lade JS’en afgøre, hvad der skal vises.

3) SSR/Hybrid (server side rendering):

– Serveren genererer HTML på request-tid for en route, fx Next.js API route eller server component.

– Hosting-platformen skal kunne køre kode ved request, typisk via serverless functions eller edge functions.

Når du vælger host, vælger du indirekte også, hvor meget du vil læne dig op ad deres måde at håndtere de tre mønstre på.

Routing-forskel i praksis på de tre

Vercel:

– Next.js: du definerer routes i app eller pages mappen. Vercel læser det og sætter edge/serverless routes op.

– SPA uden SSR (f.eks. create-react-app eller Vite SPA): du skal typisk bruge en vercel.json med en rewrite til /index.html for alle ikke-matchede routes.

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

Netlify:

– SPA: brug _redirects-filen.

/*  /index.html  200

– SSR/hybrid: de har Netlify Functions og nyere features til SSR, men oplevelsen er ikke lige så strømlinet som Next.js på Vercel. Fungerer, men kræver mere opsætning.

Cloudflare Pages:

– SPA: du kan bruge “Single Page Application” toggles i UI eller konfigurere routes med en _routes.json.

– SSR via Workers: så er du pludselig inde i Workers-land, hvor du har meget fleksibilitet, men også mere low-level kode.

Hvis du er ny og bare vil have din React-app online uden 404-helvede, er min erfaring:

– Vælg Vercel eller Netlify.

– Opsæt den ene lille rewrite-regel én gang.

– Gem den i din README, så du husker det til næste projekt.

Der er en god artikel om miljøvariabler på Coding Class, som forklarer frontend vs backend og build vs runtime. Men lad os tage hosting-specifikken her.

Environment variables: build vs runtime på Vercel, Netlify og Cloudflare

Env-vars er næste sted, hvor ting typisk går fra “det virkede lokalt” til “hvorfor er alt pludselig undefined i prod?”.

Der er to tidspunkter, en env-var kan blive læst på:

– Build-tid: når din bundler (Vite, Next, webpack) kører, inden filerne uploades.

– Runtime: når en serverless function, edge function eller Worker kører på serveren.

Og så er der forskel på, om variablen ender i:

– Frontend-koden (browseren kan se den, så den må være hemmelig).

– Backend/edge-koden (hemmelig, fx API-nøgler).

Vercel env-vars i praksis

På Vercel har du typisk tre miljøer:

– Development (lokalt)

– Preview (deploy previews, hver PR)

– Production (main-branch deployments)

I deres UI kan du gå ind på dit projekt og sætte env-vars pr. miljø. For Next.js har de nogle konventioner:

– Variabler med prefix NEXT_PUBLIC_ bliver eksponeret til frontend.

– Andre variabler lever kun på server/edge.

Typisk fejl: du sætter en env-var i “Production”, men tester på en preview URL. Preview-deployet har ikke den env-var, med mindre du også tilføjer den til “Preview” miljøet.

Det er her, Vercels opdeling mellem build-env og runtime-env også gør en forskel:

– Build-env: bruges når din app bygges. Hvis du ændrer en env-var, skal du bygge igen, før ændringen slår igennem i statiske filer.

– Runtime-env: bruges af serverless/edge functions ved request-tid. Her kan du ændre værdien uden at bygge hele appen om.

Når du rammer en fejl hvor noget er undefined i prod, gør det her en forskel på, hvordan du fejlsøger. Der er en længere gennemgang på denne artikel om env-vars, hvis du vil nørde helt ned i det.

Netlify env-vars

Netlify har også miljøer, men deres UI føles en anelse mere simpelt:

– Du sætter env-vars pr. site.

– De bliver tilgængelige ved build.

– De kan bruges i Netlify Functions.

Hvis du bruger Vite på Netlify, har du samme frontend-konvention: variabler med VITE_ prefix bliver bygget ind i bundlet og er synlige i browseren.

VITE_API_URL=https://api.example.com

Når du så i din kode gør:

const apiUrl = import.meta.env.VITE_API_URL;

… så erstattes det ved build med den konkrete streng, du har sat i Netlify.

Typisk fejl her:

– Du ændrer env-vars i Netlify, men trigger ikke et nyt build, så din app bruger stadig de gamle værdier.

Cloudflare Pages env-vars

På Cloudflare Pages arbejder du også med miljøvariabler, men Workers og Pages har hver deres små særheder.

– Du kan sætte “Environment variables” i Pages projektet, som så bruges ved build.

– Hvis du bruger Workers, kan du også definere secrets i Workers-konfigurationen.

Igen skal du tænke:

– Hvad må browseren se? Det skal være build-env og med et prefix der gøres synligt i bundleren.

– Hvad må kun server/edge se? Det skal være secrets, som bruges i Workers eller serverless-kode.

Hvis du bare vil hoste en statisk side eller en basic SPA, er Cloudflare Pages env-vars sjældent noget, du tænker meget over. Det bliver først interessant, når du blander Workers ind.

Deploy previews: det lille feature der faktisk ændrer din workflow

Deploy previews er for mig det punkt, hvor hosting flytter sig fra “det virker” til “det er rart at arbejde med”. Også selvom du bare sidder alene med et studieprojekt.

Idéen er simpel:

– Hver gang du laver en pull request (PR) eller merge request, bygger hosten en preview-version af din side.

– Du får et unikt URL til den version.

– Du kan teste, vise den til andre eller sammenligne flere previews.

På Vercel og Netlify er det fuldt integreret:

– De poster ofte en kommentar på din PR med link til preview.

– Env-vars kan være anderledes i preview end i production.

På Cloudflare Pages får du også previews, men integrationen med Git hosting og PR-kommentarer kan kræve lidt mere opsætning.

Hvorfor er det værd at gå op i?

– Fordi du slipper for manuelt at skulle deploye til en test-URL hver gang.

– Fordi du kan teste ændringer med “rigtige” URLs, ikke bare lokalt på localhost:5173.

Et lille trick, jeg bruger ret ofte:

– Behold én fast “preview”-branch (fx staging).

– Merge feature-branches ind i staging, test på preview-URL’en.

– Først derefter merge til main/production.

Det kan du gøre, uanset om du ligger på Vercel, Netlify eller Cloudflare Pages. Men Vercel og Netlify gør det ærligt talt lidt sværere at lade være med at bruge previews, fordi de bare fungerer.

Pris og limits: hvornår du typisk rammer væggen

Jeg kommer ikke til at liste alle prisplaner, for de ændrer dem hurtigere, end jeg kan nå at skrive. Men jeg kan pege på, hvad du typisk rammer ind i som hobby-udvikler eller lille team.

Vercel

Gratis-planen giver normalt:

– Begrænsede build-minutter.

– Begrænsede serverless-invocations og edge-requests.

– Begrænset antal projekter/medlemmer.

Hvor du mærker det:

– Hvis du har mange små projekter og ofte pusher, bruger du build-minutterne.

– Hvis du har en SSR-tung app, bruger du serverless/edge-kvoten hurtigere.

Hvis du laver et portfolio-site, en lille blog eller en simpel app med få brugere, er det sjældent et reelt problem. Men en populær hobby-projekt-side kan overraske dig i regnskabet.

Netlify

Netlify begrænser også build-minutter og antal teammedlemmer på gratis-planen.

Hvor du typisk rammer noget:

– Mange builds på tværs af flere projekter (især hvis du har automations og CI sat op).

– Hvis du bruger deres Netlify Functions tungt.

Hvis du hovedsageligt hoster statisk output og enkelte små API-funktioner, er de ret tilgivende.

Cloudflare Pages

Cloudflare har generelt ret generøse gratis-planer, fordi deres forretning også ligger andre steder (DNS, enterprise, security osv.).

Du rammer typisk limits på:

– Workers CPU-tid, hvis du laver tung edge-logik.

– Antal projekter og avancerede features, hvis du bevæger dig ind i enterprise-hjørnet.

Til simple sites er Pages ofte det billigste valg på den lange bane, især hvis du alligevel bruger dem til DNS og cache.

Hurtig beslutningshjælp: 5 scenarier og hvad jeg ville vælge

Nu kommer den del, jeg selv savnede, da jeg begyndte at lege med de her platforme: “Hvis jeg bygger X, hvad bør jeg så reelt vælge?”

1) Lille portfolio eller CV-side

Teknologi: statisk HTML/CSS eller et simpelt Astro/Hugo/Eleventy-site.

Jeg ville vælge:

– Netlify eller Cloudflare Pages.

Grunde:

– Du har ikke brug for SSR eller tunge edge-gimmicks.

– Statisk output kører glimrende begge steder.

Hvis du er mere tryg ved et “pænt” UI og gode guides, føles Netlify lidt lettere at lande i som ny.

2) SPA med React/Vue/Svelte (Vite, CRA, Nuxt i SPA-mode)

Teknologi: ren frontend-router, ingen SSR.

Jeg ville vælge:

– Vercel eller Netlify.

Og så sørge for:

– En rewrite / redirect-regel, der sender alle routes til /index.html.

Hvis du senere vil koble en backend på, vil jeg ofte lade backend køre separat (fx på Render/Fly/DigitalOcean) og lade frontend ligge på en af de tre her. Det er et mønster, som også går igen i andre artikler på Coding Class: små særskilte dele, der gør én ting hver.

3) Next.js-app med SSR, API routes og måske edge-middleware

Teknologi: Next.js, SSR, dynamiske sider, evt. server components.

Jeg ville vælge:

– Vercel.

Her er oplevelsen bare mest gnidningsfri. Deploy previews, logs, env-vars og hele deres integrationslag er tydeligt bygget med Next for øje. Du kan godt køre Next.js andre steder, men du får ekstra opsætning oveni.

4) Dokumentationssite eller blog med mange besøgende

Teknologi: statisk genereret site (Astro, Next static export, Hugo osv.).

Jeg ville vælge:

– Cloudflare Pages eller Netlify.

Grunde:

– Statisk output er let at cache og levere hurtigt.

– Cloudflare Pages er stærk på performance pga. deres edge-netværk.

Hvis du regner med meget trafik, kan Pages være billigere i længden. Men Netlify er også stadig et solidt valg her.

5) Projekt hvor du vil eksperimentere med edge, Workers og lave små API’er ved kanten

Teknologi: Cloudflare Workers, måske Pages + Workers integration.

Jeg ville vælge:

– Cloudflare Pages.

Her giver det ikke meget mening at gå via Vercel/Netlify, når du egentlig vil bruge Cloudflare Workers som motor. Du kan stadig lade frontend ligge på Pages og bruge Workers til alle små API-behov.

Hvor du kan bygge videre herfra

Hvis du læser det her som begynder og tænker “det er mange ord for bare at lægge en side på nettet”, så har du ret. Men det er også her, du lærer ting, der går igen, når du senere skal sætte CI/CD op, bygge backends eller tænke DevOps.

Et konkret næste skridt kunne være:

– Vælg ét af dine eksisterende små projekter (en React-app, en simpel HTML-side, et lille Next-projekt).

– Deploy det til Vercel.

– Deploy det samme repo til Netlify.

Sammenlign:

– Hvad var nemmest at sætte op?

– Hvor får du bedst overblik over builds og fejl?

– Hvem gør mest for dig automatisk, og hvornår bliver det forvirrende?

Hvis du har mod på det, så prøv at lave samme øvelse med Cloudflare Pages. Det føles lidt mere manuelt, men du lærer meget om, hvad der i virkeligheden sker bag UI’et på de to andre.

Jeg havde en aften, hvor jeg var sikker på, at jeg havde knækket et projekt på Vercel, fordi halvdelen af siderne kastede 404 i produktion. Det viste sig at være én manglende rewrite-regel til min SPA-routing. Det tog 30 sekunder at rette, men havde kostet mig to timer og en lettere bekymret kat, der ikke kunne forstå, hvorfor jeg talte højt til skærmen.

Det er cirka sådan her hosting føles de første par projekter: lidt rodet, lidt “hvorfor virker det sådan” og ret tilfredsstillende, når du til sidst får dit eget domæne til at vise noget, du selv har bygget. De tre platforme her hjælper dig derhen på hver deres måde. Resten er mest et spørgsmål om, hvem du bliver mindst træt af at skændes med.