What changed
Cloudflare changed the Workers deployment-size rule on September 4, 2026. The previous compressed bundle limits—3 MB on Free plans and 10 MB on Paid plans—have been removed. Both plans now use a 64 MiB uncompressed Worker bundle limit. Cloudflare's current tooling exposes Total Upload as the relevant size to compare with the new ceiling, while compressed size remains useful for transfer diagnostics rather than eligibility.
Why it matters
The old compressed caps could make framework choice, dependencies and generated code a deployment blocker even when runtime CPU and memory were acceptable. A 64 MiB uncompressed ceiling gives builders substantially more room and removes the plan-tier distinction, but it does not make bundle size irrelevant. Large Workers can still increase startup overhead and make deployments slower, so code and data that do not need to ship inside the Worker may still belong in static assets, KV, R2, D1 or separate services.
The plan-specific compressed caps are gone
Free and Paid Workers now share the same 64 MiB uncompressed bundle limit. That removes the old 3 MB/10 MB compressed-size boundary and makes the deployment rule easier to reason about across environments.
Measure Total Upload, not only gzip size
Cloudflare's deployment tooling reports the uncompressed Total Upload value. Builders who previously watched compressed bundle output to stay under the old cap should update CI checks and dashboards so they validate the metric Cloudflare now enforces.
More headroom does not remove architecture trade-offs
Cloudflare still recommends keeping large data and assets outside the Worker where practical. Static assets, KV, R2, D1 and Service Bindings can keep runtime code smaller and reduce the amount that must initialize with every isolate.