Límite de tamaño de Cloudflare Workers: 64 MiB también en Free

Cloudflare acaba de eliminar el límite de tamaño de Cloudflare Workers como motivo para contratar Workers Paid. El 4 de septiembre de 2026, los antiguos topes comprimidos de 3 MB en Free y 10 MB en Paid se sustituyeron por un único límite sin comprimir de 64 MiB para ambos planes. Ahora, el presupuesto de despliegue lo marca la línea Total Upload de Wrangler, no gzip.

Qué cambió en el límite de tamaño de Cloudflare Workers

El bundle de un Worker reúne el código y los módulos auxiliares que Cloudflare recibe al desplegarlo. Wrangler, la herramienta de línea de comandos de Cloudflare, prepara ese archivo con esbuild de forma predeterminada, incorpora los paquetes npm que importa el código e informa de su tamaño.

Hasta el 4 de septiembre, Cloudflare comprimía el bundle y rechazaba el despliegue cuando el resultado superaba 3 MB en Workers Free o 10 MB en Workers Paid. Esa comprobación del tamaño comprimido ya no existe.

La plataforma ahora comprueba una sola cosa: el bundle sin comprimir no puede superar 64 MiB. El límite es el mismo para Free y Paid.

La última columna resume todo el mecanismo. Total Upload indica el tamaño sin comprimir. Wrangler sigue mostrando gzip como referencia, pero Cloudflare ya no lo usa para aceptar o rechazar un despliegue.

No conviene convertir el cambio en un multiplicador exacto. Los valores anteriores medían bytes comprimidos en MB; el nuevo mide bytes sin comprimir en MiB. El código adicional que cabe depende de cuánto puedan comprimirse el JavaScript, las dependencias y los módulos binarios de cada proyecto.

La decisión sobre el plan de $5 cambia de criterio

La consecuencia inmediata para el presupuesto es concreta. Workers Paid tiene un cargo mínimo de $5 USD al mes por cuenta. Si un equipo pensaba actualizar solo porque su bundle superaba el antiguo tope de 3 MB de Free, ese motivo desapareció siempre que Total Upload no pase de 64 MiB.

Eso no iguala los dos planes. Workers Free sigue incluyendo 100,000 solicitudes al día, 10 milisegundos de CPU por invocación y 50 subsolicitudes por invocación. Workers Paid incluye 10 millones de solicitudes y 30 millones de milisegundos de CPU al mes, permite 10,000 subsolicitudes por invocación y puede ejecutar hasta 5 minutos de CPU por solicitud, con un valor predeterminado de 30 segundos.

Así, la decisión presupuestaria queda más clara. Conviene pagar por tráfico, CPU, subsolicitudes y funciones exclusivas de Paid, no solo porque un bundle comprimible haya superado el antiguo umbral de Free.

Los equipos que ya usan Paid por necesidades reales de producción no verán una reducción directa en la factura. Tampoco cambiará el flujo de trabajo de quienes ya estaban holgadamente por debajo del límite anterior. La mejora se concentra en los proyectos que recortaban o dividían el código, o cambiaban de plan, únicamente por el tamaño del despliegue.

Para entender el resto de los cálculos de cuenta y ejecución, el análisis completo de Cloudflare explica cómo encaja Workers con los demás planes y cargos por uso de Cloudflare. Las cifras antiguas sobre el límite del bundle son la parte que sustituye este cambio de septiembre.

Cuatro tipos de proyectos que ahora lo tienen más fácil

Quien crea un SaaS puede separar la elección del plan de la del framework

Supongamos que se lanza una aplicación full stack en Workers Free. Un adaptador de framework, el código de renderizado del servidor y las dependencias de producción pueden generar un bundle que, incluso comprimido, rebasa el antiguo límite de Free aunque el tráfico de la aplicación todavía encaje en ese plan.

Ahora esa compilación se puede evaluar frente a los 64 MiB de Total Upload. Si cabe, el tamaño del bundle por sí solo no obliga a asumir el mínimo de $5 de Paid. La ventaja no es disponer de producción gratuita a cualquier escala, sino validar la demanda antes de pagar por un uso de ejecución que todavía no hace falta.

Una agencia puede retirar una comprobación obsoleta de CI

Es posible que la persona responsable de las compilaciones en una agencia haya copiado el antiguo umbral de gzip en todos los repositorios de clientes. Mantener esa comprobación provoca compilaciones fallidas por una regla que Cloudflare ya no aplica.

Hay que sustituirla por una comprobación del valor sin comprimir de Total Upload y fijar un techo interno inferior a 64 MiB para conservar margen. Así, los proyectos de clientes fallarán por la restricción actual de la plataforma, no por una regla histórica.

Un equipo de Rust o WebAssembly gana espacio, no un entorno de ejecución nuevo

WebAssembly, normalmente abreviado como Wasm, permite que un Worker ejecute código binario compilado desde lenguajes como Rust, Go o C. Cloudflare señala que los Workers con Wasm suelen ser más grandes que sus equivalentes en JavaScript porque el binario suele incorporar dependencias adicionales del entorno de ejecución.

El nuevo margen de despliegue deja más espacio para un módulo Wasm y el código que lo rodea. Wrangler admite directamente archivos .wasm y .wasm?module. Optimizar el tamaño sigue siendo importante, y Cloudflare recomienda wasm-opt para reducir el binario.

Un equipo de plataforma puede retirar una arquitectura provisional

Un equipo de plataforma con Workers Paid quizá dividió un servicio que tenía sentido mantener unido, eliminó una dependencia útil o creó una ruta personalizada para módulos externos solo para mantenerse por debajo de 10 MB comprimidos. Esa decisión merece una nueva revisión.

Algunas divisiones deben conservarse porque establecen responsabilidades o límites de fallo claros. Si una separación solo existe por la comprobación de subida que ya se retiró, ahora añade complejidad sin responder a ningún requisito de la plataforma.

Cómo comprobar el tamaño del bundle de Cloudflare Workers antes de desplegar

No hace falta deducirlo a partir del tamaño de node_modules, del directorio de código fuente ni del archivo generado por una compilación independiente del framework. La ejecución en seco de Wrangler debe lanzarse desde el proyecto del Worker para que construya exactamente el artefacto que recibiría Cloudflare.

1. 1

   Compilar sin desplegar

   Ejecuta el comando de prueba documentado por Cloudflare:

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

   Wrangler compila el Worker y guarda el resultado en el equipo local sin desplegarlo.

2. 2

   Consultar Total Upload

   Busca Total Upload en la salida del comando. Ese es el tamaño sin comprimir que Cloudflare compara ahora con el límite de 64 MiB. gzip puede seguir siendo útil como dato de diagnóstico, pero ya no determina si la plataforma acepta o rechaza el despliegue.

3. 3

   Actualizar el presupuesto de CI

   Sustituye cualquier regla de tamaño comprimido de 3 MB para Free o 10 MB para Paid por una basada en Total Upload. Define un techo interno por debajo del máximo de la plataforma para que una actualización de dependencias no consuma todo el margen disponible.

4. 4

   Vigilar el arranque en un despliegue real

   En el siguiente despliegue normal o al subir una versión, registra el valor startup_time_ms que muestra Wrangler. Un bundle puede cumplir el límite de subida y aun así fallar en la comprobación independiente de arranque de Cloudflare.

El error habitual es fijarse en el valor aparentemente menor de gzip, porque antes era el que decidía el despliegue. Ya no es así: ahora la cifra que marca el presupuesto es Total Upload.

Los demás límites no aumentaron 64 MiB

Los bundles más grandes pueden tardar más en analizarse e inicializarse. El código que realiza tareas costosas en el ámbito global, es decir, fuera del manejador de solicitudes, todavía puede fallar durante la validación con Script startup exceeded CPU time limit y el código de error 10021. Un despliegue inferior a 64 MiB supera el control de tamaño, pero eso no garantiza que arranque correctamente.

Esto importa sobre todo en frameworks pesados y en Wasm. Antes, el límite solía detener primero la subida. El nuevo permite que más código llegue a la siguiente restricción, donde se hacen visibles el consumo de memoria y el comportamiento durante la inicialización.

Si un Worker sigue siendo demasiado grande, la documentación actual plantea tres salidas prácticas:

• Eliminar los paquetes y dependencias que no utilice la ruta desplegada.
• Guardar la configuración, los recursos estáticos y los datos binarios en Workers Static Assets, KV, R2 o D1, en lugar de incluirlos en el bundle del Worker.
• Dividir la funcionalidad entre varios Workers mediante Service Bindings.

Las llamadas de Service Binding no añaden una segunda tarifa por solicitud. Cloudflare factura la invocación inicial del Worker y el tiempo total de CPU utilizado por todos los Workers implicados. Por eso, dividir el servicio es una opción viable para controlar el tamaño, aunque conviene asumir deliberadamente el límite adicional entre servicios.

Qué conviene hacer el lunes

Hay que actuar esta semana si un Worker falló hace poco por la antigua comprobación de tamaño, si el equipo recortó dependencias del framework para no superarla o si el tamaño del bundle era el único motivo para actualizar a Paid. Ejecuta el despliegue en seco, registra Total Upload y vuelve a evaluar la decisión.

Conviene esperar si el Worker ya estaba muy por debajo del límite anterior y el pipeline de despliegue no contiene ninguna regla fija basada en gzip. El entorno de ejecución de la aplicación no ha cambiado.

Hay que seguir en Paid si lo justifican las solicitudes, el tiempo de CPU, las subsolicitudes o alguna otra función de ese plan. Poder subir un archivo más grande en Free no es motivo para trasladar una carga de producción a un plan cuyas cuotas operativas no son suficientes.

La tarea del lunes es sencilla: cambiar la comprobación de la compilación de gzip a Total Upload y decidir el plan según el uso, no según el tamaño del bundle.

Recibe el próximo cambio práctico de plataforma en el boletín.