Cloudflare Workers Limits: 64 MiB für Free und Paid

Bei den Cloudflare Workers Limits hat Cloudflare die Bundle-Größe als Grund für Workers Paid gestrichen. Seit dem 4. September 2026 gelten statt der bisherigen Prüfgrenzen von 3 MB für Free und 10 MB für Paid – jeweils komprimiert – einheitlich 64 MiB unkomprimiert. Für das Deployment-Budget zählt damit Wranglers Zeile Total Upload statt gzip.

Cloudflare Workers Limits: Was sich konkret geändert hat

Ein Worker-Bundle umfasst den Code und die unterstützenden Module, die Cloudflare bei einem Deployment erhält. Wrangler, das Kommandozeilen-Tool von Cloudflare, erstellt dieses Upload-Paket standardmäßig mit esbuild, bindet die vom Code importierten npm-Pakete ein und weist seine Größe aus.

Bis zum 4. September komprimierte Cloudflare das Bundle und lehnte es ab, sobald das komprimierte Ergebnis bei Workers Free über 3 MB oder bei Workers Paid über 10 MB lag. Diese Prüfung der komprimierten Größe gibt es nicht mehr.

Die Plattform prüft jetzt nur noch eines: Das unkomprimierte Bundle darf höchstens 64 MiB groß sein. Für Free und Paid gilt dasselbe Limit.

Die letzte Spalte beschreibt den gesamten Mechanismus. Total Upload steht für die unkomprimierte Größe. gzip wird weiterhin als Referenz ausgegeben, dient Cloudflare aber nicht mehr als Freigabekriterium für ein Deployment.

Daraus lässt sich kein sauberer Multiplikator ableiten. Die alten Werte maßen komprimierte Bytes in MB, der neue Wert misst unkomprimierte Bytes in MiB. Wie viel zusätzlicher Code tatsächlich hineinpasst, hängt davon ab, wie gut sich das jeweilige JavaScript, seine Abhängigkeiten und Binärmodule komprimieren lassen.

Cloudflare Workers Kosten: Die $5-Entscheidung liegt jetzt woanders

Die unmittelbare geschäftliche Folge ist klar umrissen und relevant. Workers Paid kostet mindestens $5 USD pro Konto und Monat. Wenn ein Team das Upgrade nur eingeplant hatte, weil sein Bundle die bisherige Free-Grenze von 3 MB überschritt, ist dieser Grund entfallen – sofern Total Upload innerhalb von 64 MiB bleibt.

Gleich sind die beiden Tarife dadurch nicht. Workers Free umfasst weiterhin 100,000 Anfragen pro Tag, 10 Millisekunden CPU-Zeit pro Aufruf und 50 Subrequests pro Aufruf. Workers Paid umfasst 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden pro Monat, erlaubt 10,000 Subrequests pro Aufruf und kann pro Anfrage bis zu 5 Minuten CPU-Zeit nutzen; der Standardwert liegt bei 30 Sekunden.

Damit wird die Budgetentscheidung eindeutiger. Bezahlt wird für Traffic, CPU, Subrequests und Funktionen, die nur Paid bietet – nicht allein dafür, dass ein komprimierbares Bundle oberhalb der abgeschafften Free-Grenze lag.

Teams, die Paid bereits für echte Produktionslasten nutzen, werden keine unmittelbare Kostensenkung sehen. Auch für Teams, deren Bundles schon deutlich unter der alten Grenze lagen, ändert sich der Workflow nicht. Der Vorteil konzentriert sich auf Projekte, die wegen der Deployment-Größe Code kürzten, aufteilten oder auf Paid wechselten.

Wie sich Workers neben den übrigen Tarifen und nutzungsabhängigen Kosten von Cloudflare einordnet, zeigt der ausführliche Cloudflare-Test. Die dort genannten alten Bundle-Limits sind der Teil, den diese Änderung im September ersetzt.

Vier Builds, die jetzt leichter werden

Solo-SaaS-Gründer können Tarif- und Framework-Wahl trennen

Angenommen, eine Full-Stack-Anwendung läuft auf Workers Free. Ein Framework-Adapter, Code für Server Rendering und Produktionsabhängigkeiten können gemeinsam ein Bundle ergeben, das komprimiert über der alten Free-Grenze liegt, obwohl der Traffic der Anwendung weiterhin in den Free-Tarif passt.

Dieser Build lässt sich nun anhand von 64 MiB Total Upload beurteilen. Passt er hinein, erzwingt die Bundle-Größe allein nicht mehr das Paid-Minimum von $5. Der Vorteil besteht nicht in kostenlosem Produktivbetrieb bei jeder Größenordnung. Entscheidend ist vielmehr, die Nachfrage validieren zu können, bevor für noch nicht benötigte Runtime-Nutzung bezahlt wird.

Eine Agentur kann die falsche CI-Schranke entfernen

Die Build-Verantwortlichen einer Agentur könnten den alten gzip-Grenzwert in jedes Kunden-Repository übernommen haben. Bleibt diese Prüfung bestehen, scheitern Builds an einer Regel, die Cloudflare nicht mehr durchsetzt.

Sie sollte durch eine Prüfung des unkomprimierten Total Upload ersetzt werden. Als interner Grenzwert bietet sich ein Wert unterhalb von 64 MiB an, damit Spielraum bleibt. Kundenprojekte scheitern dann an der aktuellen Plattformgrenze und nicht an einer historischen Vorgabe.

Ein Rust- oder WebAssembly-Team gewinnt Spielraum, aber keine neue Runtime

WebAssembly, meist Wasm genannt, ermöglicht einem Worker, Binärcode auszuführen, der aus Sprachen wie Rust, Go oder C kompiliert wurde. Cloudflare weist darauf hin, dass Wasm Workers in der Regel größer als vergleichbare JavaScript Workers sind, weil das Binärmodul häufig zusätzliche Runtime-Abhängigkeiten mitbringt.

Das höhere Deployment-Limit schafft mehr Platz für ein Wasm-Modul und den umgebenden Code. Wrangler unterstützt Uploads mit .wasm und .wasm?module direkt. Größenoptimierung bleibt wichtig; zum Verkleinern des Binärmoduls empfiehlt Cloudflare wasm-opt.

Ein Plattformteam kann Behelfsarchitektur zurückbauen

Möglicherweise hat ein Plattform-Engineer unter Workers Paid einen zusammengehörigen Dienst aufgeteilt, eine nützliche Abhängigkeit entfernt oder einen eigenen Pfad für externe Module gebaut, nur um unter 10 MB komprimiert zu bleiben. Diese Entscheidung sollte neu bewertet werden.

Manche Aufteilungen sollten bestehen bleiben, weil sie klare Zuständigkeiten oder Fehlergrenzen schaffen. Eine Aufteilung, die ausschließlich wegen der abgeschafften Upload-Prüfung existiert, verursacht dagegen Komplexität, ohne noch durch eine Plattformvorgabe begründet zu sein.

Cloudflare Workers Bundle Size vor dem nächsten Deployment richtig prüfen

Die Größe von node_modules, des Quellverzeichnisses oder des Archivs aus einem separaten Framework-Build liefert hier keine verlässliche Antwort. Ein Dry Deploy mit Wrangler im Worker-Projekt erzeugt genau das Artefakt, das Cloudflare tatsächlich erhalten würde.

1. 1

   Build erstellen, ohne zu deployen

   Cloudflare dokumentiert dafür diesen Dry-Run-Befehl:

   wrangler deploy --outdir bundled/ --dry-run

   Wrangler erstellt den Worker und schreibt die Ausgabe lokal, ohne sie zu deployen.

2. 2

   Total Upload ablesen

   In der Befehlsausgabe steht der Wert Total Upload. Das ist die unkomprimierte Bundle-Größe, die Cloudflare jetzt mit 64 MiB vergleicht. gzip kann weiterhin als Diagnosewert dienen, ist aber nicht mehr die Zahl, die über Erfolg oder Scheitern auf der Plattform entscheidet.

3. 3

   CI-Budget umstellen

   Jede Regel für eine komprimierte Größe von 3 MB bei Free oder 10 MB bei Paid sollte durch eine Total Upload-Regel ersetzt werden. Ein teaminterner Grenzwert unterhalb des Plattformmaximums verhindert, dass bereits ein einziges Abhängigkeits-Update den gesamten Spielraum verbraucht.

4. 4

   Startup beim echten Deployment beobachten

   Beim nächsten regulären Deployment oder Versions-Upload sollte Wranglers Ausgabe startup_time_ms festgehalten werden. Ein Bundle kann das Upload-Limit einhalten und trotzdem an Cloudflares separater Startup-Prüfung scheitern.

Der häufigste Fehler besteht darin, weiterhin den kleiner wirkenden gzip-Wert zu beobachten, weil er früher über das Deployment entschied. Das tut er nicht mehr. Die maßgebliche Budgetzeile heißt jetzt Total Upload.

Die tatsächlichen Limits sind nicht um 64 MiB gewachsen

Größere Bundles können mehr Zeit zum Parsen und Initialisieren benötigen. Code, der im globalen Scope – also außerhalb des Request-Handlers – aufwendige Arbeit ausführt, kann weiterhin mit Script startup exceeded CPU time limit und Fehlercode 10021 an der Validierung scheitern. Ein Deployment unter 64 MiB darf die Größenprüfung passieren; ein fehlerfreier Startup ist damit nicht garantiert.

Besonders relevant ist das für umfangreiche Frameworks und Wasm. Das alte Limit stoppte häufig bereits den Upload. Unter dem neuen Limit erreicht mehr Code die nächste Grenze, an der Speicherbedarf und Initialisierungsverhalten sichtbar werden.

Ist ein Worker weiterhin zu groß, nennt die aktuelle Dokumentation drei praktikable Auswege:

• Pakete und Abhängigkeiten entfernen, die der im Deployment verwendete Ausführungspfad nicht benötigt.
• Konfiguration, statische Assets und Binärdaten statt im Worker-Bundle in Workers Static Assets, KV, R2 oder D1 ablegen.
• Funktionen mit Service Bindings auf mehrere Workers verteilen.

Aufrufe über Service Bindings verursachen keine zweite Anfragegebühr. Cloudflare berechnet den ersten Worker-Aufruf und die gesamte CPU-Zeit aller beteiligten Workers. Damit ist eine Aufteilung ein praktikables Werkzeug zur Größenkontrolle; die zusätzliche Servicegrenze sollte dennoch bewusst in Kauf genommen werden.

Was am Montag zu tun ist

Noch in dieser Woche besteht Handlungsbedarf, wenn ein Worker kürzlich an der alten Größenprüfung gescheitert ist, wenn Framework-Abhängigkeiten gekürzt wurden, um darunter zu bleiben, oder wenn die Bundle-Größe der einzige Grund für ein Paid-Upgrade war. Dann gilt: Dry Deploy ausführen, Total Upload notieren und die Entscheidung neu bewerten.

Abwarten ist sinnvoll, wenn der Worker bereits deutlich unter dem alten Limit lag und die Deployment-Pipeline keine fest codierte gzip-Schranke enthält. An der Runtime der Anwendung hat sich nichts geändert.

Paid bleibt die richtige Wahl, wenn Anfragen, CPU-Zeit, Subrequests oder eine andere Paid-Funktion den Tarif rechtfertigen. Ein höheres Upload-Limit im Free-Tarif ist kein Grund, eine Produktionslast in einen Tarif zu verschieben, dessen Betriebsquoten nicht passen.

Die Aufgabe für Montag ist einfach: Die Build-Prüfung von gzip auf Total Upload umstellen und die Tarifentscheidung anschließend an der Nutzung statt an der Bundle-Größe ausrichten.

Die nächste praktische Plattformänderung kommt mit dem Newsletter.