Netlify, Vercel, Firebase eller Azure: hvor skal webappen hostes?

Det korte valg

Sammenligning

Tabellen er en arkitekturvejledning, ikke en prisliste. Planer, kvoter og inkluderet forbrug ændres løbende og skal kontrolleres før aftale.

Netlify: enkelt til frontend og previews

Netlify forbinder et Git-repository, bygger projektet og udgiver immutable deploys. Pull requests kan få egne Deploy Preview-URL'er, og en tidligere deploy kan hurtigt genudgives.

Fordele

• Lav friktion til Vite, Astro og statisk genererede sites.
• Deploy Previews, branch deploys og frontend-orienteret workflow.
• Functions og Edge Functions kan håndtere små API'er, formularer og requestlogik.
• Godt valg når frontend og indholdsworkflow er centrum.

Ulemper

• En større backend kan blive spredt over functions, edge-funktioner og eksterne datatjenester.
• Forbrug måles på flere typer ressourcer; budget og alarmer skal sættes bevidst.
• Preview-URL'er kan indeholde ufærdig funktionalitet og bør beskyttes, hvis de bruger følsomme data.

Vercel: stærkest når framework og platform passer sammen

Vercel laver en unik deployment for commits og pull requests og har miljøer til Local, Preview og Production. Platformen understøtter mange frameworks, men den mest tætte integration er med Next.js, som vedligeholdes af Vercel.

Fordele

• Meget enkel deployment af Next.js med SSR, streaming, ISR og framework-caching.
• Preview-deployments og miljøvariabler pr. miljø.
• Global distribution og platformfunktioner til moderne frontendarkitektur.
• God udvikleroplevelse til teams, der lever i Git og pull requests.

Ulemper

• Jo flere platformsspecifikke cache-, image-, edge- og serverfunktioner I bruger, desto mere arbejde kræver en senere flytning.
• Serverless-kørsel er ikke altid det rigtige til lange jobs, vedvarende forbindelser eller tung baggrundsbehandling.
• Preview-beskyttelse, teamfunktioner, observability og forbrug afhænger af planen.

Firebase Hosting: naturligt sammen med Firebase

Firebase Hosting leverer statiske filer via global CDN med automatisk SSL. Rewrites kan sende dynamiske requests videre til Cloud Functions eller Cloud Run, og preview channels kan bruges sammen med GitHub.

Fordele

• Meget enkel hosting af SPA'er og PWA'er med firebase.json.
• God sammenhæng med Firebase Authentication, Firestore, Emulator Suite og Cloud Messaging.
• Preview channels, custom domains, SSL og CDN er samlet.
• Flere sites kan ligge i samme Firebase-projekt, når de reelt deler miljø.

Ulemper

• Hosting er ikke i sig selv en backend; dynamik kræver Functions eller Cloud Run.
• Backend-deployment og visse funktioner kræver billing/Blaze, IAM og Google Cloud-forståelse.
• Et Firebase-projekt kan blive en stor fejldomæne, hvis dev, staging, prod og flere apps blandes.
• Firestore, Auth og Functions øger bindingen til Firebase mere end selve de statiske filer gør.

Azure: vælg først den rigtige Azure-service

Azure Static Web Apps er til genererede statiske frontends som React, Vue, Svelte og Blazor, eventuelt med Functions-API og indbygget routing/adgang. Azure App Service er til en rigtig serverbaseret eller containeriseret webapp med API-endpoints, runtimes og baggrundsopgaver.

Fordele

• Godt match til Microsoft Entra ID, Azure Functions, SQL, Key Vault, Monitor og virksomhedens eksisterende Azure-governance.
• Static Web Apps giver et relativt enkelt Git-baseret frontendflow.
• App Service giver deployment slots, flere runtimes, containere og mere netværkskontrol.
• Ressourcegrupper, RBAC, policies og cost management kan følge virksomhedens eksisterende struktur.

Ulemper

• Azure har flere overlappende hostingprodukter; et forkert valg skaber unødig drift eller begrænsninger.
• Opsætning af identitet, IAM, netværk, abonnementer og observability kræver mere cloudforståelse.
• App Service har typisk mere løbende kapacitets- og prisstyring end ren statisk hosting.
• Static Web Apps er ikke Azure Storage static website hosting; konfiguration og funktioner er forskellige.

Vælg ud fra disse seks spørgsmål

1. 1. Hvad bygger frameworket? Rene statiske filer, en SPA, server-renderet HTML eller en vedvarende backend?
2. 2. Hvor ligger resten af systemet? Firebase, Microsoft/Azure, eksternt API eller platformens egne functions?
3. 3. Hvem ejer driften? Skal en udvikler kunne udgive fra Git, eller har virksomheden et Azure-team med policies og netværkskrav?
4. 4. Hvad må previews se? En preview-URL er ikke automatisk sikker. Brug isolerede testdata og adgangsbeskyttelse.
5. 5. Hvordan skalerer prisen? Kortlæg build-minutter, bandwidth, requests, function-tid, logs, seats og ekstra forbrug – ikke kun startprisen.
6. 6. Hvor dyr er en flytning? Standardiserede statiske filer flytter let. Platformsspecifik SSR, edge-runtime, auth, database og caching flytter ikke lige så let.

Fire realistiske anbefalinger

• Vite/React-marketing- eller kundeportal uden tung backend: Start med Netlify eller Azure Static Web Apps, hvis Microsoft-miljøet er vigtigt.
• Next.js med SSR og frameworkfunktioner: Vercel er det enkleste udgangspunkt; dokumentér de Vercel-specifikke dele.
• React-app med Firebase Auth og Firestore: Firebase Hosting holder frontend, previews og Firebase-miljø samlet.
• Intern virksomhedsapp med Entra, Azure SQL og netværkskrav: Azure Static Web Apps plus Functions eller App Service er normalt mere naturligt end at sprede løsningen over flere clouds.

Uanset platform: gør dette før produktion

• □ Produktion deployes fra en beskyttet Git-branch gennem en dokumenteret pipeline.
• □ Preview, staging og produktion har separate secrets og data.
• □ Custom domain, HTTPS, redirects, security headers og SPA-fallback er testet.
• □ Backendens region ligger fornuftigt i forhold til database og brugere.
• □ Logs, alarmer, budget og ansvarlig modtager er sat op.
• □ Rollback er gennemført som test – ikke kun beskrevet.
• □ Kode, data, domæne og cloudkonto ejes af kunden eller er eksplicit aftalt.
• □ Exit-planen beskriver, hvilke dele der kan flyttes, og hvilke der er platformsspecifikke.

Relaterede guides