Cloudflare Workers replace compressed bundle caps with a 64 MiB limit

Cloudflare has changed the size rule that governs Worker deployments. The previous compressed-bundle caps—3 MiB on Free and 10 MiB on Paid—have been removed. Wrangler now checks a single 64 MiB uncompressed limit across all plans.

That matters most for applications with large dependency trees, heavier frameworks, generated assets, or bundled runtime code. A deployment that previously failed because gzip output crossed a plan-specific threshold can now succeed if the uncompressed bundle remains within 64 MiB.

Cloudflare’s new Worker size rule

Cloudflare says the old check measured the compressed bundle after Wrangler packaged the Worker. The new rule measures the uncompressed total instead. Compression is still shown in deployment output, but gzip size no longer determines whether the upload is accepted.

The change applies to both Free and Paid plans. It is a limit change, not a change to the Worker runtime’s CPU, memory, request, or storage quotas. Teams should therefore treat it as more room for deployment packaging, rather than as a general increase to runtime capacity.

Cloudflare’s example shows wrangler deploy --outdir bundled/ --dry-run as the preflight command. The resulting Total Upload value is the number to compare with the 64 MiB ceiling; the displayed gzip value is informational.

What changes for larger applications

The practical effect is a simpler and more predictable deployment calculation. Free users no longer face a 3 MiB compressed ceiling, while Paid users no longer need to account for the separate 10 MiB compressed threshold. This can reduce deployment failures caused by framework upgrades or dependency additions that compress inefficiently.

The uncompressed limit can still expose a different failure mode. A package may compress well and remain below the old gzip thresholds while expanding beyond 64 MiB at upload time. Build pipelines should record both values and fail early when the uncompressed total approaches the platform limit.

For teams using monorepos or generated code, the safe workflow is to inspect the bundled output produced for the Worker rather than the repository size. Remove unused dependencies, split optional features where possible, and keep the dry-run check in CI so a dependency update cannot turn into a production deployment surprise.

Rollout evidence and remaining limits

Cloudflare’s September 4 changelog entry documents the new 64 MiB rule and the removal of both compressed caps. An independent release index records the same change as a breaking Workers update and repeats the Free/Paid thresholds and the uncompressed measurement. That corroboration supports the platform-wide scope, while Cloudflare remains the authority for the exact limit and deployment behavior.

The change does not automatically make every large application suitable for Workers. Runtime constraints, startup behavior, module compatibility, asset handling, and downstream service limits still apply. Check the generated bundle size with Wrangler, then validate the Worker under the target compatibility date before relying on the larger deployment envelope.

For practical deployment patterns around agent and serverless workflows, see LinkLoot’s AI workflow automation guide.