Cloudflare Workers : la limite de bundle passe à 64 MiB

Avec Cloudflare Workers, la taille du bundle n’est plus une raison de souscrire l’offre Paid. Depuis le 4 septembre 2026, les anciens contrôles des fichiers compressés — 3 MB en Free et 10 MB en Paid — ont laissé place à une limite unique de 64 MiB non compressés pour les deux offres. Le budget de déploiement se lit donc désormais sur la ligne Total Upload de Wrangler, et non sur gzip.

Quelle est la nouvelle limite de taille de Cloudflare Workers ?

Le bundle d’un Worker regroupe le code et les modules associés que Cloudflare reçoit au moment du déploiement. Wrangler, l’outil en ligne de commande de Cloudflare, prépare cet envoi avec esbuild par défaut, y intègre les paquets npm importés par le code, puis en indique la taille.

Jusqu’au 4 septembre, Cloudflare compressait ce bundle et refusait le déploiement dès que le résultat dépassait 3 MB avec Workers Free ou 10 MB avec Workers Paid. Ce contrôle sur la taille compressée a disparu.

Désormais, la plateforme ne vérifie plus qu’un point : le bundle non compressé ne doit pas dépasser 64 MiB. Cette limite est identique pour les offres Free et Paid.

La dernière colonne résume toute la mécanique. Total Upload correspond à la taille non compressée. Wrangler affiche toujours gzip à titre indicatif, mais Cloudflare ne s’en sert plus pour accepter ou refuser un déploiement.

Il serait trompeur d’en déduire un simple coefficient multiplicateur. Les anciennes valeurs portaient sur des octets compressés, exprimés en MB ; la nouvelle concerne des octets non compressés, en MiB. La quantité de code supplémentaire disponible dépend donc de la capacité de compression propre au JavaScript, aux dépendances et aux modules binaires du projet.

L’arbitrage autour de l’offre à $5 a changé

La conséquence commerciale immédiate est précise, mais utile. Workers Paid impose un minimum de $5 USD par compte et par mois. Si une équipe envisageait de changer d’offre uniquement parce que son bundle dépassait l’ancien plafond Free de 3 MB, cette raison n’existe plus tant que Total Upload reste dans la limite de 64 MiB.

Les deux offres ne deviennent pas identiques pour autant. Workers Free comprend toujours 100,000 requêtes par jour, 10 millisecondes de temps CPU par invocation et 50 sous-requêtes par invocation. Workers Paid comprend 10 millions de requêtes et 30 millions de millisecondes CPU par mois, autorise 10,000 sous-requêtes par invocation et peut consacrer jusqu’à 5 minutes de temps CPU à chaque requête, avec une valeur par défaut de 30 secondes.

Le choix budgétaire devient donc plus lisible. L’offre payante se justifie par le trafic, le CPU, les sous-requêtes et les fonctionnalités réservées à Paid — plus par le simple fait qu’un bundle compressible dépassait un seuil Free aujourd’hui supprimé.

Les équipes déjà abonnées à Paid pour un véritable usage en production ne verront pas leur facture baisser directement. Celles dont les bundles restaient largement sous l’ancien plafond ne constateront pas non plus de changement dans leur workflow. Le bénéfice se concentre sur les projets qui réduisaient ou découpaient leur code, voire changeaient d’offre, à cause de la taille de déploiement.

Pour replacer ce choix dans l’ensemble des coûts du compte et de l’exécution, l’analyse complète de Cloudflare explique comment Workers s’articule avec les autres offres et frais d’usage de Cloudflare. Les anciens chiffres sur la limite des bundles sont la seule partie remplacée par ce changement de septembre.

Quatre types de projets qui gagnent en simplicité

Un fondateur de SaaS en solo peut dissocier le choix de l’offre de celui du framework

Prenons une application full-stack déployée avec Workers Free. L’adaptateur du framework, le code de rendu côté serveur et les dépendances de production peuvent produire un bundle qui, une fois compressé, dépasse l’ancien plafond Free alors même que le trafic de l’application reste compatible avec cette offre.

Ce build peut maintenant être évalué par rapport aux 64 MiB de Total Upload. S’il respecte cette limite, la taille du bundle ne suffit plus à imposer le minimum de $5 de l’offre Paid. Cela ne promet pas une production gratuite quelle que soit l’échelle : l’intérêt est de pouvoir valider la demande avant de payer pour des ressources d’exécution encore inutiles.

Une agence peut supprimer le mauvais contrôle dans sa CI

Le responsable des builds d’une agence a peut-être reproduit l’ancien seuil gzip dans chaque dépôt client. Maintenir ce contrôle ferait échouer des builds au nom d’une règle que Cloudflare n’applique plus.

Il faut le remplacer par un contrôle de Total Upload non compressé et fixer un plafond interne inférieur à 64 MiB afin de conserver une marge. Les projets clients échoueront alors sur la contrainte actuelle de la plateforme, et non sur une règle historique.

Une équipe Rust ou WebAssembly gagne de la marge, pas un nouveau runtime

WebAssembly, souvent abrégé en Wasm, permet à un Worker d’exécuter du code binaire compilé depuis des langages comme Rust, Go ou C. Cloudflare précise que les Workers Wasm sont généralement plus volumineux que leurs équivalents JavaScript, car le binaire embarque souvent des dépendances d’exécution supplémentaires.

La nouvelle marge de déploiement laisse davantage de place au module Wasm et au code qui l’entoure. Wrangler prend directement en charge les envois .wasm et .wasm?module. L’optimisation de la taille reste pertinente, et Cloudflare recommande wasm-opt pour alléger le binaire.

Une équipe plateforme peut abandonner une architecture de contournement

Sur Workers Paid, un ingénieur plateforme a pu découper un service pourtant cohérent, retirer une dépendance utile ou créer un mécanisme personnalisé de modules externes dans le seul but de rester sous la limite compressée de 10 MB. Cette décision mérite d’être réexaminée.

Certains découpages doivent rester en place parce qu’ils clarifient les responsabilités ou isolent les défaillances. En revanche, lorsqu’un découpage ne répondait qu’à l’ancien contrôle d’envoi, il ajoute désormais de la complexité sans qu’aucune exigence de la plateforme ne le justifie.

Comment vérifier la vraie taille du bundle avant le prochain déploiement ?

Inutile de l’estimer à partir de la taille de node_modules, du répertoire source ou de l’archive produite séparément par le framework. Lancez le déploiement à blanc de Wrangler depuis le projet Worker : l’outil générera exactement l’artefact que Cloudflare recevrait.

1. 1

   Compiler sans déployer

   Exécutez la commande de simulation documentée par Cloudflare :

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

   Wrangler compile le Worker et écrit le résultat en local, sans le déployer.

2. 2

   Lire Total Upload

   Repérez Total Upload dans la sortie de la commande. Il s’agit de la taille non compressée que Cloudflare compare désormais à la limite de 64 MiB. gzip peut rester utile pour le diagnostic, mais ne doit plus servir de critère de réussite ou d’échec sur la plateforme.

3. 3

   Modifier le budget dans la CI

   Remplacez toute règle fondée sur une taille compressée de 3 MB en Free ou 10 MB en Paid par une règle portant sur Total Upload. Fixez un plafond propre à l’équipe, inférieur au maximum de la plateforme, afin qu’une mise à jour de dépendance ne consomme pas toute la marge disponible.

4. 4

   Surveiller le démarrage lors du vrai déploiement

   Lors du prochain déploiement normal ou envoi de version, relevez la valeur startup_time_ms fournie par Wrangler. Un bundle peut respecter la limite d’envoi tout en échouant au contrôle de démarrage distinct de Cloudflare.

L’erreur classique consiste à surveiller la valeur gzip, visuellement plus petite, parce que c’était autrefois elle qui décidait du déploiement. Ce n’est plus le cas : Total Upload est désormais la ligne qui fait foi.

Les limites réelles n’ont pas augmenté de 64 MiB

Les bundles volumineux peuvent demander davantage de temps pour l’analyse et l’initialisation. Un code qui effectue des opérations coûteuses dans la portée globale, c’est-à-dire en dehors du gestionnaire de requêtes, peut toujours échouer à la validation avec Script startup exceeded CPU time limit et le code d’erreur 10021. Passer sous 64 MiB permet de franchir le contrôle de taille ; cela ne garantit pas un démarrage sain.

Le point est particulièrement important pour les frameworks lourds et Wasm. L’ancienne limite interrompait souvent l’envoi en premier. La nouvelle autorise davantage de code à atteindre la contrainte suivante, où la mémoire et le comportement à l’initialisation deviennent visibles.

Si un Worker reste trop volumineux, la documentation actuelle propose trois solutions concrètes :

• Supprimer les paquets et dépendances que le chemin réellement déployé n’utilise pas.
• Placer la configuration, les ressources statiques et les données binaires dans Workers Static Assets, KV, R2 ou D1 plutôt que dans le bundle du Worker.
• Répartir les fonctionnalités entre plusieurs Workers reliés par des Service Bindings.

Les appels via Service Binding n’entraînent pas une seconde facturation de la requête. Cloudflare facture l’invocation du Worker initial et le temps CPU total consommé par l’ensemble des Workers concernés. Le découpage constitue donc un moyen viable de maîtriser la taille, à condition d’accepter délibérément cette frontière de service supplémentaire.

Que faire dès lundi ?

Agissez cette semaine si un Worker a récemment échoué sur l’ancien contrôle de taille, si l’équipe a supprimé des dépendances du framework pour rester sous ce plafond, ou si la taille du bundle était le seul motif d’un passage à Paid. Lancez le déploiement à blanc, relevez Total Upload, puis réévaluez la décision.

Attendez si le Worker se trouvait déjà très loin sous l’ancienne limite et si le pipeline de déploiement n’impose aucun seuil gzip codé en dur. Le fonctionnement de l’application à l’exécution n’a pas changé.

Restez sur Paid si le nombre de requêtes, le temps CPU, les sous-requêtes ou une autre fonctionnalité Paid le justifient. Une limite d’envoi plus généreuse en Free ne suffit pas à déplacer une charge de production vers une offre dont les quotas d’exploitation sont inadaptés.

Le geste à faire lundi est simple : remplacez gzip par Total Upload dans le contrôle du build, puis choisissez l’offre en fonction de l’usage plutôt que de la taille du bundle.

Retrouvez le prochain changement concret concernant les plateformes dans la newsletter.