Trying to use puppeteer in vercel deployment

[abhishekmg]

Summary

I am trying to use puppeteer to launch a chrome browser in next js api , but this is not working when I deploy to Vercel. This is working in my local machine which is a mac using Apple M1 and macos monterey.

The vercel node version is 20

The code can be found in this repo https://github.com/abhishekmg/screenshot-test

The screenshot logic is in src/api/route.js

Iam getting this error when I push to vercel

import { launch } from "puppeteer";

const takeScreenshot = async (url) => {
  // this works on my local machine
  const browser = await launch();

  const page = await browser.newPage();

  await page.goto(url, { waitUntil: "load" });

  const buffer = await page.screenshot();

  await page.close();
  await browser.close();

  return buffer;
};

export async function GET(request) {
  const buffer = await takeScreenshot(
    "https://www.npmjs.com/package/puppeteer"
  );

  return Response.json({ data: buffer });
}

I tried using chrome-aws-lamda as mentioned https://github.com/orgs/vercel/discussions/124, but still facing issues

Example

https://github.com/abhishekmg/screenshot-test

[nicnocquee]

I tried this last year and it worked https://github.com/nicnocquee/instagram-puppet/tree/main but need to use the specific version of the chrome-aws-lambda and puppeteer-core

[abhishekmg]

I tried with the versions of the chrome-aws-lambda and puppeteer-core mentioned in the repo but I still get the same error 😭

[nicnocquee]

sorry bout that, it worked last year 😅

[abhishekmg]

no problem ! it might be because Vercel linux machines this past year , but to exactly sure

[estyxx]

Hey, did you find any solution?

[galbahar]

any solution?

[subhadeeproy3902]

any solution ?

[vieiralucas]

This is a recurring issue — Puppeteer works locally because you have Chrome installed, but Vercel's serverless environment doesn't include it. The @sparticuz/chromium workaround helps but is fragile (breaks across Node/Next.js version bumps, hits bundle size limits).

If you're primarily generating PDFs rather than doing browser automation, there are alternatives that skip Chromium entirely:

• Gotenberg — open source, self-hosted in Docker. Full rendering quality, you manage the container.
• PDFShift — hosted API, free tier.
• Presa — hosted API I built, free tier (100 PDFs/month).

You send HTML, get a PDF back — no Chromium binary needed in your Vercel function:

import { PDF } from "presa-sdk";
const { buffer } = await PDF.generate({ html, format: "A4" });

Deploys to Vercel without issues since it's just an HTTP call.

[JEETJM]

When deploying Next.js with Puppeteer on Vercel, the issue usually happens because Vercel serverless functions do not include a full Chromium environment.

A common solution is to use puppeteer-core together with chrome-aws-lambda, which works better in serverless environments.

Steps you can try:

1. Install required packages:
   npm install puppeteer-core chrome-aws-lambda

2. Update your code to launch Chromium correctly in a serverless environment.

Example:

import chromium from "chrome-aws-lambda";
import puppeteer from "puppeteer-core";

export default async function handler(req, res) {
  const browser = await puppeteer.launch({
    args: chromium.args,
    executablePath: await chromium.executablePath,
    headless: chromium.headless
  });

  const page = await browser.newPage();
  await page.goto("https://example.com");

  const title = await page.title();

  await browser.close();

  res.status(200).json({ title });
}

[icyJoseph]

There's a guide here:

• https://vercel.com/kb/guide/deploying-puppeteer-with-nextjs-on-vercel
• Source code: https://github.com/gabenunez/puppeteer-on-vercel

[maxcomperatore]

This error happens because Vercel Serverless Functions execute inside lightweight container environments with strict uncompressed size limits (50MB–250MB) and stripped system libraries (no ALSA, NSS, or Mesa graphics drivers needed by Chromium).

While @sparticuz/chromium is a popular workaround, it tends to be fragile across Node runtime upgrades and frequently hits lambda package limits.

If your core goal in Next.js is document generation (creating PDF invoices, tickets, contracts, or reports) rather than scraping external websites:

1. Avoid bundling headless browsers into Vercel functions: A headless browser binary is 500MB+ and incurs a 2–4 second cold start penalty.
2. Decouple document generation from your edge/serverless routes: Calling a dedicated typesetting service over HTTP keeps your Next.js bundle tiny and deploys reliably. For instance, we built and open-sourced Rubrol (Rust + Typst engine) which compiles structured JSON into PDFs in under 10ms with sub-30MB RAM footprint. You can run it on Fly.io, Railway, or a minimal container and call it from your Next.js Route Handler:

export async function POST(req: Request) {
  const data = await req.json();
  const res = await fetch("https://your-doc-engine.internal/compile", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  });
  const pdfBuffer = await res.arrayBuffer();
  return new Response(pdfBuffer, {
    headers: { "Content-Type": "application/pdf" },
  });
}

This keeps your Next.js deployments lightweight, deterministic, and free of browser layer crashes.