lambda@edge error: generated response size exceeds 1 MB

Not specified by the original author.

TL;DR

Lambda@Edge caps generated responses at 1 MB. Functions that build large pages, bundle assets, or proxy big origin bodies hit the wall. Shrink the response (paginate, compress, stream via origin), or move the heavy lifting to the origin and keep the edge function to headers and routing.

The query

lambda@edge error: generated response size exceeds 1 MB

Use this when

• The edge function fails on large responses.
• It works for small pages and fails for big ones.
• The function proxies or generates the body itself.

Not for

• Deployment package size limits (different limit).
• Function timeouts (duration problem).
• CloudFront distribution config errors (config problem).

Steps

Step 1: Measure the response size

Log the byte length of the body the function returns.

Expected result: the failing responses measure over 1 MB. Size, not content, is the blocker.

Step 2: Stop generating big bodies at the edge

Return a redirect or a small placeholder from the edge function and let the origin or S3 serve the large content directly.

Expected result: the edge response stays tiny. The heavy bytes never pass through the function's response path.

Step 3: Compress and paginate where the edge must respond

If the edge function must build the body, enable compression and paginate large datasets so no single response exceeds the cap.

Expected result: responses fit. Clients reassemble pages as needed.

Step 4: Use origin-response triggers for transformation, not generation

Transform the origin's response (headers, small rewrites) instead of replacing the body wholesale.

Expected result: the large body flows from the origin; the function only touches what it must.

Step 5: Verify with the largest real payload

Expected result: the biggest production response passes. Add a size assertion so growth re-triggers an alert, not an outage.

Why it happens

Lambda@Edge runs at CloudFront edge locations with strict response budgets for latency. The 1 MB cap keeps edge responses fast. Functions written like origin servers (render everything, return everything) work until the first large payload.

Edge cases

• The limit applies to the generated response, not to origin passthrough. Proxying without buffering avoids it.
• Viewer-request triggers cannot generate large bodies at all; use origin-facing triggers for body work.
• Compression counts: the cap applies to the final encoded response. Compress before measuring.
• CloudFront Functions (the lighter alternative) have even smaller limits; do not 'fix' this by switching runtimes without checking.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHNzUJacykQ5b-IEObyGWQ

Resolved from the public thread: https://vectle.com/posts/pstHNzUJacykQ5b-IEObyGWQ

Thread query: lambda@edge error: generated response size exceeds 1 MB

TL;DR: Lambda@Edge caps generated responses at 1 MB. Functions that build large pages, bundle assets, or proxy big origin bodies hit the wall. Shrink the response (paginate, compress, stream via origin), or move the heavy lifting to the origin and keep the edge function to headers and routing.

Not specified by the original author.

The Edge Function exceeds the maximum size limit of 1 MB (Vercel)

TL;DR: your middleware or edge route bundles more than the edge size cap (1 MB on Hobby after gzip, 2 MB on Pro, 4 MB on Enterprise) and the deploy is rejected. Edge code has to stay tiny: audit what middleware.ts imports, drop heavy libs (charting, 3D, UI kits) from the edge path, and narrow the matcher so the edge bundle does not drag in page code. There is no config to raise the cap on Hobby.

The Edge Function "middleware" is 1.13 MB which exceeds the maximum size limit of 1 MB.

1. See what the edge bundle pulls in

The error names the function. Check its imports: middleware.ts (or any route with runtime = 'edge') bundles everything it touches. Common bloat: UI kits, charting/3D libs, date libraries with all locales, SDKs meant for Node.

Expected: you find one or two imports responsible for most of the megabytes.

2. Keep heavy libs out of the edge path

Move anything heavy behind a serverless route or a client component:

• Auth/session checks in middleware: keep, but import only the tiny edge-safe helper, not the full SDK
• Charting, 3D, PDF, image libs: these do not belong in edge code, move them to API routes or the client
• import ... from 'lib' pulling a whole barrel file: import the single module path instead

Expected: the reported edge function size drops under the cap.

3. Narrow the matcher

A middleware with no matcher (or a /(.*) matcher) bundles against every route. Scope it to the paths that need it:

export const config = {
  matcher: ['/dashboard/:path*', '/account/:path*'],
};

Expected: the edge bundle only includes code reachable from the matched routes.

4. If it still does not fit, move off the edge runtime

Some logic genuinely needs Node APIs or big deps. For those routes, drop runtime = 'edge' and run on Node.js serverless functions (250 MB cap, much more headroom). Keep middleware itself minimal: redirect, rewrite, or header tweaks only.

Expected: the route deploys as a serverless function; middleware stays under 1 MB.

When this applies

• Vercel deploy fails with the edge function size error
• The named function is middleware or a route with runtime = 'edge'
• Next.js on Vercel, any plan

When it does not apply

• A Serverless Function has exceeded the unzipped maximum size of 250 MB: the Node.js function limit, different fixes
• Edge runtime errors at request time (those are invocation failures, not size)
• Middleware that is small but crashes: check for Node-only imports instead

Compatibility

Vercel Edge Functions: 1 MB cap on Hobby, 2 MB on Pro, 4 MB on Enterprise, measured after gzip. Next.js middleware (middleware.ts) always runs on the edge runtime. Applies to Next.js 12.2+ middleware and any runtime = 'edge' route.

Why it happens

Edge functions run on V8 isolates distributed worldwide, so Vercel caps their size hard. Your middleware bundles every import transitively, and one heavy library (a UI kit, three.js, a full SDK) is enough to push a 50 KB middleware past 1 MB. next/dynamic does not help here because the edge bundle is built at deploy time, not lazily.

Edge cases

• The size in the error varies (1.13mb, 2.4 MB): same error, the cap is what matters.
• On Pro the cap is 2 MB: if you are at 1.5 MB, upgrading buys room, but slimming is still cheaper.
• Barrel imports (import { x } from 'huge-lib') defeat tree-shaking on the edge; import the deep path.
• Middleware must also avoid Node-only APIs (fs, crypto.createHash); those fail differently, at runtime.

A real bug report on vercel/next.js (issue 32907) shows the exact failure: The Edge Function "map" is 1.13mb which exceeds the maximum size limit of 1mb. The reporter was pulling in three.js, d3, material-ui and accessibility libs through their edge code, and the 1 MB cap killed the deploy even after trying next/dynamic and tree-shaking. The confirmed direction from the thread and current Vercel limits: edge functions are capped at 1 MB on Hobby (2 MB Pro, 4 MB Enterprise, measured after gzip), so the fix is to shrink what the edge bundle imports, keep middleware to edge-safe code only, and narrow its matcher. Full thread: https://github.com/vercel/next.js/issues/32907

Not specified by the original author.

TL;DR

A single KV value cannot exceed 25 MiB. Payloads bigger than that (large JSON exports, bundled assets, big cached pages) must move to R2, which is built for large objects, with KV holding only a pointer or metadata. Split the write path: big bytes to R2, small metadata to KV.

The query

workerd error: KV value exceeds 25 MiB on put

Use this when

• KV put fails naming the value size.
• Caching full pages, API responses, or generated files in KV.
• The failure started as content grew.

Not for

• 'KV key length exceeds 512 bytes' (key limit, separate fix).
• R2 write failures (different service).
• Slow KV reads (performance problem, not a limit error).

Steps

Step 1: Measure the payload at write time

Log the byte length of the value before the put.

Expected result: the failing values measure over 25 MiB. You now know the write path must change, not the limit.

Step 2: Move large values to R2

await env.BUCKET.put(objectKey, bigBytes);
await env.KV.put(metaKey, JSON.stringify({ r2Key: objectKey, size: bigBytes.byteLength, type: contentType }));

Expected result: the large bytes live in R2, and KV holds a tiny metadata record.

Step 3: Update the read path

const meta = JSON.parse(await env.KV.get(metaKey));
const obj = await env.BUCKET.get(meta.r2Key);
return new Response(obj.body, { headers: { "content-type": meta.type } });

Expected result: reads follow the pointer. Both shapes (direct small values in KV, pointer records) should be handled during migration.

Step 4: Decide the size threshold

Route values over roughly 1 MiB to R2 even though KV allows 25 MiB. KV is optimized for small fast reads; large values are slower and costlier there.

Expected result: a single constant in the write path decides KV vs R2. Future growth never re-triggers the error.

Step 5: Backfill or expire old entries

Expected result: oversized values already in KV are migrated or left to expire. New writes cannot exceed the threshold.

Why it happens

KV is a low-latency key-value store for small values: flags, sessions, redirects, small JSON. Teams reach for it as a general blob store because the API is simple, and it works until the first large payload. R2 exists precisely for the large-object case.

Edge cases

• KV list and bulk operations also slow down with large values. The R2-pointer pattern fixes those too.
• Compressing the value buys headroom but not a fix; content keeps growing. Compress AND route by size.
• R2 objects need their own lifecycle rules; KV expiration does not cascade. Set matching expirations on both sides.
• During migration, readers must handle both shapes: raw KV values and pointer records.

Provenance

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

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

Thread query: workerd error: KV value exceeds 25 MiB on put

TL;DR: A single KV value cannot exceed 25 MiB. Payloads bigger than that (large JSON exports, bundled assets, big cached pages) must move to R2, which is built for large objects, with KV holding only a pointer or metadata. Split the write path: big bytes to R2, small metadata to KV.