Cloudflare Workers: Isolates, Bindings und Edge-Betrieb

Cloudflare Workers ist eine ereignisgesteuerte Compute-Plattform innerhalb des Cloudflare-Netzes. Ein Worker kann HTTP-Anfragen beantworten oder weiterleiten, geplante Aufgaben ausführen, Queue-Nachrichten konsumieren, eingehende E-Mails verarbeiten und als interner Service für andere Worker dienen. Der Betreiber verwaltet dabei keinen Listenerprozess und keine einzelne VM. Er verwaltet Code, Entrypoints, Routen, Runtimekompatibilität, Berechtigungen zu Plattformressourcen, Versionen und Betriebsdaten.

Das Wort «Edge» beschreibt nur einen möglichen Ausführungsort, nicht die vollständige Architektur. Ein HTTP-Worker kann nahe beim Benutzer laufen; Smart Placement kann Compute näher an ein Backend verlagern; Durable Objects besitzen eine eindeutige Zustandsheimat; D1, KV, R2 und Queues haben jeweils eigene Replikations- und Konsistenzmodelle. Für Admins ist deshalb nicht «serverlos» die entscheidende Eigenschaft, sondern die Aufteilung von Datenpfad, Control Plane, Zustandsdiensten und möglichen Ausfallstellen.

Die Erklärung folgt einem Request vom öffentlichen Endpunkt in die Workers-Laufzeit und weiter zu Bindings, Speicher und Upstreams. Danach werden Deployment, Sicherheit, Beobachtbarkeit und Wiederherstellung aus Sicht des Plattformbetriebs eingeordnet.

Architektur: Datenpfad, Laufzeit und Control Plane

Ein Workers-System besteht aus mehreren Ebenen:

1. Ingress und Routing: Cloudflare nimmt eine Anfrage über DNS, TLS und HTTP entgegen und ordnet Host beziehungsweise Pfadmuster einem Worker oder statischen Asset zu.
2. Ereignisdispatch: Die Plattform erzeugt ein Fetch-, Scheduled-, Queue-, E-Mail-, Alarm- oder Tail-Ereignis und ruft den passenden Entrypoint auf.
3. Runtime: workerd stellt V8-Isolates, Web-APIs, Node.js-Kompatibilität und Laufzeitlimits bereit.
4. Bindings: Das env-Objekt erteilt dem Code Fähigkeiten für KV, D1, R2, Durable Objects, Queues, Secrets, Assets, andere Worker und weitere Plattformdienste.
5. Zustand und Upstreams: Daten liegen ausserhalb des flüchtigen Isolates oder in kontrollierten Durable-Object-Speichern; ausgehende Aufrufe verwenden Fetch, Service Bindings oder unterstützte Socket-APIs.
6. Control Plane: Wrangler, Dashboard und API verwalten Konfiguration, Ressourcenbeziehungen, Secrets, Versionen, Deployments und Observability.

Cloudflare beschreibt Isolates, requestbezogene Rechenzeit und verteilte Ausführung als die drei wichtigsten Unterschiede zu klassischen Serverlaufzeiten (How Workers works). Die Plattformreferenz trennt den Worker selbst von den angebundenen Storage- und Developer-Platform-Produkten (Cloudflare Workers documentation).

Requestpfad und Ausführungsort

Bei einer HTTP-Anfrage entscheidet zuerst die Cloudflare-Konfiguration, ob ein workers.dev-Hostname, eine Route oder eine Custom Domain den Worker auslöst. Eine Route sitzt vor einem vorhandenen Origin und kann Anfragen verändern, beantworten oder weiterleiten. Eine Custom Domain verbindet einen Worker direkt mit einem Hostnamen. Statische Assets können vor oder nach dem Worker ausgewertet werden; run_worker_first verändert diese Reihenfolge (Wrangler configuration – routes, Static Assets – configuration and bindings).

Der externe Pfad lässt sich als Client → DNS → Cloudflare Edge → TLS/HTTP → Route → Worker/Asset → Binding oder Origin modellieren. Die Verbindung zum Origin ist ein neuer Transportkontext. Clientzertifikat, Authorization-Header, Cachekey, Hostheader und Quell-IP müssen deshalb an jeder Grenze bewusst behandelt werden. Ein Service Binding umgeht dagegen die öffentliche Namensauflösung und stellt einen explizit berechtigten Worker-zu-Worker-Pfad bereit (Service bindings).

Smart Placement kann einen Worker näher an seine Backends ausführen, statt allein Nähe zum Benutzer zu priorisieren. Das ist bei datenbanklastigen Aufrufen nützlich, kann für Assets oder reine Edge-Transformation aber den falschen Weg verlängern. Cloudflare dokumentiert deshalb unterschiedliche Empfehlungen für Assets-first und Worker-first (Placement).

workerd und V8-Isolates

workerd ist die serverorientierte JavaScript-/WebAssembly-Laufzeit hinter Workers. V8 stellt Isolates als getrennte Ausführungskontexte bereit. Viele Isolates können sich einen Prozess teilen, ohne dass jede Anwendung einen eigenen JavaScript-Prozess oder Container benötigt. Web-APIs werden weitgehend nativ durch die Laufzeit bereitgestellt (Introducing workerd, Workers security model).

Ein Isolate ist keine persistente Maschine. Es kann wiederverwendet, parallel mit mehreren Requests belegt oder entfernt werden. Zwei aufeinanderfolgende Requests müssen nicht dieselbe Instanz oder denselben Standort treffen. Globale Objekte eignen sich für unveränderliche, teuer zu erzeugende Hilfsstrukturen oder opportunistische Caches, aber nicht als Quelle der Wahrheit. Jede Korrektheit, die von einer globalen Variable zwischen Requests abhängt, ist ein Architekturfehler.

V8-Isolation ersetzt nicht sämtliche Sicherheitskontrollen. Cloudflare ergänzt Laufzeit- und Prozessschutz, Ressourcenlimits und spezielle Spectre-Abwehr. Der Betreiber bleibt für Eingabevalidierung, Autorisierung, Secret-Scope, Zielallowlists, Ausgabelimits und Datenklassifikation verantwortlich. Die Isolate-Grenze schützt nicht vor einer Anwendung, die mit ihren legitimen Bindings falsche Daten liest oder schreibt.

Ereignismodell und Handler

Workers implementieren Entrypoints für unterschiedliche Ereignistypen. Der allgemeine Handlerkatalog umfasst Fetch, Scheduled, Queue, E-Mail, Alarm und Tail (Handlers).

Der Fetch Handler erhält Request, env und ctx und liefert eine Web-API-Response (Fetch handler). ctx.waitUntil() registriert Arbeit, die nach dem Senden der Antwort weiterlaufen darf; sie bleibt an dokumentierte Laufzeit- und Fehlergrenzen gebunden und ist kein langlebiger Jobserver (Context – waitUntil). Für dauerhafte, wiederholbare Abläufe sind Queues oder Workflows geeigneter als eine Kette unbeobachteter Background 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>;

Das Beispiel verwendet ein Service Binding statt einer frei konfigurierten URL. Damit werden Erreichbarkeit und Berechtigung zur Deploymentkonfiguration, während der Code nur eine Fetcher-Capability sieht. Die Runtime-APIs sind weborientiert und umfassen unter anderem Fetch, Streams, Web Crypto, WebSockets, HTMLRewriter und TCP Sockets (Runtime APIs).

Der Code läuft nicht in einer frei gewählten lokalen Node-Umgebung, sondern gegen einen versionierten Runtimevertrag. Das Compatibility Date bestimmt, welche Verhaltensänderungen für ein Deployment gelten.

Compatibility Date und Runtimevertrag

Eine Compatibility Date ist kein Releasehinweis und keine Aussage über den «aktuellen Stand» des Artikels. Sie ist Teil des Runtimevertrags eines konkreten Worker-Deployments. Änderungen, die bestehendes Verhalten brechen könnten, werden nach Datum oder Flag aktiviert. Ein älteres Datum hält kompatibles Verhalten fest; ein neueres Datum muss wie eine Abhängigkeitsaktualisierung getestet und ausgerollt werden (Compatibility flags).

Admins behandeln deshalb diese Felder gemeinsam:

• Codecommit und gebündeltes Artefakt;
• Compatibility Date und explizite Flags;
• Wrangler- und Buildwerkzeugkette;
• Bindingdefinitionen, Routes und Placement;
• Version-ID und Deploymentgewicht;
• Daten- oder Durable-Object-Migrationen.

Node.js-Kompatibilität ist opt-in und implementiert nur einen dokumentierten Teil der Node-APIs. Einige Module sind vollständig, andere teilweise oder lediglich als Import-Stub verfügbar. nodejs_compat darf daher nicht mit «vollständige Node-Laufzeit» gleichgesetzt werden (Node.js compatibility).

Sprachen und Technologiestack

Cloudflare dokumentiert JavaScript, TypeScript, Python und Rust als erstklassige Sprachpfade; WebAssembly öffnet weitere Quellsprachen (Languages). Der resultierende Technologiestack unterscheidet Entwicklung und Ausführung:

Rust wird über workers-rs und WebAssembly integriert; das importierte Wasm-Modul bleibt Teil des Workerartefakts (Rust language support). Python Workers verwenden eigene Entrypointklassen und eine Laufzeitintegration, nicht einen frei administrierbaren CPython-Prozess.

Konfiguration und Wrangler

Die Wrangler-Konfiguration ist die deklarative Verbindung zwischen Code und Plattform. Sie definiert mindestens Name, Entrypoint, Compatibility Date, Routes sowie Bindings. Named Environments können abweichende Werte besitzen; Bindings müssen pro Umgebung bewusst geprüft werden. Cloudflare dokumentiert die Felder und Vererbung im Wrangler-Schema (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 startet die projektlokal fixierte CLI; die Wrangler Commands dokumentieren Authentisierung, Typgenerierung, Deployment, Versions- und Logkommandos. wrangler types erzeugt Typen aus der tatsächlichen Bindingkonfiguration. deploy --dry-run prüft Bundle und Konfiguration, erzeugt aber keinen Beweis für funktionierende Remote-Ressourcen oder korrekte Autorisierung.

Nachdem Laufzeit und Build geklärt sind, stellt sich die Zugriffsfrage. Ein Worker erreicht Datenbanken, Queues, Secrets und andere Worker über deklarierte Bindings statt über frei verteilte Zugangsdaten.

Bindings als Capability-Modell

Ein Binding ist gleichzeitig Berechtigung und Laufzeit-API. Der Worker erhält beispielsweise env.ARCHIVE als R2-Bucket, env.DB als D1-Datenbank oder env.AUTH als internen Service. Der zugrunde liegende Plattformcredential wird dem Anwendungscode nicht als wiederverwendbarer API-Key offengelegt (Bindings).

Das Capability-Modell verschiebt die zentrale Adminfrage von «Welches Secret steht in der Umgebungsvariable?» zu «Welche Ressource ist unter welchem Namen in welcher Umgebung an welche Version gebunden?». Eine falsche Bucket-ID oder Service-Binding-Version kann trotz identischem Code Datenverlust oder Cross-Environment-Zugriff verursachen.

Bindings sollten nach Aufgabe und Umgebung getrennt sein. Produktions- und Testworker teilen keine schreibbaren Buckets, Queues oder Datenbanken, sofern dies nicht ausdrücklich Teil eines kontrollierten Integrationstests ist. Generische Namen wie DB reichen im Code, wenn das Deployment die tatsächliche Ressource eindeutig und überprüfbar bindet.

Secrets und Variablen

Normale Variablen sind Konfiguration, keine Geheimnisse. Secrets sind verschlüsselte Textbindungen und werden ausserhalb des Quellcodes verwaltet. Erforderliche Secret-Namen können deklariert werden, ohne ihre Werte in die Konfigurationsdatei zu schreiben (Environment variables, Secrets).

Ein Secretwechsel ist ein Zustandswechsel der Anwendung. Global aus env abgeleitete Clients können in wiederverwendeten Isolates einen alten Wert behalten; Cloudflare empfiehlt, solche Ableitungen requestbezogen zu erzeugen. Rotation umfasst daher Setzen, Deployment-/Bindingprüfung, parallele Gültigkeit falls das Zielsystem dies verlangt, Telemetrie und kontrolliertes Entfernen.

Service Bindings und Worker-zu-Worker-Architektur

Service Bindings verbinden Worker explizit, ohne einen öffentlich adressierbaren HTTP-Endpunkt zu benötigen. Der aufgerufene Service kann über Fetch oder RPC exponiert werden. Das reduziert Netzwerk- und Credentialkonfiguration, beseitigt aber keine Versions- und Vertragsprobleme. Bei getrennten Rollouts können Caller und Callee unterschiedliche APIstände verwenden (Service bindings, Gradual deployments).

Admins dokumentieren je Binding:

• Caller und Zielservice;
• Environment und Zielversion beziehungsweise Rolloutstrategie;
• öffentliche Erreichbarkeit des Zielworkers;
• Timeout-, Fehler- und Retrysemantik;
• Request-ID-Weitergabe und Tracekorrelation;
• Vertragskompatibilität bei unabhängigen Deployments.

Eine Kette vieler Worker verteilt eine Anfrage auf mehr mögliche Ausfallstellen. Weniger öffentliche Angriffsfläche ist wertvoll; zu feine Aufteilung kann dafür Subrequesttiefe, Debuggingaufwand und Versionsskew erhöhen.

Zustandsdienste: Modell vor Produktname

Der Isolate-Heap ist flüchtig. Persistenter Zustand liegt in gebundenen Diensten, deren Semantik sich deutlich unterscheidet. Cloudflares Storage-Übersicht ordnet die Produkte nach Zugriffsmuster und Konsistenz ein (Choosing a data or storage product).

Cache API

Die Cache API arbeitet lokal im Rechenzentrum, in dem der Worker die Anfrage bearbeitet. cache.put() ist daher keine globale Replikation und kein persistenter Datenbankwrite. caches.default teilt den Standardcachekontext; benannte Caches schaffen Namespaces, aber ebenfalls keine globale Konsistenz (How the Cache works).

Personalisierte Antworten dürfen nur mit einem Key gecacht werden, der alle relevanten Identitäts- und Variantenmerkmale abbildet. Authorization, Cookies, Sprache, Encoding und Mandantenzugehörigkeit sind typische Leckagegrenzen. Cache-Purge und Originvalidierung gehören zur Recovery, nicht nur TTLs.

Workers KV

KV repliziert Daten über zentrale Stores und Edge-Caches. Änderungen können an anderen Standorten zeitversetzt sichtbar werden; auch «nicht gefunden» kann gecacht sein. Cloudflare nennt für entfernte Standorte Verzögerungen von bis zu 60 Sekunden oder mehr und empfiehlt KV nicht für atomare Read-Modify-Write-Transaktionen (How KV works).

KV eignet sich für überwiegend gelesene Konfiguration, Allow-/Deny-Listen oder Caches, wenn Staleness explizit toleriert wird. Globale Rate-Limits, eindeutige Sequenzen oder sofortige Credentialrevocation gehören nicht ohne zusätzliche Koordination in KV.

Durable Objects

Ein Durable Object verbindet eine weltweit eindeutige Objekt-ID mit serieller Koordination und privatem Speicher. Requests für dieselbe ID werden zu derselben logischen Instanz geroutet. Neue Namespaces verwenden den SQLite-Storagepfad; dieser bietet transaktionalen, stark konsistenten Speicher und Point-in-Time-Recovery-Funktionen (Durable Objects overview, SQLite-backed Durable Object Storage).

Auch ein Durable Object ist kein ständig laufender Server. In-Memory-Zustand kann bei Hibernation oder Eviction verschwinden und muss bei Bedarf aus Storage rekonstruiert werden. Es gibt keinen zuverlässigen Shutdown Hook (Durable Object lifecycle). Änderungen an Klassen und Storagezuordnung sind Lifecycleoperationen; sie werden wie Datenmigrationen behandelt (Durable Object class lifecycle).

D1, R2 und Queues

D1 bietet SQL für relationale Daten. R2 speichert grosse unstrukturierte Objekte und exponiert eine S3-kompatible API ausserhalb beziehungsweise eine Binding-API innerhalb Workers. Queues entkoppeln Producer und Consumer. Diese Dienste ersetzen einander nicht: Ein R2-Objekt kann den Payload tragen, D1 den Index, eine Queue die Verarbeitung anstossen und ein Durable Object konkurrierende Änderungen koordinieren.

Das gemeinsame Commit dieser vier Zustände ist nicht automatisch atomar. Admins planen Idempotency Keys, Outbox-/Inbox-Muster, Reconciliation und Dead-Letter-Verarbeitung. Produktdokumentation und Grenzen der einzelnen Dienste für D1, R2 und Queues sind Teil des Runbooks.

Statische Assets und Full-Stack-Worker

Ein Worker kann statische Assets gemeinsam mit Code ausliefern. Das Assets Binding erlaubt dem Code, ein Asset explizit abzurufen. Die Routingoption bestimmt, ob existierende Assets den Worker umgehen oder ob der Worker zuerst läuft (Static Assets).

Die Reihenfolge ist eine Sicherheitsentscheidung. Bei Assets-first darf ein zufällig vorhandener Dateipfad keine Authentisierung umgehen. Bei Worker-first erhöht jeder Assetrequest Compute- und Abhängigkeitslast. Frameworkadapter verbergen diese Reihenfolge teilweise; das gebaute Deploymentartefakt und die Wrangler-Konfiguration bleiben die massgebliche Wahrheit.

Netzwerk- und Protokollsicht

Workers sitzt im Anwendungspfad oberhalb von DNS, TLS und HTTP. Die Plattform terminiert den externen Transport; der Worker verarbeitet Web-API-Requests. Ausgehendes fetch() erzeugt einen neuen HTTP-Aufruf. TCP Sockets erlauben ausgewählte Outbound-Protokolle, verwandeln den Worker aber nicht in einen allgemein erreichbaren TCP-Server (Workers protocols, TCP sockets).

Für Messaging-Admins sind drei Grenzen wichtig:

• Ein E-Mail-Handler wird durch Cloudflare Email Routing ausgelöst; er lauscht nicht selbst auf SMTP.
• Ein Worker, der eine Mail-API aufruft, muss OAuth-Audience, Tokenlebenszyklus und Retries wie jeder andere API-Client behandeln.
• DNS-, TLS- und HTTP-Fehler liegen vor dem Entrypoint; Binding-, Auth- und Anwendungsfehler danach. Ein fetch()-Timeout sagt ohne Korrelation nicht, welche Phase versagte.

Sicherheits- und Vertrauensgrenzen

Das Sicherheitsmodell besitzt mindestens fünf getrennte Vertrauensgrenzen:

1. Öffentlicher Request: beliebige Header, Bodygrösse, Methode und Identität.
2. Cloudflare-Konfiguration: Zone, Route, WAF, Access, Zertifikate und Fail-open/closed.
3. Workerartefakt: Code, Abhängigkeiten, Source Maps, Compatibility Date und Supply Chain.
4. Bindings: konkrete Ressourcenberechtigungen, Secrets und interne Servicepfade.
5. Upstreams und gespeicherte Daten: eigene Autorisierung, Konsistenz und Recovery.

Least Privilege wird primär durch kleine Bindingflächen und getrennte Environments erreicht. Ein Worker mit schreibendem Zugriff auf alle Buckets und Datenbanken bleibt ein hochprivilegierter Principal, auch wenn er keine sichtbaren Zugangsschlüssel besitzt. Die Workers-Sicherheitsdokumentation erläutert Runtimeisolation; sie ersetzt keine Anwendungssicherheitsarchitektur (Security model).

Supply-Chain-Kontrollen umfassen fixierte Paketversionen, Lockfile, reproduzierbaren Build, Dependency-Scanning, Secret-Scanning, minimale Uploadberechtigungen und geschützte Deploymentumgebungen. Das erzeugte Bundle wird vor dem Upload geprüft; nur Quellcode-Review reicht nicht, wenn Bundler oder Framework zusätzliche Module einbetten.

Edge-Nähe hebt Ressourcenbegrenzungen nicht auf. CPU-Zeit, Subrequests, Speicher und Plattformlimits müssen bereits in Entwurf und Lastmodell berücksichtigt werden.

Limits als Architekturparameter

Workers begrenzt unter anderem CPU-Zeit, Speicher, Startup-Zeit, Subrequests, Bundlegrösse, Logvolumen, Routeanzahl und statische Assets. Werte unterscheiden sich nach Plan und Invocationtyp und können sich ändern. Deshalb gehört im statischen Artikel keine kopierte Limits-Tabelle als vermeintlich zeitlose Wahrheit; die offizielle Workers Limits-Seite ist die Betriebsquelle.

Admins unterscheiden:

• CPU Time: aktive Rechenzeit; Warten auf I/O zählt nicht gleich wie CPU.
• Wall Time: verstrichene Dauer des Ereignisses; Regeln unterscheiden Fetch, Cron, Queue und Durable Object.
• Startup Time: Modulevaluation und Initialisierung vor dem Handler.
• Subrequests: Fetch- und Plattformoperationen pro Invocation.
• Memory: Heap, Streams, Buffer und Bibliothekszustand des Isolates.
• Log Budget: zu grosse oder geheime Payloads sind sowohl Kosten- als auch Datenschutzproblem.

Ein Fehler 1102 weist auf überschrittene Ressourcenlimits hin; 10021 kann bei zu teurer Startup-Initialisierung auftreten. Die Fehlernummer ist ein Einstiegspunkt, kein Root Cause. CPU-Profil, Invocationtyp, Version, Inputklasse und Subrequestgraph müssen zusammen betrachtet werden.

Lokale Entwicklung und Tests

Lokale Entwicklung führt Code mit workerd über Miniflare aus. Bindings werden standardmässig lokal simuliert; einzelne Remote Bindings können gezielt mit echten Plattformressourcen verbunden werden. Vollständig remote ausgeführtes wrangler dev --remote bleibt für netzspezifische Fälle verfügbar, ist aber nicht mehr der Standardpfad (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 und curl prüfen Status und Header des lokalen HTTP-Pfads. Die Workers-Vitest-Integration führt Tests innerhalb workerd aus und stellt Helfer für Bindings, Requests und Durable Objects bereit (Vitest integration, Workers test APIs).

Ein grüner Unit Test belegt keine korrekte Route, Remote-Berechtigung oder Datenmigration. Die Testpyramide umfasst reine Logik, Runtimeintegration, Bindingsemantik, Stagingroute, kontrollierten Production-Smoke-Test und Recoveryübung.

Deployment, Version und Rollout

Eine Version ist ein unveränderliches Code-/Konfigurationsobjekt. Ein Deployment verteilt Traffic auf eine oder mehrere Versionen. Gradual Deployments verschieben Gewichte schrittweise und erlauben Beobachtung sowie Rückkehr zu einer stabilen Version (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

Vor einem Rollout wird die Zuordnung Git commit → Bundlehash → Worker-Version → Deploymentgewicht gespeichert. Bei mehreren Service Bindings ist Versionsskew Teil des Tests. Durable Objects erfordern besondere Migrations- und Rolloutregeln, weil für eine Objekt-ID nicht gleichzeitig beliebige Klassenstände aktiv sein können.

Rollback stellt Code und Konfiguration zurück, aber nicht automatisch externe Daten. Ein neuer Worker kann Daten in einem Format geschrieben haben, das der alte nicht versteht. Schemaänderungen verwenden Expand/Contract, Vorwärtskompatibilität oder eine separat getestete Datenrückführung. «Rollback möglich» ist erst belegt, wenn Code-, Binding- und Datenseite gemeinsam geprüft wurden.

Observability und Betriebsnachweis

Workers Logs sammelt Invocation Logs, eigene Logs, Fehler und unbehandelte Exceptions. Tail Workers oder Logpush können Ereignisse exportieren; OpenTelemetry-Ziele bieten einen direkteren Exportpfad für Logs und Traces (Workers Logs, Tail Workers, Traces).

Jede Invocation sollte mindestens korrelierbar machen:

• Workername, Version-ID und Environment;
• Ereignistyp und Route;
• Request-/Message-/Correlation-ID;
• Ergebnis, HTTP-Status oder Ack/Retry;
• CPU- und Wall Time;
• Subrequestziel und Latenz ohne Secrets;
• Binding-/Ressourcenklasse, nicht sensitiven Vollinhalt;
• fachlichen Idempotency Key bei asynchroner Verarbeitung.

console.log() ist keine unbegrenzte Beweisablage. Loglimits, Sampling und Redaction beeinflussen Sichtbarkeit. Credentials, Authorization Header, Cookies, vollständige Mailinhalte und personenbezogene Payloads werden nicht protokolliert. Monitoring überwacht auch den Exportpfad: Ein fehlerhafter Tail Worker darf die Diagnose des Producerfehlers nicht unmöglich machen.

Die Diagnose folgt dem Veröffentlichungsweg: Route und DNS, aktive Version, Runtime und Bindings, ausgehende Abhängigkeiten und schliesslich Logs sowie Traces.

Admin-Diagnose nach Phasen

Workers-Fehler werden effizient entlang des Ausführungspfads getrennt:

1. DNS: Löst der erwartete Host auf Cloudflare und ist die Zone aktiv?
2. TLS/HTTP: Zertifikat, SNI, Protokoll und Status prüfen.
3. Route/Asset: Trifft Host/Pfad den Worker, ein Asset oder den Origin?
4. Version: Welche Version und welches Deploymentgewicht bearbeitete den Request?
5. Runtime: Startup, CPU, Memory, Exception und Handlerausgang prüfen.
6. Binding: Existiert die Ressource in diesem Environment und besitzt sie die erwartete Capability?
7. Upstream/Storage: Timeout, Auth, Konsistenz, Datenzustand und Retry untersuchen.
8. Recovery: stabile Version, Datenkompatibilität und Reconciliation bestätigen.

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 und curl trennen DNS, TCP, TLS und HTTP vor der Runtime. DNS, TCP, TLS, APIs und Troubleshooting behandeln diese Ebenen vertieft.

Typische Fehlbilder

Backup und Disaster Recovery

Serverless beseitigt kein Backup. Es verschiebt die schützenswerten Objekte:

• Git-Repository, Lockfile und reproduzierbare Builddefinition;
• Wrangler-Konfiguration, Routes, Compatibility Date und Flags;
• Inventar aller Bindings und Zielressourcen;
• Secret-Werte oder deren externe Source of Truth und Rotationsprozess;
• Datenexporte und Restoreverfahren für D1, R2, KV und externe Systeme;
• Durable-Object-Klassen, Lifecycle-/Migrationsstand und gegebenenfalls PITR;
• Queue-/DLQ-Zustand, Idempotency Keys und Reconciliation;
• Version-/Deploymenthistorie sowie ein getesteter Rollbackpfad.

Nicht jedes Produkt hat dieselbe Export- und Restoresemantik. Ein R2-Objektbackup schützt nicht den D1-Index; ein D1-Restore stellt keine bereits bestätigte Queue-Nachricht wieder her; ein zurückgerollter Worker kann neue Objektformate falsch interpretieren. Backup und Disaster Recovery muss deshalb einen konsistenten Anwendungspunkt statt nur einzelne Produktkopien definieren.

Recovery wird in Szenarien getestet: falsches Secret, gelöschte Route, fehlerhafte Version, inkompatibles D1-Schema, verlorenes R2-Objekt, poison Queue Message, fehlerhafte Durable-Object-Klasse und nicht erreichbarer Upstream. RTO und RPO werden je Zustandsdienst und für die zusammengesetzte Anwendung festgelegt.

Technische Geschichte

Cloudflare stellte Workers 2017 als programmierbare Ausführung im globalen Netz vor. Der Ausgangspunkt war die Latenzgrenze zentraler Rechenzentren und die Idee, Code nahe am Datenpfad auszuführen (Code Everywhere: Why We Built Cloudflare Workers).

Die Architektur setzte früh auf V8-Isolates statt auf einen Container oder Prozess je Funktion. Cloudflare beschrieb 2018 die ökonomischen und technischen Unterschiede dieses Modells, aber auch die Einschränkung auf JavaScript beziehungsweise WebAssembly-fähige Sprachen (Cloud Computing without Containers).

Workers KV ergänzte global lesbaren, eventual-consistent Zustand. Durable Objects wurden 2020 als Gegenmodell für koordinierte, stark konsistente Objektzustände angekündigt (Introducing Workers Durable Objects). Damit entwickelte sich Workers von reiner Requesttransformation zu einer Anwendungsplattform mit mehreren expliziten Konsistenzmodellen.

2022 veröffentlichte Cloudflare workerd unter Apache 2.0. Die offene Laufzeit teilt Code mit dem Produktionssystem und verbesserte die Genauigkeit lokaler Entwicklung; sie ist dennoch nicht die gesamte Cloudflare-Plattform mit deren Routing, Orchestrierung und Sicherheitsbetrieb (Introducing workerd, workerd repository).

Spätere Erweiterungen brachten ES-Module-Entrypoints, Compatibility Dates, Service/RPC-Bindings, D1, R2, Queues, Workflows, Python, ausgebaute Node-Kompatibilität, Versionsobjekte und schrittweise Deployments. Diese Geschichte erklärt den heutigen Kern: Workers ist weder Browser-JavaScript auf einem CDN noch ein beliebiger Linuxserver, sondern eine eventgetriebene, capabilitybasierte Laufzeit mit getrennten Daten- und Control-Plane-Produkten.

Admin-Checkliste

Vor Produktivbetrieb sind mindestens folgende Punkte belegt:

• Route, Custom Domain, Assetreihenfolge und Fail-open/closed sind dokumentiert.
• Compatibility Date, Flags, Wrangler-Version, Bundle und Source Maps sind reproduzierbar.
• Jedes Binding besitzt Owner, Environment, Resource-ID, Rechte und Recoverypfad.
• Cache-, KV-, D1-, R2-, Durable-Object- und Queue-Semantik wird nicht vermischt.
• Secrets sind ausserhalb des Repositories, rotierbar und nicht in Logs sichtbar.
• Timeouts, Retries, Idempotenz und Dead-Letter-Verhalten sind pro Ereignistyp definiert.
• Logs und Traces enthalten Version und Correlation-ID, aber keine sensitiven Payloads.
• Gradual Deployment und Rollback berücksichtigen Service-Binding-Versionen und Datenformate.
• Limits werden aus der offiziellen Plattformseite überwacht, nicht aus einer kopierten Tabelle.
• Backup, Restore und Reconciliation wurden für die zusammengesetzte Anwendung getestet.