Cloudflare Workers: Isolates, bindings og Edge-drift

Cloudflare Workers er en hendelsesdrevet databehandlingsplattform i Cloudflare-nettverket. En Worker kan besvare eller videresende HTTP-forespørsler, kjøre planlagte oppgaver, konsumere kømeldinger, behandle innkommende e-post og fungere som en intern tjeneste for andre Workers. Operatøren administrerer verken en lytteprosess eller en enkelt VM. Operatøren administrerer kode, entrypoints, ruter, kjøretidskompatibilitet, tillatelser til plattformressurser, versjoner og driftsdata.

Ordet «Edge» beskriver bare ett mulig kjøringssted, ikke hele arkitekturen. En HTTP-Worker kan kjøre nær brukeren; Smart Placement kan flytte databehandling nærmere et backend-system; Durable Objects har et entydig tilstandshjemsted; D1, KV, R2 og Queues har hver sine replikerings- og konsistensmodeller. For administratorer er derfor ikke «serverløs» den avgjørende egenskapen, men oppdelingen i dataplan, control plane, tilstandstjenester og mulige feilpunkter.

Forklaringen følger en forespørsel fra det offentlige endepunktet inn i Workers-kjøretiden og videre til bindings, lagring og upstreams. Deretter settes utrulling, sikkerhet, observerbarhet og gjenoppretting inn i plattformdriftens perspektiv.

Arkitektur: dataplan, kjøretid og control plane

Et Workers-system består av flere lag:

1. Ingress og ruting: Cloudflare mottar en forespørsel via DNS, TLS og HTTP og tilordner vertsnavn- eller banemønsteret til en Worker eller en statisk ressurs.
2. Hendelsesdistribusjon: Plattformen oppretter en Fetch-, Scheduled-, Queue-, e-post-, Alarm- eller Tail-hendelse og kaller det aktuelle entrypointet.
3. Kjøretid: workerd leverer V8-isolater, web-API-er, Node.js-kompatibilitet og kjøretidsgrenser.
4. Bindings: env-objektet gir koden capabilities for KV, D1, R2, Durable Objects, Queues, secrets, assets, andre Workers og ytterligere plattformtjenester.
5. Tilstand og upstreams: Data ligger utenfor det flyktige isolatet eller i kontrollerte Durable Object-lagre; utgående kall bruker Fetch, Service Bindings eller støttede socket-API-er.
6. Control plane: Wrangler, Dashboard og API administrerer konfigurasjon, ressursrelasjoner, secrets, versjoner, utrullinger og observerbarhet.

Cloudflare beskriver isolater, forespørselsrelatert databehandlingstid og distribuert kjøring som de tre viktigste forskjellene fra klassiske serverkjøretider (How Workers works). Plattformreferansen skiller selve Workeren fra tilknyttede storage- og Developer Platform-produkter (Cloudflare Workers documentation).

Forespørselsbane og kjøringssted

Ved en HTTP-forespørsel avgjør Cloudflare-konfigurasjonen først om et workers.dev-vertsnavn, en rute eller et Custom Domain utløser Workeren. En rute ligger foran en eksisterende origin og kan endre, besvare eller videresende forespørsler. Et Custom Domain kobler en Worker direkte til et vertsnavn. Statiske assets kan evalueres før eller etter Workeren; run_worker_first endrer denne rekkefølgen (Wrangler configuration – routes, Static Assets – configuration and bindings).

Den eksterne banen kan modelleres som Client → DNS → Cloudflare Edge → TLS/HTTP → Route → Worker/Asset → Binding oder Origin. Forbindelsen til origin er en ny transportkontekst. Klientsertifikat, Authorization-header, cache-nøkkel, Host-header og kilde-IP må derfor håndteres bevisst ved hver grense. En Service Binding omgår derimot offentlig navneoppløsning og gir en eksplisitt autorisert Worker-til-Worker-bane (Service bindings).

Smart Placement kan kjøre en Worker nærmere backend-systemene i stedet for å prioritere nærhet til brukeren alene. Dette er nyttig ved databaseintensive kall, men kan forlenge feil vei for assets eller rene Edge-transformasjoner. Cloudflare dokumenterer derfor ulike anbefalinger for Assets-first og Worker-first (Placement).

workerd og V8-isolater

workerd er den serverorienterte JavaScript-/WebAssembly-kjøretiden bak Workers. V8 tilbyr isolater som separate kjøringskontekster. Mange isolater kan dele én prosess uten at hver applikasjon trenger sin egen JavaScript-prosess eller container. Web-API-er leveres i stor grad direkte av kjøretiden (Introducing workerd, Workers security model).

Et isolat er ikke en persistent maskin. Det kan gjenbrukes, håndtere flere forespørsler parallelt eller fjernes. To påfølgende forespørsler trenger ikke treffe samme instans eller sted. Globale objekter egner seg for uforanderlige, kostbare hjelpestrukturer eller opportunistiske cacher, men ikke som sannhetskilde. All korrekthet som avhenger av en global variabel mellom forespørsler, er en arkitekturfeil.

V8-isolasjon erstatter ikke alle sikkerhetskontroller. Cloudflare supplerer med kjøretids- og prosessbeskyttelse, ressursgrenser og spesifikt Spectre-forsvar. Operatøren er fortsatt ansvarlig for inputvalidering, autorisering, secret-scope, måltillatlister, utgangsgrenser og dataklassifisering. Isolatgrensen beskytter ikke mot en applikasjon som leser eller skriver feil data med sine legitime bindings.

Hendelsesmodell og handlere

Workers implementerer entrypoints for ulike hendelsestyper. Den generelle handlerkatalogen omfatter Fetch, Scheduled, Queue, e-post, Alarm og Tail (Handlers).

Fetch-handleren mottar Request, env og ctx og leverer en web-API-Response (Fetch handler). ctx.waitUntil() registrerer arbeid som kan fortsette etter at responsen er sendt; det er fortsatt bundet til dokumenterte kjøretids- og feilgrenser og er ikke en langvarig jobbserver (Context – waitUntil). For varige, repeterbare prosesser er Queues eller Workflows bedre egnet enn en kjede av uovervåkede bakgrunns-Promises.

export interface Env {
  UPSTREAM: Fetcher;
  RELEASE: string;
}
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
const started = Date.now();
const response = await env.UPSTREAM.fetch(request);
ctx.waitUntil(Promise.resolve().then(() =>
console.log(JSON.stringify({ release: env.RELEASE, status: response.status, ms: Date.now() - started }))
));
return response;
},
} satisfies ExportedHandler<Env>;

export interface Env {
  UPSTREAM: Fetcher;
  RELEASE: string;
}
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
const started = Date.now();
const response = await env.UPSTREAM.fetch(request);
ctx.waitUntil(Promise.resolve().then(() =>
console.log(JSON.stringify({ release: env.RELEASE, status: response.status, ms: Date.now() - started }))
));
return response;
},
} satisfies ExportedHandler<Env>;

Eksemplet bruker en Service Binding i stedet for en fritt konfigurerbar URL. Dermed flyttes tilgjengelighet og autorisering til utrullingskonfigurasjonen, mens koden bare ser en Fetcher-capability. Kjøretids-API-ene er weborienterte og omfatter blant annet Fetch, Streams, Web Crypto, WebSockets, HTMLRewriter og TCP Sockets (Runtime APIs).

Koden kjører ikke i et fritt valgt lokalt Node-miljø, men mot en versjonert kjøretidskontrakt. Compatibility Date bestemmer hvilke atferdsendringer som gjelder for en utrulling.

Compatibility Date og kjøretidskontrakt

En Compatibility Date er ikke en release-merknad og ikke en uttalelse om artikkelens «nåværende status». Den er en del av kjøretidskontrakten for en konkret Worker-utplassering. Endringer som kan bryte eksisterende atferd, aktiveres etter dato eller flagg. En eldre dato fastholder kompatibel atferd; en nyere dato må testes og rulles ut som en avhengighetsoppdatering (Compatibility flags).

Administratorer behandler derfor disse feltene samlet:

• Kodecommit og buntet artefakt;
• Compatibility Date og eksplisitte flagg;
• Wrangler- og byggeverktøykjede;
• Bindingdefinisjoner, routes og placement;
• Versjons-ID og utrullingsvekt;
• Data- eller Durable Object-migreringer.

Node.js-kompatibilitet er opt-in og implementerer bare en dokumentert del av Node-API-ene. Enkelte moduler er fullstendige, andre delvise eller bare tilgjengelige som import-stubber. nodejs_compat må derfor ikke likestilles med «fullstendig Node-kjøretid» (Node.js compatibility).

Språk og teknologistack

Cloudflare dokumenterer JavaScript, TypeScript, Python og Rust som førsteklasses språkbaner; WebAssembly åpner for flere kildespråk (Languages). Den resulterende teknologistacken skiller utvikling og kjøring:

Rust integreres via workers-rs og WebAssembly; den importerte Wasm-modulen forblir del av Worker-artefaktet (Rust language support). Python Workers bruker egne entrypoint-klasser og en kjøretidsintegrasjon, ikke en fritt administrerbar CPython-prosess.

Konfigurasjon og Wrangler

Wrangler-konfigurasjonen er den deklarative koblingen mellom kode og plattform. Den definerer minst navn, entrypoint, Compatibility Date, routes og bindings. Navngitte miljøer kan ha avvikende verdier; bindings må kontrolleres bevisst per miljø. Cloudflare dokumenterer feltene og arv i Wrangler-skjemaet (Workers configuration, Wrangler configuration reference).

npx wrangler whoami
npx wrangler types
npx wrangler deploy --dry-run
npx wrangler deployments status

npx wrangler whoami
npx wrangler types
npx wrangler deploy --dry-run
npx wrangler deployments status

npx starter prosjektets lokalt låste CLI; Wrangler Commands dokumenterer autentisering, typegenerering, utrulling, versjons- og loggkommandoer. wrangler types genererer typer fra den faktiske bindingkonfigurasjonen. deploy --dry-run kontrollerer bundle og konfigurasjon, men gir ikke bevis for fungerende fjernressurser eller korrekt autorisering.

Etter at kjøretid og bygg er avklart, oppstår tilgangsspørsmålet. En Worker når databaser, køer, secrets og andre Workers via deklarerte bindings i stedet for fritt distribuerte tilgangsdata.

Bindings som capability-modell

En binding er samtidig tillatelse og kjøretids-API. Workeren mottar for eksempel env.ARCHIVE som R2-bucket, env.DB som D1-database eller env.AUTH som intern tjeneste. Den underliggende plattformlegitimasjonen eksponeres ikke for applikasjonskoden som en gjenbrukbar API-nøkkel (Bindings).

Capability-modellen flytter det sentrale administratorspørsmålet fra «Hvilket secret ligger i miljøvariabelen?» til «Hvilken ressurs er bundet under hvilket navn i hvilket miljø til hvilken versjon?». En feil bucket-ID eller Service Binding-versjon kan føre til datatap eller tilgang på tvers av miljøer til tross for identisk kode.

Bindings bør være adskilt etter oppgave og miljø. Produksjons- og test-Workers deler ikke skrivbare buckets, køer eller databaser, med mindre dette uttrykkelig inngår i en kontrollert integrasjonstest. Generiske navn som DB er tilstrekkelige i koden når utrullingen binder den faktiske ressursen entydig og verifiserbart.

Secrets og variabler

Vanlige variabler er konfigurasjon, ikke hemmeligheter. Secrets er krypterte tekstbindings og administreres utenfor kildekoden. Nødvendige secret-navn kan deklareres uten at verdiene skrives i konfigurasjonsfilen (Environment variables, Secrets).

Et secret-bytte er en tilstandsendring i applikasjonen. Klienter som globalt avledes fra env kan beholde en gammel verdi i gjenbrukte isolater; Cloudflare anbefaler å opprette slike avledninger per forespørsel. Rotasjon omfatter derfor setting, kontroll av utrulling/binding, parallell gyldighet dersom målsystemet krever det, telemetri og kontrollert fjerning.

Service Bindings og Worker-til-Worker-arkitektur

Service Bindings kobler Workers eksplisitt uten behov for et offentlig adresserbart HTTP-endepunkt. Den kalte tjenesten kan eksponeres via Fetch eller RPC. Dette reduserer nettverks- og credentialkonfigurasjon, men eliminerer ikke versjons- og kontraktsproblemer. Ved separate utrullinger kan caller og callee bruke ulike API-versjoner (Service bindings, Gradual deployments).

Administratorer dokumenterer per binding:

• Caller og måltjeneste;
• Miljø og målversjon eller utrullingsstrategi;
• Offentlig tilgjengelighet for mål-Workeren;
• Semantikk for timeout, feil og retry;
• Videreføring av request-ID og trace-korrelasjon;
• Kontraktskompatibilitet ved uavhengige utrullinger.

En kjede av mange Workers fordeler en forespørsel over flere mulige feilpunkter. Mindre offentlig angrepsflate er verdifullt; for fin oppdeling kan til gjengjeld øke subrequest-dybde, feilsøkingsarbeid og versionsskew.

Tilstandstjenester: modell før produktnavn

Isolat-heapen er flyktig. Persistent tilstand ligger i bundne tjenester med tydelig forskjellig semantikk. Cloudflares storage-oversikt kategoriserer produktene etter tilgangsmønster og konsistens (Choosing a data or storage product).

Cache API

Cache API arbeider lokalt i datasenteret der Workeren behandler forespørselen. cache.put() er derfor ikke global replikering og ikke en persistent databaseskriving. caches.default deler standard cache-kontekst; navngitte cacher oppretter namespaces, men heller ingen global konsistens (How the Cache works).

Personaliserte svar må bare caches med en nøkkel som avbilder alle relevante identitets- og variantkjennetegn. Authorization, cookies, språk, encoding og tenanttilhørighet er typiske lekkasjegrenser. Cache-purge og originvalidering hører til recovery, ikke bare TTL-er.

Workers KV

KV replikerer data via sentrale stores og Edge-cacher. Endringer kan bli synlige forsinket på andre steder; også «ikke funnet» kan caches. Cloudflare oppgir forsinkelser på opptil 60 sekunder eller mer for fjerne steder og anbefaler ikke KV for atomiske read-modify-write-transaksjoner (How KV works).

KV egner seg for hovedsakelig lest konfigurasjon, allow-/deny-lister eller cacher når staleness tolereres eksplisitt. Globale rate limits, entydige sekvenser eller umiddelbar tilbakekalling av credentials hører ikke hjemme i KV uten ekstra koordinering.

Durable Objects

Et Durable Object kombinerer en globalt entydig objekt-ID med seriell koordinering og privat lagring. Forespørsler for samme ID rutes til samme logiske instans. Nye namespaces bruker SQLite-storagebanen; denne tilbyr transaksjonell, sterkt konsistent lagring og Point-in-Time-Recovery-funksjoner (Durable Objects overview, SQLite-backed Durable Object Storage).

Et Durable Object er heller ikke en kontinuerlig kjørende server. In-memory-tilstand kan forsvinne ved hibernation eller eviction og må om nødvendig rekonstrueres fra storage. Det finnes ingen pålitelig shutdown hook (Durable Object lifecycle). Endringer i klasser og storage-tilordning er livssyklusoperasjoner; de behandles som datamigreringer (Durable Object class lifecycle).

D1, R2 og Queues

D1 tilbyr SQL for relasjonelle data. R2 lagrer store ustrukturerte objekter og eksponerer et S3-kompatibelt API utenfor, og et Binding-API innenfor Workers. Queues frakobler producer og consumer. Disse tjenestene erstatter ikke hverandre: Et R2-objekt kan bære payloaden, D1 indeksen, en kø kan utløse behandlingen og et Durable Object kan koordinere konkurrerende endringer.

Den felles committen av disse fire tilstandene er ikke automatisk atomisk. Administratorer planlegger idempotency keys, Outbox-/Inbox-mønstre, reconciliation og dead-letter-behandling. Produktdokumentasjon og grenser for de enkelte tjenestene for D1, R2 og Queues er del av runbooken.

Statiske assets og full-stack-Workers

En Worker kan levere statiske assets sammen med kode. Assets Binding lar koden hente en asset eksplisitt. Rutingalternativet bestemmer om eksisterende assets omgår Workeren, eller om Workeren kjører først (Static Assets).

Rekkefølgen er en sikkerhetsbeslutning. Ved assets-first må en tilfeldig eksisterende filbane ikke kunne omgå autentisering. Ved Worker-first øker hver asset-forespørsel databehandlings- og avhengighetsbelastningen. Rammeverksadaptere skjuler delvis denne rekkefølgen; det bygde utrullingsartefaktet og Wrangler-konfigurasjonen er fortsatt den autoritative sannheten.

Nettverks- og protokollperspektiv

Workers ligger i applikasjonsbanen over DNS, TLS og HTTP. Plattformen terminerer den eksterne transporten; Workeren behandler web-API-forespørsler. Utgående fetch() oppretter et nytt HTTP-kall. TCP Sockets tillater utvalgte utgående protokoller, men gjør ikke Workeren om til en generelt tilgjengelig TCP-server (Workers protocols, TCP sockets).

For meldingsadministratorer er tre grenser viktige:

• En e-posthandler utløses av Cloudflare Email Routing; den lytter ikke selv på SMTP.
• En Worker som kaller et e-post-API, må behandle OAuth-audience, tokenlivssyklus og retries som enhver annen API-klient.
• DNS-, TLS- og HTTP-feil oppstår før entrypointet; binding-, auth- og applikasjonsfeil etterpå. En fetch()-timeout sier uten korrelasjon ikke hvilken fase som feilet.

Sikkerhets- og tillitsgrenser

Sikkerhetsmodellen har minst fem separate tillitsgrenser:

1. Offentlig forespørsel: vilkårlige headere, body-størrelse, metode og identitet.
2. Cloudflare-konfigurasjon: zone, route, WAF, Access, sertifikater og fail-open/closed.
3. Worker-artefakt: kode, avhengigheter, Source Maps, Compatibility Date og forsyningskjede.
4. Bindings: konkrete ressurstillatelser, secrets og interne tjenestebaner.
5. Upstreams og lagrede data: egen autorisering, konsistens og recovery.

Least Privilege oppnås primært gjennom små bindingflater og separate miljøer. En Worker med skrivetilgang til alle buckets og databaser forblir en høyt privilegert principal, selv om den ikke har synlige tilgangsnøkler. Workers-sikkerhetsdokumentasjonen forklarer kjøretidsisolasjon; den erstatter ikke en applikasjonssikkerhetsarkitektur (Security model).

Kontroller for forsyningskjeden omfatter låste pakkeversjoner, lockfile, reproduserbart bygg, dependency-scanning, secret-scanning, minimale opplastingsrettigheter og beskyttede utrullingsmiljøer. Det genererte bundle-et kontrolleres før opplasting; kun gjennomgang av kildekode er ikke tilstrekkelig når bundlere eller rammeverk bygger inn ekstra moduler.

Nærhet til Edge opphever ikke ressursbegrensninger. CPU-tid, subrequests, minne og plattformgrenser må allerede tas med i design og lastmodell.

Grenser som arkitekturparametere

Workers begrenser blant annet CPU-tid, minne, oppstartstid, subrequests, bundle-størrelse, loggvolum, antall ruter og statiske assets. Verdier varierer etter plan og invocationtype og kan endres. Derfor hører ingen kopiert grenseoversikt hjemme i en statisk artikkel som påstått tidløs sannhet; den offisielle siden Workers Limits er driftskilden.

Administratorer skiller mellom:

• CPU Time: aktiv databehandlingstid; venting på I/O teller ikke på samme måte som CPU.
• Wall Time: hendelsens forløpte varighet; regler skiller mellom Fetch, Cron, Queue og Durable Object.
• Startup Time: modulevaluering og initialisering før handleren.
• Subrequests: Fetch- og plattformoperasjoner per invocation.
• Memory: heap, streams, buffere og bibliotekstilstand i isolatet.
• Log Budget: for store eller hemmelige payloads er både et kostnads- og personvernproblem.

En feil 1102 peker på overskredne ressursgrenser; 10021 kan oppstå ved for kostbar oppstartsinitialisering. Feilnummeret er et startpunkt, ikke root cause. CPU-profil, invocationtype, versjon, inputklasse og subrequest-graf må vurderes samlet.

Lokal utvikling og testing

Lokal utvikling kjører kode med workerd via Miniflare. Bindings simuleres lokalt som standard; enkelte remote bindings kan målrettet kobles til ekte plattformressurser. Fullstendig eksternt kjørt wrangler dev --remote er fortsatt tilgjengelig for nettverksspesifikke tilfeller, men er ikke lenger standardbanen (Local development, Bindings per development mode).

npx wrangler dev --local
$response = Invoke-WebRequest 'http://127.0.0.1:8787/health'
$response.StatusCode
$response.Headers['content-type']
npx vitest run

npx wrangler dev --local
curl --silent --show-error --fail --dump-header - http://127.0.0.1:8787/health
npx vitest run

Invoke-WebRequest og curl kontrollerer status og headere for den lokale HTTP-banen. Workers-Vitest-integrasjonen kjører tester innenfor workerd og leverer hjelpere for bindings, forespørsler og Durable Objects (Vitest integration, Workers test APIs).

En grønn unit test beviser ikke korrekt route, remote-tillatelse eller datamigrering. Testpyramiden omfatter ren logikk, kjøretidsintegrasjon, bindingsemantikk, stagingrute, kontrollert Production-smoke-test og recoveryøvelse.

Utrulling, versjon og rollout

En versjon er et uforanderlig kode-/konfigurasjonsobjekt. En utrulling fordeler trafikk på én eller flere versjoner. Gradual Deployments forskyver vekter trinnvis og gjør det mulig å observere og gå tilbake til en stabil versjon (Versions and deployments, Gradual deployments).

npx wrangler versions list
npx wrangler deployments status
npx wrangler tail --format json
npx wrangler check startup

npx wrangler versions list
npx wrangler deployments status
npx wrangler tail --format json
npx wrangler check startup

Før en rollout lagres tilordningen Git commit → Bundlehash → Worker-Version → Deploymentgewicht. Ved flere Service Bindings er versionsskew del av testen. Durable Objects krever spesielle migrerings- og rolloutregler fordi vilkårlige klassestadier ikke kan være aktive samtidig for en objekt-ID.

Rollback tilbakefører kode og konfigurasjon, men ikke automatisk eksterne data. En ny Worker kan ha skrevet data i et format som den gamle ikke forstår. Skjemaendringer bruker Expand/Contract, fremoverkompatibilitet eller separat testet datatilbakeføring. «Rollback mulig» er først dokumentert når kode-, binding- og datasiden er kontrollert sammen.

Observerbarhet og driftsbevis

Workers Logs samler invocation-logger, egne logger, feil og ubehandlede exceptions. Tail Workers eller Logpush kan eksportere hendelser; OpenTelemetry-mål tilbyr en mer direkte eksportbane for logger og spor (Workers Logs, Tail Workers, Traces).

Hver invocation bør minst gjøre følgende korrelerbart:

• Worker-navn, versjons-ID og miljø;
• Hendelsestype og route;
• Request-/Message-/Correlation-ID;
• Resultat, HTTP-status eller Ack/Retry;
• CPU- og Wall Time;
• Subrequest-mål og latens uten secrets;
• Binding-/ressursklasse, ikke sensitivt fullinnhold;
• Faglig idempotency key ved asynkron behandling.

console.log() er ikke et ubegrenset bevisarkiv. Logggrenser, sampling og redaction påvirker synligheten. Credentials, Authorization-headere, cookies, fullstendige e-postinnhold og personrelaterte payloads logges ikke. Overvåking overvåker også eksportbanen: En feilende Tail Worker må ikke gjøre diagnose av producer-feilen umulig.

Diagnosen følger publiseringsveien: route og DNS, aktiv versjon, kjøretid og bindings, utgående avhengigheter og til slutt logger og spor.

Admin-diagnose etter faser

Workers-feil skilles effektivt langs utførelsesbanen:

1. DNS: Løser forventet host til Cloudflare, og er sonen aktiv?
2. TLS/HTTP: Kontroller sertifikat, SNI, protokoll og status.
3. Route/Asset: Treffer host/path Workeren, en asset eller origin?
4. Versjon: Hvilken versjon og hvilken utrullingsvekt behandlet forespørselen?
5. Kjøretid: Kontroller startup, CPU, memory, exception og handlerutfall.
6. Binding: Finnes ressursen i dette miljøet, og har den forventet capability?
7. Upstream/Storage: Undersøk timeout, auth, konsistens, datatilstand og retry.
8. Recovery: Bekreft stabil versjon, datakompatibilitet og reconciliation.

Resolve-DnsName $env:WORKER_HOST
Test-NetConnection $env:WORKER_HOST -Port 443
$r = Invoke-WebRequest "https://$env:WORKER_HOST/health" -Headers @{ 'x-correlation-id' = [guid]::NewGuid() }
$r.StatusCode
$r.Headers
npx wrangler deployments status

dig +short "$WORKER_HOST"
nc -vz "$WORKER_HOST" 443
openssl s_client -connect "$WORKER_HOST:443" -servername "$WORKER_HOST" -brief </dev/null
curl --silent --show-error --fail --dump-header - "https://$WORKER_HOST/health"
npx wrangler deployments status

Resolve-DnsName, Test-NetConnection, dig, nc, openssl s_client og curl skiller DNS, TCP, TLS og HTTP før kjøretiden. DNS, TCP, TLS, APIs og Troubleshooting behandler disse lagene i dybden.

Typiske feilbilder

Backup og disaster recovery

Serverløshet eliminerer ikke backup. Den flytter objektene som må beskyttes:

• Git-repositorium, lockfile og reproduserbar byggdefinisjon;
• Wrangler-konfigurasjon, routes, Compatibility Date og flagg;
• Inventar over alle bindings og målressurser;
• Secret-verdier eller deres eksterne source of truth og rotasjonsprosess;
• Dataeksporter og restore-prosedyrer for D1, R2, KV og eksterne systemer;
• Durable Object-klasser, lifecycle-/migreringsstatus og eventuelt PITR;
• Queue-/DLQ-tilstand, idempotency keys og reconciliation;
• Versjons-/utrullingshistorikk samt en testet rollback-bane.

Ikke alle produkter har samme eksport- og restore-semantikk. En R2-objektbackup beskytter ikke D1-indeksen; en D1-restore gjenoppretter ikke en allerede bekreftet kømelding; en tilbakeført Worker kan tolke nye objektformater feil. Backup og disaster recovery må derfor definere et konsistent applikasjonspunkt i stedet for bare enkeltstående produktkopier.

Recovery testes i scenarier: feil secret, slettet route, feil versjon, inkompatibelt D1-skjema, tapt R2-objekt, poison Queue Message, feil Durable Object-klasse og utilgjengelig upstream. RTO og RPO fastsettes per tilstandstjeneste og for den sammensatte applikasjonen.

Teknisk historie

Cloudflare presenterte Workers i 2017 som programmerbar kjøring i det globale nettet. Utgangspunktet var latenstidsgrensen til sentrale datasentre og ideen om å kjøre kode nær databanen (Code Everywhere: Why We Built Cloudflare Workers).

Arkitekturen satset tidlig på V8-isolater i stedet for en container eller prosess per funksjon. Cloudflare beskrev i 2018 de økonomiske og tekniske forskjellene i denne modellen, men også begrensningen til JavaScript- eller WebAssembly-egnede språk (Cloud Computing without Containers).

Workers KV la til globalt lesbar, eventually consistent tilstand. Durable Objects ble annonsert i 2020 som en motmodell for koordinert, sterkt konsistent objekttilstand (Introducing Workers Durable Objects). Dermed utviklet Workers seg fra ren forespørselstransformasjon til en applikasjonsplattform med flere eksplisitte konsistensmodeller.

I 2022 publiserte Cloudflare workerd under Apache 2.0. Den åpne kjøretiden deler kode med produksjonssystemet og forbedret nøyaktigheten i lokal utvikling; den er likevel ikke hele Cloudflare-plattformen med dens ruting, orkestrering og sikkerhetsdrift (Introducing workerd, workerd repository).

Senere utvidelser førte til ES-modul-entrypoints, Compatibility Dates, Service/RPC-bindings, D1, R2, Queues, Workflows, Python, utvidet Node-kompatibilitet, versjonsobjekter og trinnvise utrullinger. Denne historien forklarer dagens kjerne: Workers er verken nettleser-JavaScript på et CDN eller en vilkårlig Linux-server, men en hendelsesdrevet, capability-basert kjøretid med separate dataplan- og control plane-produkter.

Admin-sjekkliste

Før produksjonsdrift er minst følgende punkter dokumentert:

• Route, Custom Domain, asset-rekkefølge og fail-open/closed er dokumentert.
• Compatibility Date, flagg, Wrangler-versjon, bundle og Source Maps er reproduserbare.
• Hver binding har owner, miljø, ressurs-ID, rettigheter og recovery-bane.
• Cache-, KV-, D1-, R2-, Durable Object- og Queue-semantikk blandes ikke.
• Secrets er utenfor repositoriet, kan roteres og er ikke synlige i logger.
• Timeouts, retries, idempotens og dead-letter-atferd er definert per hendelsestype.
• Logger og spor inneholder versjon og Correlation-ID, men ingen sensitive payloads.
• Gradual Deployment og rollback tar hensyn til Service Binding-versjoner og dataformater.
• Grenser overvåkes fra den offisielle plattformsiden, ikke fra en kopiert tabell.
• Backup, restore og reconciliation er testet for den sammensatte applikasjonen.

Kilder

• How Workers works
• Cloudflare Workers documentation
• Wrangler configuration reference
• Static Assets – configuration and bindings
• Service bindings
• Placement
• Introducing workerd
• Workers security model
• Handlers
• Fetch handler
• Context – waitUntil
• Runtime APIs
• Compatibility flags
• Node.js compatibility
• Languages
• Rust language support
• Workers configuration
• npx documentation
• Wrangler Commands
• Bindings
• Environment variables
• Secrets
• Gradual deployments
• Choosing a data or storage product
• How the Cache works
• How KV works
• Durable Objects overview
• SQLite-backed Durable Object Storage
• Durable Object lifecycle
• Durable Object class lifecycle
• D1
• R2
• Queues
• Static Assets
• Workers protocols
• TCP sockets
• Workers Limits
• Local development
• Bindings per development mode
• Invoke-WebRequest
• curl manual
• Vitest integration
• Workers test APIs
• Versions and deployments
• Workers Logs
• Tail Workers
• Traces
• Resolve-DnsName
• Test-NetConnection
• dig manual
• nc(1)
• openssl-s_client(1)
• Code Everywhere: Why We Built Cloudflare Workers
• Cloud Computing without Containers
• Introducing Workers Durable Objects
• workerd repository