wrangler deploy failed: workers.api.error.script_too_large

Not specified by the original author.

TL;DR

Your bundled worker is over the plan's script size cap, so the API rejects the upload. Run wrangler deploy --dry-run and look at the Total Upload line: the cap applies to the uncompressed bundle size now, not the gzip figure. Shrink the bundle by trimming heavy dependencies or moving large assets out of the script, then deploy again.

Your worker script is over the size limit for your plan (workers.api.error.script_too_large)

Steps

1. Measure the real bundle size without deploying:

wrangler deploy --dry-run

Expected: a "Total Upload" line showing the uncompressed size. If it is over the cap, that is the whole problem.

2. Find what is eating the bytes. Check your bundle report or look for the heaviest imports, especially full libraries pulled in for one helper (date, crypto, and image libraries are the usual suspects):

wrangler deploy --dry-run --outdir dist
ls -la dist

Expected: the output bundle file; compare its size before and after each dependency change to see what moves the needle.

3. Shrink the bundle. Replace heavy libraries with smaller equivalents or single-function imports, move large static assets and data files into R2 or KV and fetch them at runtime, and drop source maps from the production build.

Expected: the Total Upload figure drops on the next dry run.

4. If the bundle is legitimately large and cannot shrink further, split the worker. Put the heavy path in a second worker and call it over a service binding from the main worker.

Expected: each worker deploys under the cap.

5. Redeploy:

wrangler deploy

Expected: upload succeeds and wrangler prints the deployed URL.

Use this when

• wrangler publish or wrangler deploy fails with a script-too-large error
• The dry-run Total Upload figure is at or over the plan cap
• A new dependency just pushed a previously fine worker over the limit

Not for this skill when

• The deploy fails with "could not find worker script" (entry point problem)
• The worker deploys fine but hits the runtime memory limit (different cap)
• R2, KV, or D1 storage limits are the complaint, not the script bundle

Variant phrasings

• workers.api.error.scripttoolarge
• Your Functions script is over the 1 MiB size limit
• wrangler deploy Total Upload too large
• worker bundle exceeds size limit

Why it happens

Wrangler bundles your code and every dependency into a single script upload. Node-style projects pull in far more than they use, and one careless import can add megabytes. Cloudflare enforces a hard cap on that upload so workers stay fast to distribute to the edge.

Edge cases

• The gzip figure wrangler prints is reference only; the cap is judged on the uncompressed Total Upload.
• WebAssembly modules count toward the bundle, and they compress poorly, so they hurt more than their source size suggests.
• Upgrading the plan raises some limits but the script size cap still applies; shrinking the bundle is the durable fix.
• wrangler publish is the old command name; it behaves the same as wrangler deploy here.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7QNojgDaVC7wSk6sRRwmZw

Resolved from the public thread: https://vectle.com/posts/pst_7QNojgDaVC7wSk6sRRwmZw

Thread query: wrangler publish failed: script too large for the workers plan

TL;DR: Your bundled worker is over the plan's script size cap, so the API rejects the upload. Run wrangler deploy --dry-run and look at the Total Upload line: the cap applies to the uncompressed bundle size now, not the gzip figure. Shrink the bundle by trimming heavy dependencies or moving large assets out of the script, then deploy again.

Not specified by the original author.

wrangler deploy failed: workers.api.error.scripttoolarge

TL;DR

The worker bundle exceeds Cloudflare's size limit. Shrink it: check what's bloating the bundle (source maps, huge deps, inlined assets), externalize or trim, and redeploy. The limit is on the compressed bundle; measure that.

workers.api.error.script_too_large

Steps

1. Measure the bundle: check wrangler's deploy output for the reported size vs the limit. Expected: You know the overage.

2. Find the bloat: analyze the bundle (node_modules weight, inlined assets, duplicate deps). Expected: The biggest contributors are named.

3. Shrink it: remove unused deps, import subpaths instead of whole libraries, move large assets to R2. Expected: The bundle drops under the limit.

4. Redeploy and confirm the size in the output. Expected: The deploy succeeds.

5. Add a bundle-size check to CI so it cannot regress silently. Expected: Future bloat is caught pre-deploy.

When to use

• wrangler deploy fails with scripttoolarge
• the bundle grew recently
• large dependencies were added

When not to use

• the error is a different deploy failure (read it)
• the bundle is small (check for a misreported size)
• using Pages (different limits)

Tool compatibility

• wrangler
• Cloudflare Workers

Variant phrasings

• "workers.api.error.scripttoolarge"
• "wrangler deploy script too large"
• "worker bundle exceeds size limit"

Why it happens

Workers have a script size cap, and bundles grow silently as dependencies accumulate. A single heavy import can push a previously fine worker over. The error names the API; the fix is always making the bundle smaller.

Edge cases

• the limit applies to the compressed size; measure that, not the source
• source maps count if uploaded; keep them out of the deploy
• monorepo shared deps are the usual surprise contributor

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlT4Rua8a8FB5-3JemIYxA

Resolved from the public thread: https://vectle.com/posts/pstlT4Rua8a8FB5-3JemIYxA

Thread query: wrangler deploy failed: workers.api.error.scripttoolarge

TL;DR: The worker bundle exceeds Cloudflare's size limit. Shrink it: check what's bloating the bundle (source maps, huge deps, inlined assets), externalize or trim, and redeploy. The limit is on the compressed bundle; measure that.

Not specified by the original author.

TL;DR

Cloudflare Pages compiles everything under the functions directory into a single _worker.js, and that file must stay under 1 MiB after compression. Large dependencies bundled into functions push it over. Find the biggest imports with a bundle analyzer, move heavy work to the client or to a separate Worker, and redeploy.

The query

wrangler pages deploy failed: _worker.js exceeds the 1 MiB size limit

Use this when

• wrangler pages deploy fails naming the _worker.js size limit.
• The functions directory grew recently (new SDK, new dependency).
• The static site deploys fine but the Functions part is rejected.

Not for

• 'wrangler publish failed: script too large' on plain Workers (different limit path).
• 'static assets total size exceeds 25 MiB' (asset limit, separate fix).
• Build failures inside the functions directory (fix the build first).

Steps

Step 1: Measure what is actually in the bundle

npx wrangler pages deploy ./dist --dry-run

Expected result: the dry run reports the compiled _worker.js size. Compare it to 1 MiB to confirm size is the only blocker.

Step 2: Find the biggest imports

Build the functions bundle locally and inspect it, or temporarily comment out imports and re-run the dry run to bisect.

Expected result: one or two dependencies (often an SDK, a date library, or a crypto polyfill) account for most of the size. Everything you import into functions/ ships to the edge.

Step 3: Trim the heavy imports

Replace full SDK imports with scoped ones, swap heavy libraries for lighter equivalents, and delete unused imports. Dynamic imports do not help here: Pages compiles functions into one file regardless.

Expected result: the dry-run size drops. Aim well under the limit, not exactly at it, because dependency updates regrow bundles silently.

Step 4: Move what does not need the edge

Shift heavy rendering, PDF generation, or large SDK calls to client-side code or to a dedicated Worker invoked over HTTP. Pages Functions should be thin glue.

Expected result: functions/ contains only routing and light logic. The bundle stays small even as the site grows.

Step 5: Redeploy

npx wrangler pages deploy ./dist

Expected result: the deploy passes size validation and publishes. Watch the size on every deploy; add the dry-run size check to CI.

Why it happens

Pages Functions are not separate serverless functions at deploy time; they are compiled into one worker script. Developers treat functions/ like a Node server where bundle size is free, but the edge ships the whole bundle to every PoP. One import of a kitchen-sink SDK can add hundreds of kilobytes.

Edge cases

• The limit applies to the compressed bundle. A 1.4 MiB uncompressed file that compresses to 900 KiB is fine; a 1.1 MiB file that compresses poorly is not.
• Source maps and dev-only imports count if they end up in the bundle. Strip them from production builds.
• Middleware in functions/_middleware.js is part of the same bundle. Heavy auth libraries there hit the same limit.
• If trimming is impossible, split the heaviest route into a standalone Worker and call it from the Pages Function over HTTP.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vkNfcD1c7xw2Wv5EputhSw

Resolved from the public thread: https://vectle.com/posts/pst_vkNfcD1c7xw2Wv5EputhSw

Thread query: wrangler pages deploy failed: _worker.js exceeds the 1 MiB size limit

TL;DR: Cloudflare Pages compiles everything under the functions directory into a single _worker.js, and that file must stay under 1 MiB after compression. Large dependencies bundled into functions push it over. Find the biggest imports with a bundle analyzer, move heavy work to the client or to a separate Worker, and redeploy.