Consolidated notes on sharp/native-module deploy failures on Vercel

Help
,
1

Disclosure up front: I’m not a Vercel employee, this isn’t sponsored by anyone, and I haven’t personally hit every variant below. I put this together because the same failure keeps showing up in different threads here and on GitHub, with the same root cause and no single place that collects the known causes and fixes. If I’ve got something wrong, please correct it in the replies — that’s the point of posting it rather than just filing it away somewhere.

The failure, in short: sharp (and less commonly canvas, bcrypt, sqlite3) builds and runs fine locally, then fails at deploy/runtime on Vercel or another serverless platform with something like “Could not load the ‘sharp’ module using the linux-x64 runtime”, an ERR_DLOPEN_FAILED on a libvips binary, or a similar native-binding load error. This is not a bug that got fixed once and stayed fixed — it recurs across sharp versions, most recently against 0.35.3, the current stable release (published 2026-07-01), because the underlying cause is structural: the machine that builds your project and the machine that runs it don’t always end up with matching native binaries, and npm’s optional-dependency resolution for platform binaries doesn’t always download the right one.

Where this is documented (going to the source, not paraphrasing) — newest first:

  • lovell/sharp#4567 — opened 2026-07-06, still open. sharp 0.35.3 failing on Vercel with Next.js 16 Server Actions under Turbopack: ERR_DLOPEN_FAILED: libvips-cpp.so.8.18.3. This is against the version whose own changelog claims improved bundler support — the failure recurred 5 days after that release shipped.
  • lovell/sharp#4543 — opened 2026-06-12, closed 2026-06-19 as “completed.” sharp 0.35.0, Vercel Serverless Functions couldn’t find @img/sharp-libvips-linux-x64 at runtime. Fixed quickly — then a new instance of the same failure class (#4567, above) reappeared against the very next patch, two weeks later. That two-issue pattern is the actual evidence for “structural and recurring,” not a one-off.
  • lovell/sharp#3870, #2230 — older reports of the same linux-x64 load failure against earlier sharp versions. Cited here as historical pattern evidence (this has been happening for a long time, in different forms), not as current open reports.
  • An earlier thread on this forum ( Deploy of next.js project to Vercel fails because of sharp ) — someone hitting this in November 2024. Older than the GitHub reports above; included to show it’s been surfacing here too, not as current evidence — see #4567 for that.
  • vercel/vercel#14001 — Vercel’s own platform-side tracking issue for this failure class. Opened 2025-09-27, closed 2026-03-03 as “completed.” Noting it here as historical context, not as a live tracker. The fact that it closed and the failure is still recurring five months later (#4567) is itself part of the pattern worth naming plainly.

What’s actually been reported to fix it (again, sourced from the threads above and the free workarounds people have already written up — none of this is new or mine):

  1. Delete node_modules and any lockfile-cached platform binary, then reinstall with the target platform explicitly forced: npm install --os=linux --cpu=x64 sharp (or the pnpm/yarn equivalent). Doing this without first clearing the existing install is the most commonly reported reason it appears not to work.
  2. Pin sharp to the last known-good minor version instead of upgrading immediately — in both #4543 and #4567 above, downgrading rather than staying on the newest release is what reporters said actually resolved the failure for them. Worth trying before or alongside the platform-forced install above.
  3. Make sure --include=optional isn’t being skipped by an .npmrc or CI cache that strips optional deps.
  4. If you’re on a monorepo or custom build image, check whether the build step and the runtime step are actually the same architecture — mismatches between an arm64 dev/build machine and Vercel’s x64 Lambda runtime are a frequent silent cause.
  5. For persistent cases, a manual Lambda layer ( GitHub - cbschuld/sharp-aws-lambda-layer: Prebuilt Sharp AWS Lambda Layer for Node.js 18, 20, and 22. Optimized, bundled, and minified Sharp binaries for x86_64 and arm64 architectures. Improve cold starts with lightweight Sharp builds, ready for Serverless Framework, AWS SAM, and SST deployments. · GitHub ) sidesteps the bundling problem entirely by shipping the binary outside the function package.
  6. None of the above is guaranteed — several people in the threads above report needing more than one of these together.

Two honest questions, not a pitch: I don’t have a product and I’m not selling anything. If you’ve hit this: did any of the above actually fix it for you, or did you land on something not listed here? And separately — once you’ve hit this and fixed it once, is it actually annoying the next time it happens on a different project (like the #4543 → #4567 pattern above suggests it can be), or is it a one-time tax you fix and never think about again? Genuinely trying to understand which one this is.