1.12 larger build

[ceramicunobir]

Is your feature request related to a problem?

After upgrading to opennextjs-cloudflare@1.12, my Next.js 16 project builds successfully but fails during the publish step with the following error:

19:47:55.693 ✨ Upload complete!
19:48:01.740 Success: Assets published!
19:48:09.207 Error: Failed to publish your Function. Got error:
Your Worker exceeded the size limit of 3 MiB.
Please upgrade to a paid plan to deploy Workers up to 10 MiB.

The same project builds and deploys without issues on version 1.11.
It seems that version 1.12 produces a significantly larger Worker bundle, possibly due to a change in the bundling or runtime packaging process.

🧩 Environment

Next.js: 16.x

opennextjs-cloudflare: 1.12 (works fine on 1.11)

Cloudflare Pages / Workers Free Plan

✅ Expected behavior

The build output should remain under the 3 MiB limit as it did in version 1.11.

🧠 Additional context

It might be related to updated dependencies or how @cloudflare/workers-types / wrangler handles bundling in 1.12.

Describe the solution you'd like

The build output should remain under the 3 MiB limit as it did in version 1.11.

Describe alternatives you've considered

1.12 less build size

@opennextjs/cloudflare version

1.11

Additional context

No response

Before submitting

• I have checked that there isn't already a similar feature request
• This is a single feature (not multiple features in one request)

[ceramicunobir]

Deploying with wrangler without a GitHub trigger was successful because Cloudflare's local optimizations work better.

rm -rf .next .open-next
pnpm build:cloudflare
wrangler pages deploy .open-next --project-name xxxxx

[vicb]

eploying with wrangler without a GitHub trigger was successful because Cloudflare's local optimizations work better.

It shouldn't matter.

wrangler pages deploy .open-next --project-name

Are you deploying to pages? That is not tested, the adapter is for workers, i.e. wrangler deploy.
Also you are not supposed to call wrangler commands directly, see the docs

The last point is that Next 16 is not fully supported yet.

[Antoine4011]

Hello @vicb, we're getting the same issue after testing turbopack builds with Next 15.5.6 and OpenNext 1.12.

Our builds went from :

  ✨ Success! Uploaded 30 files (1848 already uploaded) (4.26 sec)
  
  Total Upload: 39662.51 KiB / gzip: 7967.30 KiB

to:

✨ Success! Uploaded 436 files (155 already uploaded) (7.47 sec)
  Total Upload: 94694.76 KiB / gzip: 19539.39 KiB

The 5 larger assets now :

    Here are the 5 largest dependencies included in your script:
    
    - .open-next/server-functions/default/apps/nextjs/handler.mjs - 84088.71 KiB
    - .open-next/middleware/handler.mjs - 2326.15 KiB
    - ../../node_modules/next/dist/compiled/@vercel/og/resvg.wasm - 1346.05 KiB
    - ../../node_modules/@react-email/tailwind/dist/index.mjs - 649.04 KiB
    - ../../node_modules/react-dom/cjs/react-dom-server.edge.production.js - 242.46 KiB

[vicb]

Please add a repro (link to a GH repository) so that we can investigate.

[eashish93]

This is happening with turbopack build in production. If you do this, next build --webpack, the output generated will be same size as before.

[vicb]

Could somebody please share a repro (link to a GH repository) so that we can investigate?

[eashish93]

Here's the repo: https://github.com/eashish93/opennext-build-test

Without turbopack (using next build --webpack)

With turbopack (using next build)

One other thing I found is that if you build with Turbopack and deploy, node-postgres breaks on workers while postgres.js working fine. I've not included that part in repo though.

[vicb]

Thanks @eashish93 !

The repro uses 16.0.3

Investigation

Webpack

Turbopack

Some notes:

• Both versions include sharp and related dependencies - that should be removed
• The turbopack version includes og - it should only be included when needed
• The turbopack version includes app-page.runtime.prod.js (which pulls a lot of duplicated deps) - that should not be needed

There are probably more things to dig later but starting with the 3 items above should be a good start

[kiralikbeyin]

The same files are compressed to 2.5MB on Next 15, but 3.5MB on Next 16.

It would be good to consider increasing the 3MB limit to allow testing of the free CF plan.

[vicb]

It would be good to consider increasing the 3MB limit to allow testing of the free CF plan.

I don't see the point here.
If the code is unused it should (and will) not be bundled.

Large bundle sizes come with their own problem and upping the limit would not solve that.