Was sind Cloudflare Workers? Eine Erklärung in einfachen Worten

Überall liest du „läuft auf Cloudflare Workers”, auch bei EmDash, und du nickst brav, ohne wirklich zu wissen, was ein Worker eigentlich ist. Serverlos? Edge? Isolate? Klären wir das in einfachen Worten, ohne Nebelkerzen.

Am Ende weißt du, was ein Worker ist, warum er sich von einem normalen Server oder einer Lambda-Funktion unterscheidet und warum er eine naheliegende Grundlage für ein CMS wie EmDash ist.

Die Kurzfassung in einem Satz

Ein Cloudflare Worker ist ein kleines Stück Code, das im globalen Netzwerk von Cloudflare läuft, an Hunderten von Standorten nah bei deinen Besuchern, sofort startet, sobald eine Anfrage eintrifft, und im Leerlauf nichts kostet.

Das war’s. Packen wir nun die drei Ideen aus, die in diesem Satz stecken: serverlos, Edge und Isolate.

Serverlos: du verwaltest keinen Server

Klassisch bedeutet eine Website zu betreiben, dass du einen Server mietest (oder eine VM oder einen Container), der rund um die Uhr läuft. Du patchst sein Betriebssystem, dimensionierst ihn für Lastspitzen und bezahlst ihn auch nachts um vier, wenn niemand vorbeischaut.

„Serverlos” dreht das um. Du lädst nur deinen Code hoch, und die Plattform führt ihn bei Bedarf aus. Irgendwo steht immer noch ein Server, das Wort ist Marketing, aber du siehst ihn nie, dimensionierst ihn nie und patchst ihn nie. Kein SSH, keine Betriebssystem-Updates, keine Kapazitätsplanung.

Der Nebeneffekt, den alle lieben: Skalierung auf null. Kommen keine Anfragen, läuft nichts, und du zahlst nichts. Treffen tausend Anfragen gleichzeitig ein, führt die Plattform deinen Code tausendmal parallel aus. Du konfigurierst davon gar nichts.

Edge: dein Code läuft nah beim Besucher

Normalerweise steht dein Server an einem einzigen Ort, sagen wir in einem Rechenzentrum in Virginia. Eine Besucherin in Sydney schickt jede Anfrage einmal um den halben Planeten und wartet auf die Antwort. Diese Rundreise ist Latenz, und sie summiert sich.

Cloudflare betreibt ein Netzwerk aus Rechenzentren in Hunderten Städten weltweit. „Edge” heißt: Dein Code läuft jeweils dort, wo es zum Besucher am nächsten ist. Der Nutzer in Sydney landet in Sydney, die Nutzerin in London in London. Derselbe Code, nah bei allen ausgeführt.

Für eine Website bedeutet das: Die dynamischen Teile, also eine Seite rendern, die Anmeldung prüfen, die Datenbank abfragen, passieren in der Nähe der Leserin statt an einem weit entfernten Punkt. Das ist ein wesentlicher Grund, warum Edge-Seiten weltweit flott wirken, ohne dass du von Hand ein CDN und Origin-Server einrichtest.

Isolate: warum Workers sofort starten

Jetzt kommt der clevere Teil, und genau das unterscheidet Workers von älteren serverlosen Diensten wie AWS Lambda.

Plattformen im Lambda-Stil starten üblicherweise pro Funktion einen Container oder eine Mikro-VM. Das ist abgeschottet und sicher, aber der Start dauert: der gefürchtete „Cold Start” von einigen hundert Millisekunden bis zu Sekunden, während eine komplette Umgebung hochfährt.

Cloudflare Workers nutzen stattdessen V8-Isolate, dieselbe leichtgewichtige Sandbox-Technik, mit der dein Browser das JavaScript vieler Websites nebeneinander ausführt, ohne dass ein Tab die Daten eines anderen lesen kann. Ein Isolate ist keine ganze virtuelle Maschine, sondern ein billiges, sicheres Abteil innerhalb einer gemeinsamen Laufzeitumgebung. Cloudflare kann eines in etwa einer Millisekunde erzeugen und viele Isolate gefahrlos im selben Prozess laufen lassen.

Die praktischen Folgen:

• Praktisch keine Cold Starts. Ein Worker ist fast sofort bereit.
• Enorme Dichte. Eine einzelne Maschine betreibt riesige Mengen an Isolaten, und nur deshalb ist „führe meinen Code in Hunderten Städten aus” überhaupt bezahlbar.
• Starke Abschottung. Dein Code sieht den Code anderer nicht, das ist so gebaut.

Der Haken: Ein Isolate ist kein vollwertiger Node.js-Server. Workers laufen in einer V8-Umgebung mit Web-Standard-APIs (fetch, Request, Response, Web Crypto) plus den Laufzeit-APIs von Cloudflare. Nicht jede Node-Bibliothek funktioniert unverändert. Moderne Frameworks, Astro eingeschlossen, zielen direkt auf diese Umgebung, in der Praxis merkst du also meist nichts davon. Trotzdem ist „läuft auf Workers” eine echte technische Rahmenbedingung und nicht bloß eine Hosting-Entscheidung.

Wofür du zahlst: CPU-Zeit, nicht Laufzeit

Das überrascht viele. Auf einem normalen Server zahlst du für die Zeit, in der die Maschine existiert. Bei Workers wird dir im Wesentlichen die tatsächlich rechnende CPU-Zeit berechnet, also die Millisekunden, in denen dein Code arbeitet, und nicht die Zeit, in der er wartet (etwa auf eine langsame Datenbank oder eine fremde API).

Für Web-Arbeit nach dem Muster Anfrage und Antwort, die stoßweise kommt und viel wartet, ergibt das eine wirklich andere und oft deutlich günstigere Kostenform. Es gibt ein großzügiges kostenloses Kontingent, und der Workers-Paid-Plan beginnt bei 5 USD pro Monat, wenn du mehr brauchst (inklusive Funktionen wie den Dynamic Workers, die Plugins in der Sandbox antreiben).

Ein schnelles Denkmodell

Alles zusammengesetzt:

Anfrage von einem Nutzer in Tokio
   ↓
Trifft auf Cloudflares Rechenzentrum in Tokio (die Edge)
   ↓
Ein V8-Isolate führt deinen Worker-Code sofort aus (kein Cold Start)
   ↓
Der Worker arbeitet, liest vielleicht eine Datenbank, rendert eine Seite
   ↓
Die Antwort geht zurück nach Tokio, nur Millisekunden entfernt
   ↓
Wieder im Leerlauf → du zahlst nichts bis zur nächsten Anfrage

Warum das eine hervorragende Grundlage für ein CMS ist

Genau deshalb ist EmDash, Cloudflares Open-Source-CMS, auf Workers gebaut:

• Globales Tempo ab Werk. Deine Inhalte werden nah bei jeder Leserin gerendert, ohne CDN-Bastelei.
• Wirtschaftlichkeit durch Skalierung auf null. Ein Blog mit wenig Traffic kostet fast nichts, eine Lastspitze wird automatisch abgefedert. Cloudflares eigener Blog läuft auf EmDash und hat einen DDoS mit 28.000 Anfragen pro Sekunde einfach weggesteckt.
• Kein Server zum Patchen. Die größte Sicherheitsquelle des Ärgers bei WordPress, ein alternder Server samt PHP-Stack, existiert hier schlicht nicht.
• Ein natürlicher Ort für Plugins in der Sandbox. Isolate liefern ohnehin starke, günstige Abschottung, also führt EmDash jedes Plugin in einem eigenen Isolate mit ausdrücklich deklarierten Rechten aus, sicher durch Bauart.

Workers arbeiten allerdings nicht allein. Ein CMS braucht außerdem eine Datenbank und einen Dateispeicher, und Cloudflare liefert beides als serverlose Begleiter: D1 für die Datenbank (siehe Cloudflare D1 erklärt) und R2 für Dateien (siehe R2 vs. S3). Zusammen bilden sie das Trio, auf das EmDash deployt.

Eine echte Website auf Workers zu bringen, kostet ein paar wrangler-Befehle, und darin liegt der ganze Reiz: kein Server einzurichten, keine Kapazität zu planen.

Workers ist das Netzwerk, auf dem deine Website läuft, wenn du zu 2emdash wechselst: Wir bauen alternde Websites auf Cloudflare neu und geben den Besitzern ein einfaches Panel an die Hand. Wir sind ein unabhängiger Dienst, nicht verbunden mit Cloudflare oder dem EmDash-Projekt.