Skal appen din svare på under fem millisekunder uansett hvor i verden brukeren sitter, ender valget som regel opp mellom to plattformer: Cloudflare Workers og Fastly Compute. Begge lover kode som kjører nær brukeren i stedet for i ett sentralt datasenter, men de er bygget på helt ulik arkitektur, prises helt ulikt, og passer til dels ulike arbeidslaster. Denne artikkelen går gjennom nettverk, ytelse, priser og reelle brukstilfeller for begge, med tall hentet direkte fra Cloudflare og Fastly sine egne prissider per 28. september 2026.
Kort oppsummert: Cloudflare har et større globalt fotavtrykk med over 335 datasentre mot Fastlys 166 punkter for tilstedeværelse (PoP-er), og Cloudflare Workers har ingen ekstra kostnad for utgående trafikk. Fastly Compute bygger i stedet alt på WebAssembly fra bunnen av, og gir deg flere språkalternativer som Rust og Go via TinyGo. Ingen av dem er et universelt riktig svar. Hvilken som vinner for deg avhenger av hvor mange forespørsler du har, hvor tung koden din er å kjøre, og om du allerede har WebAssembly-kompetanse i teamet.
Hva er Cloudflare Workers og Fastly Compute?
Cloudflare Workers er en serverløs kjøretidsplattform som lar utviklere deployere funksjoner direkte til Cloudflares globale nettverk, uten å administrere servere, containere eller virtuelle maskiner selv. Koden kjører i såkalte V8-isolater, det samme lette sandkasse-oppsettet som driver JavaScript i Chrome-nettleseren, og startes opp på millisekunder fordi det ikke krever en full prosess- eller containeroppstart. Du skriver en funksjon, laster den opp med kommandolinjeverktøyet Wrangler slik vi viste i vår egen oppsettguide for Cloudflare Workers, og Cloudflare distribuerer den automatisk til hele nettverket sitt.
Fastly Compute, tidligere kjent som Compute@Edge, løser samme problem på en annen måte. I stedet for en JavaScript-først isolat-modell kompilerer Fastly koden din til WebAssembly før den kjører på edge-noden. Det betyr at du fra dag én kan skrive i språk som Rust, Go eller JavaScript og få samme kjøretidsmiljø, siden alt uansett ender opp som Wasm-bytekode. Fastly har lenge markedsført denne tilnærmingen som mer sikker og mer forutsigbar i ytelse, fordi Wasm-sandkassen isolerer arbeidslaster strengere enn tradisjonelle prosessmodeller.
Begge plattformene sikter mot samme mål: kjøre applikasjonslogikk så nær sluttbrukeren som mulig for å kutte nettverkslatens, samtidig som infrastrukturen skalerer automatisk uten at du trenger å tenke på servere. Forskjellen ligger i hvordan de kommer dit, og det påvirker alt fra hvilke språk du kan bruke til hvordan regningen din ser ut ved slutten av måneden. Denne dynamikken minner om det vi så da vi sammenlignet Cloudflare Workers mot Azure AKS, der kjøretidsmodellen alene forklarte det meste av kaldstart-forskjellen mellom plattformene, og det samme mønsteret gikk igjen da vi tidligere så på containerbaserte serverløse alternativer som Fargate og Cloud Run.
Begge produktene har eksistert lenge nok til å modnes betydelig. Cloudflare lanserte Workers i 2017 og har siden bygget ut en hel plattform rundt det, med tilleggsprodukter som Workers KV, Durable Objects og D1-database som alle kjører på samme underliggende isolat-teknologi. Fastly lanserte Compute@Edge i 2020 og har senere forenklet navnet til bare Compute, samtidig som selskapet har flyttet stadig mer av sin egen CDN-infrastruktur over til den samme WebAssembly-motoren internt. Begge selskapene har med andre ord bevist at teknologien holder i skala, ikke bare i demo-miljøer.
Arkitektur: V8-isolater mot WebAssembly-sandkasser
Den viktigste tekniske forskjellen mellom de to plattformene handler om hva som faktisk starter opp når en forespørsel kommer inn. Cloudflare Workers bruker V8-isolater, som er lettvektsprosesser inne i samme V8-motor som driver Chrome og Node.js. Fordi mange isolater kan dele samme underliggende V8-instans, slipper Cloudflare å starte en ny prosess eller container for hver kunde, noe som gir svært rask oppstartstid selv for kode som ikke har kjørt nylig.
Fastly Compute går en annen vei og kompilerer applikasjonen din til WebAssembly før deploy. Wasm-modulen kjører deretter i en sandkasse bygget på samme sikkerhetsmodell som nettlesernes Wasm-motorer, men optimalisert for korte, isolerte kjøringer på edge-noder. Fordelen er strengere minneisolasjon mellom kunder og forutsigbar ytelse uavhengig av kildespråk, siden Rust, Go og JavaScript alle ender opp som samme type bytekode før kjøring. Ulempen er at kompileringssteget legger til et ekstra ledd i utviklingsløpet som Cloudflares JavaScript-først modell ikke krever.
I praksis betyr dette at Cloudflare Workers har en lavere terskel for team som allerede jobber mye med JavaScript eller TypeScript, mens Fastly Compute passer bedre for team som ønsker et enhetlig kjøretidsmiljø på tvers av flere programmeringsspråk, eller som har spesifikke krav til minneisolasjon som Wasm-sandkassen dekker godt.
Cloudflare bruker også WebAssembly internt, blant annet for tyngre beregninger og for enkelte tredjepartsspråk, men isolat-modellen forblir hovedveien inn for de aller fleste utviklere som starter et nytt Workers-prosjekt. Fastly har gjort motsatt reise: de startet med et rendyrket Wasm-fokus og har siden bygget stadig bedre JavaScript-støtte oppå det fundamentet, blant annet gjennom komponenter som lar deg kjøre eksisterende Node.js-biblioteker med enkelte tilpasninger. Retningen de to plattformene beveger seg i minner dermed mer om hverandre år for år, selv om utgangspunktet fortsatt er tydelig forskjellig.
Nettverk og rekkevidde: 335 mot 166 lokasjoner
Ifølge Cloudflares egen nettverksside strekker nettverket seg i dag over mer enn 330 byer globalt, og Workers-produktsiden oppgir global utrulling på tvers av over 335 datasentre. Det gjør Cloudflare til den klart mest utbredte av de to plattformene rent geografisk, noe som isolert sett taler for lavere nettverkslatens for brukere spredt over mange land, inkludert Norden.
Fastly oppga under sin 2026-investordag 166 punkter for tilstedeværelse og en total nettverkskapasitet på 622 terabit per sekund, ifølge transkripsjonen fra arrangementet. Det er betydelig færre lokasjoner enn Cloudflare, men Fastly har historisk prioritert færre, kraftigere noder med høy gjennomstrømning fremfor et bredt antall mindre punkter. For arbeidslaster med jevn global trafikkfordeling betyr Cloudflares tallmessige overtak som regel bedre gjennomsnittlig nærhet til sluttbrukeren, mens Fastlys modell kan holde tritt på ytelse i regioner der de faktisk har tilstedeværelse.
For norske og nordiske team betyr dette i praksis at begge plattformene dekker regionen godt nok til produksjonsbruk, siden begge har europeiske knutepunkter tett på Norden. Forskjellen blir mest synlig for globale applikasjoner med brukere i mindre dekkede regioner, der Cloudflares bredere fotavtrykk kan gi et reelt fortrinn i opplevd responstid.
Antall lokasjoner forteller likevel ikke hele historien om nettverkskvalitet. Et nettverk med flere, mindre noder kan i teorien gi kortere geografisk avstand til flere brukere, men dette betyr lite hvis nodene mangler kapasitet til å håndtere trafikktopper uten degradert ytelse. Fastlys fokus på færre, kraftigere noder med 622 Tbps samlet kapasitet er nettopp et forsøk på å konkurrere på gjennomstrømning og stabilitet under press, fremfor ren geografisk spredning. For team som hovedsakelig betjener brukere i Europa og Nord-Amerika, der begge nettverkene har solid tilstedeværelse, er denne forskjellen i strategi mindre avgjørende enn for team med brukere spredt over Afrika, Sør-Amerika eller deler av Asia, der Cloudflares bredere geografiske dekning har en klarere praktisk fordel.
Programmeringsspråk og utvikleropplevelse
Cloudflare Workers er bygget rundt JavaScript og TypeScript som primærspråk, men støtter også WebAssembly og har en egen Python Workers-kjøretid for team som foretrekker det, ifølge Cloudflares offisielle språkdokumentasjon. Andre språk som kompilerer til WebAssembly kan også kjøre, men da innenfor Workers sine egne kjøretidsbegrensninger, ikke som fullverdige førsteklasses språk på linje med JavaScript.
Fastly Compute snur rekkefølgen. Her er WebAssembly selve fundamentet, og de offisielt støttede SDK-ene dekker Rust, JavaScript, samt Go via TinyGo-kompilatoren, i tillegg til AssemblyScript, ifølge Fastlys produktside for Compute. Rust har historisk vært det mest modne alternativet på Fastly, med best verktøystøtte og flest eksempler i offisiell dokumentasjon, mens JavaScript-SDK-en har hentet seg inn de siste årene for team som ønsker Fastlys sikkerhetsmodell uten å bytte hovedspråk.
- Cloudflare Workers: JavaScript, TypeScript, Python Workers, WebAssembly som tilleggsalternativ.
- Fastly Compute: Rust, JavaScript, Go (via TinyGo), AssemblyScript, alt kompilert til WebAssembly.
For team med sterk Rust- eller Go-kompetanse som ønsker maksimal kontroll over minnebruk og ytelse, gir Fastly en mer naturlig inngang. For team som allerede lever i et JavaScript- og TypeScript-økosystem, og som ønsker raskest mulig vei fra kode til produksjon uten et separat kompileringssteg, er Cloudflare Workers som regel raskere å komme i gang med.
Ytelse og kaldstart: hva sier tallene egentlig?
Cloudflare oppgir på sin egen nettverksside at serverløse funksjoner starter opp på under fem millisekunder, noe selskapet knytter direkte til V8-isolat-arkitekturen og at det ikke kreves noen full prosess- eller containeroppstart for hver kunde. Det er et offisielt, vendor-publisert tall, og bør leses som sådan.
Fastly har ikke publisert et like direkte sammenlignbart kaldstart-tall for Compute. En uavhengig 2026-benchmark fra BlazingCDN, som testet 10.000 forespørsler per region på tvers av åtte globale lokasjoner, målte varm P50-latens mellom 6,2 og 21,3 millisekunder og en P99-latens som aldri oversteg 45 millisekunder. De samme målingene fra første kvartal 2026 viste kaldstart-P50 fra 4,7 millisekunder i Frankfurt til 12,6 millisekunder i Johannesburg, ifølge BlazingCDNs sammenligning av Fastly og Cloudflare.
Disse tallene er ikke direkte sammenlignbare uten forbehold, siden de måler ulike ting: Cloudflares tall er et offisielt selskapstall for isolat-oppstart, mens Fastly-tallene er en tredjeparts benchmark av full forespørsel-til-svar-tid inkludert nettverkstransport. Det ærlige svaret er at begge plattformene leverer kaldstart og responstid godt under det brukere merker som treghet, og at den reelle forskjellen i produksjon i stor grad avhenger av hvor tung koden din er, hvor ofte isolaten eller Wasm-modulen din gjenbrukes, og hvilken region trafikken din kommer fra.
For de fleste applikasjoner betyr forskjellen mellom 5 og 25 millisekunder i kaldstart lite i praksis, siden den totale svartiden uansett domineres av selve nettverksreisen mellom bruker og nærmeste edge-node, ikke av oppstartstiden til selve funksjonen. Der kaldstart faktisk merkes, er i arbeidslaster med svært lav trafikk der isolaten eller Wasm-modulen sjelden gjenbrukes, for eksempel en intern verktøytjeneste som kalles noen få ganger i timen. For høyfrekvente API-er som mottar flere forespørsler per sekund holder begge plattformene isolatene eller modulene varme mesteparten av tiden, og kaldstart-forskjellen blir i praksis en ikke-faktor for sluttbrukeropplevelsen.
Spesifikasjoner side ved side
Tabellen under samler de viktigste tekniske og kommersielle egenskapene til begge plattformene, basert på offisiell dokumentasjon fra Cloudflare og Fastly per 28. september 2026.
| Egenskap | Cloudflare Workers | Fastly Compute |
|---|---|---|
| Kjøretidsmodell | V8-isolater | WebAssembly-sandkasse |
| Primærspråk | JavaScript, TypeScript | Rust, JavaScript |
| Øvrige språk | Python Workers, Wasm | Go (TinyGo), AssemblyScript |
| Globalt fotavtrykk | 335+ datasentre / 330+ byer | 166 PoP-er |
| Nettverkskapasitet | Ikke separat oppgitt av Cloudflare | 622 Tbps (investordag 2026) |
| Offisiell kaldstart | Under 5 ms | Ikke offisielt oppgitt |
| Gratis forespørsler/mnd | 100.000/dag (~3 mill./mnd) | 10 millioner |
| Gratis CPU/beregning | 10 ms CPU/kall (gratis), inntil 30 mill. CPU-ms/mnd (betalt) | 100 millioner vCPU-millisekunder/mnd |
| Maks CPU-tid per kall | 5 minutter (standard 30 sek.) | Ikke separat oppgitt i prisdokumentasjon |
| Egress/utgående trafikk | Ingen ekstra kostnad | Fakturert separat via CDN-produkt |
| Laveste betalte plan | 5 USD/mnd | 500 USD/mnd (pakkeløsning) eller ren forbrukspris |
| Prismodell over gratis-nivå | Per forespørsel + per CPU-ms | Per forespørsel + per vCPU-ms |
Legg merke til at Cloudflare bundler nettverkstrafikk inn i Workers-prisen uten ekstra kostnad, mens Fastly Compute i utgangspunktet kun prises for beregning, og fakturerer båndbredde separat gjennom sitt egne CDN-produkt. Det er en strukturell forskjell som fort kan snu et regnestykke på hodet hvis du kun sammenligner de rene compute-prisene uten å ta høyde for dette.
Tabellen viser også at de to plattformene bruker litt ulik terminologi for i bunn og grunn samme ressurs. Det Cloudflare kaller CPU-millisekunder og det Fastly kaller vCPU-millisekunder måler begge hvor mye prosessortid en funksjon faktisk bruker under kjøring, ikke total forespørselstid inkludert venting på nettverk eller eksterne kall. En funksjon som gjør et kall til en ekstern database og venter 200 millisekunder på svar, men bare bruker 5 millisekunder faktisk CPU-tid mens den venter, betales altså for de 5 millisekundene på begge plattformer, ikke de fulle 200. Dette gjør I/O-tunge funksjoner, som API-proxyer eller cache-oppslag, betydelig billigere å kjøre enn CPU-tunge funksjoner som bildebehandling eller komplekse beregninger.
Slik prises Cloudflare Workers i 2026
Gratis-planen
Cloudflares gratis Workers-plan gir deg 100.000 forespørsler per dag, tilsvarende rundt 3 millioner i måneden, ifølge Cloudflares offisielle prisdokumentasjon. Det er ingen kostnad knyttet til kjøretiden i seg selv på gratis-planen, men hver invokasjon er begrenset til 10 millisekunder CPU-tid, noe som er nok til enkle API-kall og redirect-logikk, men for lite til tunge beregninger eller store JSON-transformasjoner.
Betalt plan
Workers Paid-planen starter på 5 dollar i måneden per konto og inkluderer 10 millioner forespørsler i måneden, med et tillegg på 0,30 dollar per ekstra million. CPU-tid faktureres separat fra selve forespørselen: 30 millioner CPU-millisekunder er inkludert per måned, med et tillegg på 0,02 dollar per ekstra million CPU-millisekunder. Det finnes ikke lenger noen fast varighetsbegrensning eller -kostnad per kall på betalt plan, kun et tak på maksimalt fem minutters CPU-tid per invokasjon (standard er 30 sekunder, men kan økes). Viktigst for kostnadsbevisste team: Cloudflare tar ikke betalt for utgående dataoverføring eller båndbredde i det hele tatt på Workers, uansett hvor mye trafikk applikasjonen din genererer.
Den flate prisen på 0,30 dollar per million ekstra forespørsler og 0,02 dollar per million ekstra CPU-millisekunder gjør det også uvanlig enkelt å budsjettere for vekst. Der mange skytjenester bruker fallende tiersystemer som krever at du regner ut hvilket sjikt trafikken din havner i, kan et Cloudflare-team i praksis multiplisere forventet vekst direkte med de samme to satsene uansett hvor stort selskapet blir. Det gjør det enklere å forklare en fremtidig regning for ledelsen enn en tiersbasert modell, selv om selve sluttsummen ikke nødvendigvis alltid er lavest ved svært lav eller svært ujevn trafikk.
Slik prises Fastly Compute i 2026
Fastly oppdaterte prismodellen for Compute med virkning fra 22. september 2026, og den nye strukturen deler kostnaden i to separate målinger: antall forespørsler og vCPU-millisekunder brukt, ifølge Fastlys offisielle prisside. De første 10 millioner forespørslene og de første 100 millioner vCPU-millisekundene per måned er gratis. Over det koster forespørsler 0,50 dollar per million i intervallet 10 til 500 millioner, fallende gradvis til 0,20 dollar per million for volum over 500 milliarder forespørsler i måneden.
vCPU-millisekunder følger en tilsvarende fallende skala: 0,05 dollar per million i intervallet 100 millioner til 5 milliarder, ned til 0,02 dollar per million for de aller største kundene med over 5 billioner vCPU-millisekunder i måneden. Dette compute-gebyret dekker imidlertid kun selve kjøringen. Vil applikasjonen din også levere innhold som bilder, video eller statiske filer via Fastlys CDN, faktureres det som et eget produkt kalt Full Site Delivery, med 100 GB gratis båndbredde i måneden og deretter fra 0,12 dollar per GB i Europa, avhengig av region og volum. For team som utelukkende bruker Compute til API-logikk uten tung CDN-levering, er dette skillet mindre relevant, men for team som bygger fullstack-applikasjoner på Fastly er det en kostnad som lett glemmes i et førsteinntrykk av prislisten.
Fastly tilbyr også ferdigpakkede platformpakker for kunder som ønsker forutsigbar fakturering fremfor ren forbruksprising: en Starter-pakke på 500 dollar i måneden med 500 millioner forespørsler inkludert, og en Starter-pakke på 500 dollar i måneden med 500 millioner forespørsler inkludert. De to øverste nivåene, Advantage og Ultimate, er tilpasset enterprise-kunder med henholdsvis 2 og 5 milliarder forespørsler inkludert, og prises etter individuell avtale med salgsteamet.
Denne pakkemodellen gjør Fastly attraktivt for større organisasjoner som ønsker én fast linje i budsjettet fremfor en variabel regning som svinger med trafikk. En norsk mediebedrift med forutsigbar, jevn trafikk gjennom hele måneden kan for eksempel foretrekke en fast pris på 6.000 dollar fremfor å regne ut nøyaktig forbruk hver måned, selv om den rene forbruksprisen i teorien kunne blitt lavere enkelte måneder. Ulempen er at du betaler for kapasitet du kanskje ikke bruker fullt ut i stille perioder, noe som gjør pakkemodellen mindre gunstig for virksomheter med sterkt sesongbasert eller uforutsigbar trafikk.
Fastlys forbruksbaserte pris faller i flere trinn etter hvert som volumet øker, noe som skiller den fra Cloudflares flate satser. Tabellen under viser hele skalaen for begge måleenhetene på Fastly Compute, slik den er publisert på selskapets offisielle prisside.
| Volumintervall | Pris per million forespørsler | Pris per million vCPU-ms |
|---|---|---|
| 0 – 10 mill. forespørsler / 0 – 100 mill. vCPU-ms | Gratis | Gratis |
| 10 mill. – 500 mill. / 100 mill. – 5 mrd. | 0,50 USD | 0,05 USD |
| 500 mill. – 5 mrd. / 5 – 50 mrd. | 0,49 USD | 0,049 USD |
| 5 – 20 mrd. / 50 – 200 mrd. | 0,48 USD | 0,048 USD |
| 20 – 50 mrd. / 200 – 500 mrd. | 0,45 USD | 0,045 USD |
| 50 – 125 mrd. / 500 mrd. – 1 billion | 0,40 USD | 0,04 USD |
| 125 – 500 mrd. / 1 – 5 billioner | 0,30 USD | 0,03 USD |
| Over 500 mrd. / over 5 billioner | 0,20 USD | 0,02 USD |
Til sammenligning holder Cloudflare Workers seg til to faste satser uansett volum: 0,30 dollar per million ekstra forespørsler og 0,02 dollar per million ekstra CPU-millisekunder, uten noen fallende skala. Det gjør Fastly relativt sett mer konkurransedyktig for de aller største kundene med enorme volum, mens Cloudflare beholder et prisfortrinn for de fleste team i det små til mellomstore sjiktet, altså der størstedelen av norske og nordiske virksomheter befinner seg.
Pristabell og regnestykke: to konkrete arbeidslaster
Tall på et prisark sier lite før du legger dem inn i et faktisk regnestykke. Under har vi regnet ut kostnaden for to typiske arbeidslaster basert utelukkende på de offisielle, publiserte satsene over, uten rabatter eller forhandlede avtaler.
| Arbeidslast | Cloudflare Workers | Fastly Compute (kun beregning) |
|---|---|---|
| 20 mill. forespørsler/mnd, 30 ms CPU/kall (600 mill. CPU-ms totalt) | 19,40 USD/mnd | 30,00 USD/mnd |
| 1 mrd. forespørsler/mnd, 20 ms CPU/kall (20 mrd. CPU-ms totalt) | 701,40 USD/mnd | 1.470,00 USD/mnd |
For den lille arbeidslasten består Cloudflare-summen av 5 dollar i grunnavgift, 3 dollar for 10 ekstra millioner forespørsler utover de inkluderte 10 millionene, og 11,40 dollar for 570 ekstra millioner CPU-millisekunder utover de gratis 30 millionene. Fastly lander på 5 dollar for 10 ekstra millioner forespørsler og 25 dollar for 500 ekstra millioner vCPU-millisekunder utover de gratis 100 millionene, altså 30 dollar totalt, uten at båndbredde er inkludert i det tallet.
For den store arbeidslasten vokser gapet betydelig fordi Fastlys forespørsels- og vCPU-priser først faller til lavere satser ved svært høyt volum, mens Cloudflares 0,30 dollar per million forespørsler og 0,02 dollar per million CPU-millisekunder holder seg flatt gjennom hele dette intervallet. Merk at begge regnestykkene er forenklede modeller basert på jevn trafikkfordeling og bør brukes som utgangspunkt for egen kalkulasjon, ikke som en garantert regning. Faktisk CPU-tid per kall varierer mye avhengig av hva koden din faktisk gjør, og det er alltid lurt å måle egen arbeidslast i en pilot før du legger et budsjett basert på antakelser.
Kodeeksempel: samme funksjon på begge plattformer
For å illustrere den praktiske forskjellen i utvikleropplevelse, her er en enkel HTTP-håndterer som returnerer en JSON-respons, skrevet for begge plattformene. Cloudflare Workers-varianten er ren JavaScript uten noe kompileringssteg:
export default {
async fetch(request) {
const data = { melding: "Hei fra Cloudflare Workers", tid: Date.now() };
return new Response(JSON.stringify(data), {
headers: { "content-type": "application/json" },
});
},
};Fastly Compute-varianten i Rust ser annerledes ut fordi den kompileres til WebAssembly før deploy, men løser nøyaktig samme oppgave:
use fastly::{Error, Request, Response};
#[fastly::main]
fn main(_req: Request) -> Result {
let body = r#"{"melding":"Hei fra Fastly Compute"}"#;
Ok(Response::from_body(body)
.with_content_type(fastly::mime::APPLICATION_JSON))
} Forskjellen i kodestil gjenspeiler arkitekturvalget: Cloudflare-eksempelet kjører direkte som JavaScript uten noe mellomsteg, mens Fastly-eksempelet må kompileres med Rust-verktøykjeden og pakkes som en Wasm-modul før den kan deployes med fastly compute deploy. For team som allerede har Rust i produksjon andre steder, er dette ekstra steget sjelden et problem. For team uten den kompetansen internt, er det en reell ekstra læringskurve sammenlignet med å bare skrive om en eksisterende JavaScript-funksjon til Workers-format.
Fem reelle brukstilfeller: hvilken plattform passer når
I stedet for å lete etter én universell vinner, er det mer nyttig å matche valget mot konkrete scenarioer team faktisk står i. Under er fem situasjoner der valget mellom plattformene som regel gir seg selv, basert på hva som faktisk driver kostnad og kompleksitet i hvert tilfelle.
- A/B-testing og personalisering av nettsider: Cloudflare Workers passer godt her siden du kan skrive enkel JavaScript-logikk som endrer HTML-responsen basert på cookies eller headere, uten separat kompilering, og uten ekstra kostnad for den økte trafikken personalisering ofte medfører.
- Sikkerhetskritiske API-er med strenge isolasjonskrav: Fastly Compute sin WebAssembly-sandkasse gir strengere minneisolasjon mellom kunder på delt infrastruktur, noe som kan være relevant for aktører med høye compliance-krav til multi-tenant-arkitektur.
- Team med eksisterende Rust- eller Go-kodebase: Fastly Compute lar deg gjenbruke forretningslogikk skrevet i disse språkene direkte på edgen, mens Cloudflare i praksis krever en JavaScript- eller TypeScript-vri på tilsvarende logikk.
- Høyvolum-applikasjoner med mye statisk og dynamisk innhold kombinert: Cloudflares nullkostnad på egress gjør det enklere å forutsi totalregningen for applikasjoner som serverer mye data ut til sluttbrukere, siden du slipper å legge et eget CDN-produkt oppå compute-kostnaden.
- Global SaaS med brukere spredt på mange kontinenter: Cloudflares bredere nettverk med over 335 datasentre gir som regel jevnere responstid for brukere i regioner der Fastlys 166 PoP-er har tynnere dekning.
Disse fem scenarioene overlapper i praksis ofte med hverandre. Et fintech-selskap i Oslo kan for eksempel starte med Cloudflare Workers for enkel API-ruting og personalisering, for så å vurdere Fastly Compute for spesifikke, sikkerhetskritiske betalingsflyter der Wasm-sandkassens isolasjonsmodell gir et sterkere compliance-argument overfor revisor eller regulator.
Et sjette, mer teknisk scenario dukker ofte opp i praksis: team som allerede bruker Fastlys CDN til innholdslevering, men som ønsker å legge til dynamisk logikk uten å bytte hele leverandøren. For disse gir Fastly Compute den enkleste veien inn, siden det kjører i samme kontrollpanel og samme fakturering som eksisterende CDN-tjenester. Å legge Cloudflare Workers oppå en eksisterende Fastly-CDN krever i stedet at du enten flytter DNS delvis eller setter opp Workers som et frittstående lag foran eksisterende infrastruktur, noe som øker kompleksiteten uten nødvendigvis å redusere kostnaden nok til å rettferdiggjøre bryet for mindre team.
Fordeler og ulemper
Etter å ha gått gjennom arkitektur, nettverk, priser og reelle brukstilfeller, er det nyttig å samle styrker og svakheter for hver plattform ett sted, slik at du raskt kan sjekke dem opp mot dine egne krav uten å bla gjennom hele artikkelen på nytt.
Cloudflare Workers
- Fordeler: Ingen ekstra kostnad for egress, størst globalt nettverk med over 335 datasentre, rask vei fra JavaScript-kode til produksjon uten kompileringssteg, offisielt kaldstart-tall under 5 ms, lav inngangsterskel på gratis-plan.
- Ulemper: CPU-tid er strengt begrenset på gratis-planen (10 ms per kall), primærspråket er i praksis JavaScript/TypeScript selv om andre språk støttes via Wasm, og prismodellen kombinerer to separate måleenheter (forespørsler og CPU-ms) som krever litt regning for å forstå fullt ut.
Fastly Compute
- Fordeler: Flere modne språkalternativer inkludert Rust og Go, strengere Wasm-sandkasse-isolasjon som kan styrke compliance-argumenter, forutsigbare pakkepriser for enterprise-kunder som ønsker fast månedspris, generøst gratis-nivå på 100 millioner vCPU-millisekunder.
- Ulemper: Mindre globalt nettverk med 166 PoP-er mot Cloudflares 335+, båndbredde og CDN-levering faktureres som separat produkt utenom selve compute-prisen, og kompileringssteget til WebAssembly legger til friksjon for team uten Rust- eller Go-erfaring fra før.
Migreringsguide: bytte fra Fastly Compute til Cloudflare Workers
Mange team som vurderer et bytte gjør det for å kutte egress-kostnader eller for å samle flere Cloudflare-produkter, som R2-lagring og D1-database, under samme faktura. Andre migrerer fordi de allerede bruker Cloudflare til DNS og DDoS-beskyttelse, og ønsker å redusere antall leverandører de må forholde seg til i en hendelsesrespons. Slik ser et typisk migreringsløp ut i praksis.
- Kartlegg all forretningslogikk i eksisterende Fastly Compute-tjenester, inkludert hvilke deler som er skrevet i Rust, Go eller JavaScript, og noter avhengigheter til Fastly-spesifikke biblioteker som KV Store eller Secret Store.
- Skriv om Rust- eller Go-kode til JavaScript eller TypeScript, siden Cloudflare Workers ikke har et tilsvarende modent SDK for disse språkene direkte, med mindre du velger å kjøre eksisterende Wasm-moduler via Workers sin Wasm-støtte.
- Sett opp et nytt Cloudflare-konto med Workers Paid-plan aktivert, og installer kommandolinjeverktøyet Wrangler lokalt for deploy og testing.
- Migrer nøkkelverdi-lagring fra Fastlys KV Store til Cloudflare Workers KV eller til Durable Objects, avhengig av om du trenger sterk konsistens eller ren cache-oppførsel.
- Konfigurer DNS til å peke gradvis mer trafikk mot Cloudflare, for eksempel med vektet ruting, i stedet for en brå full cutover som risikerer å eksponere feil i produksjon for alle brukere samtidig.
- Kjør begge tjenestene parallelt i en observasjonsperiode på minst en til to uker, og sammenlign feilrater, responstid og faktisk regning før du avvikler Fastly-tjenesten helt.
- Oppdater CI/CD-pipeliner til å bruke Wrangler i stedet for Fastlys egen CLI, og fjern eventuelle Rust- eller Go-byggetrinn som ikke lenger trengs etter migreringen.
Den vanligste fellen team går i under en slik migrering er å undervurdere omskrivingsarbeidet når kildekoden opprinnelig er skrevet i Rust eller Go. Selve HTTP-håndteringslogikken er som regel enkel å overføre konseptuelt, men bibliotek, feilhåndtering og typesystem er fundamentalt forskjellig mellom et statisk typet systemspråk og JavaScript, noe som gjør at en migrering sjelden er en ren copy-paste-jobb selv for relativt enkle tjenester.
Sett av god tid til testing av edge-tilfeller rundt request- og response-headere, siden de to plattformene håndterer enkelte HTTP-detaljer som chunked transfer-encoding og streaming-responser på litt ulike måter internt. Et team som hopper rett fra utviklingsmiljø til full produksjonstrafikk uten en gradvis utrulling risikerer å oppdage slike forskjeller først når reelle brukere rammes, noe den vektede DNS-rutingen i steg fem i listen over er ment å forhindre.
Verdikt: hvilken plattform vinner i 2026?
Det finnes ikke ett riktig svar, men tallene peker mot klare anbefalinger avhengig av prioritet. Velger du basert på ren totalkostnad for en typisk API-arbeidslast, vinner Cloudflare Workers tydelig i begge regnestykkene over, hovedsakelig fordi Cloudflare ikke fakturerer egress separat og fordi CPU-prisen holder seg flat gjennom hele skalaen i stedet for Fastlys mer kompliserte tiersystem for compute alene.
Velger du basert på språkfleksibilitet og ønsker Rust eller Go som hovedspråk på edgen, vinner Fastly Compute siden det er bygget for akkurat den arbeidsflyten fra grunnen av. Velger du basert på globalt fotavtrykk alene, vinner Cloudflare med over dobbelt så mange lokasjoner som Fastly, noe som isolert sett gir et fortrinn for applikasjoner med virkelig global brukerbase utenfor Europa og Nord-Amerika.
For de fleste norske og nordiske team uten spesifikke Rust- eller Go-krav er Cloudflare Workers som regel det enkleste og billigste utgangspunktet i 2026, spesielt for team som allerede bruker andre Cloudflare-produkter som R2-lagring. Team med strenge isolasjonskrav, eksisterende Rust-kompetanse eller behov for forutsigbar pakkepris bør likevel teste Fastly Compute grundig før de konkluderer, siden ingen av regnestykkene over erstatter en reell pilottest av egen arbeidslast.
Ser vi fremover mot resten av 2026, er det verdt å følge med på to ting spesielt. For det første hvordan Fastlys nye toparts prismodell for forespørsler og vCPU-tid, innført 22. september 2026, faktisk slår ut for eksisterende kunder over tid, siden en så fersk endring gjerne justeres videre etter tilbakemeldinger fra store kunder det første året. For det andre om Cloudflare velger å utvide Python Workers-støtten til et fullverdig alternativ til JavaScript, siden det kunne gjøre plattformen enda mer attraktiv for team med tung Python-kompetanse fra data- og ML-miljøer, uten at de må lære et nytt språk for å utnytte edge-nettverket fullt ut.
Vanlige feil ved valg av edge-computing-plattform
Den vanligste feilen team gjør er å sammenligne kun forespørselsprisen mellom plattformene uten å regne inn CPU-tid eller vCPU-millisekunder, som ofte utgjør en større del av totalregningen enn selve forespørselskostnaden ved tyngre arbeidslaster. En annen vanlig feil er å glemme at Fastly Compute ikke inkluderer båndbredde i compute-prisen, slik at et tilsynelatende billig regnestykke kan bli dyrere enn forventet så snart applikasjonen også leverer betydelige mengder innhold via CDN-produktet.
Team bør også unngå å anta at kaldstart-tallene fra ulike kilder er direkte sammenlignbare, siden Cloudflares offisielle under-5-millisekunder-tall og Fastlys tredjeparts benchmark-tall måler forskjellige ting under forskjellige forhold. Mål alltid egen arbeidslast i et representativt testmiljø før du legger et endelig valg til grunn for et helt produkt, og ikke basér beslutningen kun på tallene i denne eller andre artikler.
En tredje feil er å velge plattform utelukkende basert på hvilket språk teamet foretrekker uten å regne på faktisk kostnad for arbeidslasten. Et team som elsker Rust, men som egentlig bare trenger enkel API-ruting med lite CPU-bruk, kan fort ende opp med å betale mer i utviklingstid på kompilering og verktøyoppsett enn de sparer i kjøretidskostnader sammenlignet med en enklere JavaScript-løsning på Cloudflare Workers. Språkvalg bør veie tungt når teamet allerede har dyp kompetanse i et bestemt språk, men bør ikke alene avgjøre plattformvalget for et helt nytt prosjekt.
Ofte stilte spørsmål om Cloudflare Workers og Fastly Compute
Kan jeg bruke Rust på Cloudflare Workers?
Ja, via WebAssembly, men det er ikke like modent eller like godt dokumentert som Fastlys Rust-SDK, som er bygget for nettopp dette fra grunnen av. JavaScript og TypeScript er fortsatt de mest naturlige valgene på Cloudflare.
Er Fastly Compute dyrere enn Cloudflare Workers for alle arbeidslaster?
Ikke nødvendigvis, men i begge regnestykkene i denne artikkelen kom Cloudflare Workers billigere ut, hovedsakelig fordi Fastly fakturerer båndbredde separat mens Cloudflare inkluderer egress uten ekstra kostnad. Arbeidslaster med svært lite CPU-bruk per forespørsel kan i teorien vippe regnestykket annerledes.
Hvilken plattform har lavest kaldstart?
Cloudflare oppgir offisielt under 5 millisekunder. Fastly har ikke publisert et direkte sammenlignbart offisielt tall, men uavhengige benchmarks fra 2026 viser kaldstart-tider fra rundt 4,7 til 12,6 millisekunder avhengig av region, som er i samme størrelsesorden.
Kan jeg kjøre begge plattformene samtidig for ulike deler av en applikasjon?
Ja, flere team kjører et hybrid oppsett der Cloudflare Workers håndterer generell API-trafikk og personalisering, mens Fastly Compute brukes for spesifikke, isolasjonskritiske tjenester. Det krever mer driftskompleksitet, men er teknisk fullt mulig siden begge eksponeres som vanlige HTTP-endepunkter.
Hvor mye koster det å teste ut Cloudflare Workers uten å committe til en betalt plan?
Gratis-planen gir deg 100.000 forespørsler per dag helt uten kostnad, noe som er mer enn nok til å teste en prototype eller et sideprosjekt grundig før du eventuelt oppgraderer til Paid-planen for 5 dollar i måneden.
Støtter begge plattformene norske datasentre eller europeisk databehandling?
Begge har europeiske knutepunkter som dekker nordisk trafikk godt, men verken Cloudflare eller Fastly garanterer at all databehandling skjer utelukkende innenfor Norge eller EU/EØS med mindre du eksplisitt konfigurerer regionbegrensninger der det er støttet. Sjekk alltid gjeldende datalokasjonsfunksjoner hos begge leverandører hvis det er et hardt krav for din virksomhet.
Hva skjer med prisen min hvis Fastly endrer satsene igjen etter september 2026?
Fastly har allerede justert Compute-prismodellen én gang i 2026, så det er ikke urimelig å forvente ytterligere justeringer over tid. Følg alltid med på leverandørens egen prisside fremfor å basere langsiktig budsjettering utelukkende på tall fra en artikkel som denne.
Er det vanskelig å migrere fra Cloudflare Workers til Fastly Compute, altså motsatt vei?
Det er som regel mer arbeid enn motsatt retning, siden du da må skrive om JavaScript-logikk til Rust, Go eller et annet Wasm-kompatibelt språk fra bunnen av, i stedet for å gjenbruke eksisterende JavaScript direkte. Planlegg ekstra tid til dette hvis den migreringsretningen er aktuell for deg.
Trenger jeg et eget CDN-produkt i tillegg til Cloudflare Workers eller Fastly Compute?
Cloudflare Workers kjører på samme nettverk som selskapets CDN, så du trenger ikke et separat produkt for grunnleggende innholdslevering. Fastly Compute er i utgangspunktet et rendyrket beregningsprodukt, og de fleste team som også trenger tradisjonell CDN-levering av statisk innhold, kombinerer det med Fastlys Full Site Delivery-produkt, som faktureres separat.
Hvor lang tid tar det å komme fra null til en produksjonsklar tjeneste på hver plattform?
Med Cloudflare Workers og Wrangler kan en enkel JavaScript-tjeneste være live i produksjon på under en time for et team med grunnleggende erfaring. Fastly Compute tar som regel noe lengre tid for nye team, siden kompilering til WebAssembly og oppsett av Rust- eller Go-verktøykjeden legger til et par ekstra steg før første deploy.
