Cloudflare Workers Ends the Bundle-Size Upgrade

Cloudflare just removed bundle size as a reason to buy Workers Paid. On September 4, 2026, the old 3 MB Free and 10 MB Paid compressed checks gave way to one 64 MiB uncompressed limit across both plans, so your deployment budget now follows Wrangler's Total Upload line instead of gzip.

What Cloudflare actually changed

A Worker bundle is the code and supporting modules Cloudflare receives when you deploy. Wrangler, Cloudflare's command-line tool, builds that upload with esbuild by default, pulls in the npm packages your code imports, and reports its size.

Until September 4, Cloudflare compressed that bundle and rejected it when the compressed result crossed 3 MB on Workers Free or 10 MB on Workers Paid. That compressed check is gone.

The platform now checks one thing: the uncompressed bundle must be no larger than 64 MiB. The same limit applies to Free and Paid.

That last column is the whole mechanic. Total Upload is the uncompressed size. gzip is still printed for reference, but Cloudflare no longer uses it as a deployment gate.

Don't turn this into a neat multiplier. The old numbers measured compressed bytes in MB. The new number measures uncompressed bytes in MiB. How much extra code fits depends on how compressible your particular JavaScript, dependencies, and binary modules are.

The $5 plan decision moved

The immediate business consequence is narrow and useful. Workers Paid has a minimum charge of $5 USD per account each month. If a team planned to upgrade only because its bundle crossed the old 3 MB Free cap, that reason has disappeared as long as Total Upload stays within 64 MiB.

That doesn't make the two plans equal. Workers Free still includes 100,000 requests per day, 10 milliseconds of CPU time per invocation, and 50 subrequests per invocation. Workers Paid includes 10 million requests and 30 million CPU milliseconds per month, allows 10,000 subrequests per invocation, and can run up to 5 minutes of CPU time per request with a 30-second default.

So the budget decision gets cleaner. Pay for traffic, CPU, subrequests, and Paid-only capabilities. Don't pay merely because a compressible bundle landed above the retired Free threshold.

Teams already on Paid for real production usage won't see a direct bill reduction. Teams whose bundles already sat comfortably under the old cap won't see a workflow change either. The gain is concentrated among projects that were trimming, splitting, or upgrading because of deployment size.

For the rest of the account and runtime math, the broader Cloudflare review lays out how Workers fits beside Cloudflare's other plan and usage charges. Its old bundle-limit figures are the part this September change replaces.

Four builds that get easier

A solo SaaS founder can keep plan choice separate from framework choice

Say you're shipping a full-stack application on Workers Free. A framework adapter, server rendering code, and production dependencies can produce a bundle that compresses beyond the old Free cap even when the application's traffic still fits Free.

You can now judge that build against 64 MiB Total Upload. If it fits, bundle size alone doesn't force the $5 Paid minimum. The payoff isn't free production at any scale. It's the ability to validate demand before paying for runtime usage you don't need yet.

An agency can delete the wrong CI gate

An agency build lead may have copied the old gzip threshold into every client repository. Leaving that check in place creates failed builds against a rule Cloudflare no longer enforces.

Replace it with an uncompressed Total Upload check and choose an internal ceiling below 64 MiB for headroom. Client projects then fail for the current platform constraint, not a historical one.

A Rust or WebAssembly team gets more room, not a new runtime

WebAssembly, usually shortened to Wasm, lets a Worker run binary code compiled from languages such as Rust, Go, or C. Cloudflare notes that Wasm Workers are typically larger than equivalent JavaScript Workers because the binary often carries extra runtime dependencies.

The larger deployment allowance gives that team more room for a Wasm module and its surrounding code. Wrangler supports .wasm and .wasm?module uploads directly. Size optimization still matters, and Cloudflare recommends wasm-opt for reducing the binary.

A platform team can retire workaround architecture

A platform engineer on Workers Paid may have split a coherent service, removed a useful dependency, or built a custom external-module path just to stay below 10 MB compressed. That decision deserves a fresh review.

Some splits should remain because they create clean ownership or failure boundaries. A split that exists only for the retired upload check is now complexity without a platform requirement behind it.

Check the real bundle before the next deploy

You don't need to guess from the size of node_modules, your source directory, or the archive produced by a separate framework build. Run Wrangler's dry deploy from the Worker project so it builds the artifact Cloudflare would actually receive.

1. 1

   Build without deploying

   Run Cloudflare's documented dry-run command:

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

   Wrangler builds the Worker and writes the output locally without deploying it.

2. 2

   Read Total Upload

   Find Total Upload in the command output. That is the uncompressed bundle size Cloudflare now checks against 64 MiB. Keep gzip for diagnostic context if it helps, but don't use it as the platform pass or fail number.

3. 3

   Change the CI budget

   Replace any 3 MB Free or 10 MB Paid compressed-size rule with a Total Upload rule. Set your team's own ceiling below the platform maximum so one dependency update doesn't consume every byte of headroom.

4. 4

   Watch startup on the real deploy

   On the next normal deployment or version upload, record Wrangler's startup_time_ms output. A bundle can fit the upload limit and still fail Cloudflare's separate startup check.

The common mistake is watching the smaller-looking gzip value because that used to decide the deploy. It doesn't anymore. Total Upload is now the budget line.

The honest limits didn't get 64 MiB larger

Larger bundles can take longer to parse and initialize. Code that does expensive work at global scope, meaning outside the request handler, can still fail validation with Script startup exceeded CPU time limit and error code 10021. A deploy under 64 MiB is allowed through the size gate, not promised a healthy startup.

This matters most for heavy frameworks and Wasm. The old limit often stopped the upload first. The new limit lets more code reach the next constraint, where memory and initialization behavior become visible.

If a Worker is still too large, the current docs give three practical exits:

• Remove packages and dependencies the deployed path doesn't use.
• Keep configuration, static assets, and binary data in Workers Static Assets, KV, R2, or D1 instead of the Worker bundle.
• Split functionality across Workers with Service Bindings.

Service Binding calls don't add a second request fee. Cloudflare bills the initial Worker invocation and the total CPU time used across the Workers involved. That makes a split a workable size tool, but you should still accept the extra service boundary deliberately.

What to do on Monday

Act this week if a Worker recently failed the old size check, if your team trimmed framework dependencies to stay under it, or if bundle size was the only reason attached to a Paid upgrade. Run the dry deploy, record Total Upload, and reopen that decision.

Wait if your Worker was already far below the old limit and your deployment pipeline has no hard-coded gzip gate. Nothing about the application's runtime changed.

Stay on Paid if requests, CPU time, subrequests, or another Paid capability justify it. A bigger Free upload limit isn't a reason to move a production workload onto a plan whose operating quotas don't fit.

The Monday move is simple: change the build check from gzip to Total Upload, then make the plan decision from usage instead of bundle size.

Get the next practical platform change in the newsletter.