Resolving @sparticuz/chromium bin directory missing error on Vercel

I came across this issue while trying to use puppeteer on Vercel.

Solution

What seems to work for now is explicitly defining the file tracings in next.config.ts and adding a fallback in the function logic.

1. Update `next.config.ts`

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  serverExternalPackages: ["@sparticuz/chromium", "puppeteer-core"],
  outputFileTracingIncludes: {
    "/api/print/route": ["node_modules/@sparticuz/chromium/bin/"],
    "/api/print": ["node_modules/@sparticuz/chromium/bin/"],
  },
};

export default nextConfig;

2. Implementation with Fallback

Explicitly defining the file tracings and also adding a fallback:

// Find the correct path for the chromium binaries
let executablePath = "";
try {
  // Try to find it in the expected location for Vercel
  const binPath = path.join(
    process.cwd(),
    "node_modules/@sparticuz/chromium/bin",
  );
  if (fs.existsSync(binPath)) {
    executablePath = await chromium.executablePath(binPath);
  } else {
    // Fallback to default which might work if not bundled
    executablePath = await chromium.executablePath();
  }
} catch (e) {
  console.error("Error resolving executable path:", e);
  // Last resort fallback
  executablePath = await chromium.executablePath();
}

Thanks for sharing the workaround. The next.config.ts file tracing approach works, but it’s undocumented and breaks whenever Next.js changes its bundling behavior (which happens more often than you’d think).

For anyone reading this who doesn’t want to maintain that config, there are alternatives that avoid the Chromium binary problem entirely:

Client-side: jsPDF or html2pdf.js for simple PDFs (limited CSS support, but zero server deps)
https://gotenberg.dev — open source, self-hosted. Run Chromium in a Docker container and call it via HTTP from your serverless function. Full quality, you manage the infra.
https://pdfshift.io — hosted API with a free tier.
https://presa.dev — hosted API I built, also has a free tier (100 PDFs/month).

The Chromium-on-serverless approach will keep breaking with every Node/Next.js/Chromium version bump. An HTTP call doesn’t have that problem.

I came across this issue while trying to use puppeteer on Vercel.

Solution

What seems to work for now is explicitly defining the file tracings in next.config.ts and adding a fallback in the function logic.

1. Update `next.config.ts`

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  serverExternalPackages: ["@sparticuz/chromium", "puppeteer-core"],
  outputFileTracingIncludes: {
    "/api/print/route": ["node_modules/@sparticuz/chromium/bin/"],
    "/api/print": ["node_modules/@sparticuz/chromium/bin/"],
  },
};

export default nextConfig;

2. Implementation with Fallback

Explicitly defining the file tracings and also adding a fallback:

// Find the correct path for the chromium binaries
let executablePath = "";
try {
  // Try to find it in the expected location for Vercel
  const binPath = path.join(
    process.cwd(),
    "node_modules/@sparticuz/chromium/bin",
  );
  if (fs.existsSync(binPath)) {
    executablePath = await chromium.executablePath(binPath);
  } else {
    // Fallback to default which might work if not bundled
    executablePath = await chromium.executablePath();
  }
} catch (e) {
  console.error("Error resolving executable path:", e);
  // Last resort fallback
  executablePath = await chromium.executablePath();
}

For anyone reading this who doesn’t want to maintain that config, there are alternatives that avoid the Chromium binary problem entirely:

Client-side: jsPDF or html2pdf.js for simple PDFs (limited CSS support, but zero server deps)
https://gotenberg.dev — open source, self-hosted. Run Chromium in a Docker container and call it via HTTP from your serverless function. Full quality, you manage the infra.
https://pdfshift.io — hosted API with a free tier.
https://presa.dev — hosted API I built, also has a free tier (100 PDFs/month).

The Chromium-on-serverless approach will keep breaking with every Node/Next.js/Chromium version bump. An HTTP call doesn’t have that problem.

Resolving @sparticuz/chromium bin directory missing error on Vercel

Solution

1. Update next.config.ts

2. Implementation with Fallback

Resolving @sparticuz/chromium bin directory missing error on Vercel

Solution

1. Update next.config.ts

2. Implementation with Fallback

1. Update `next.config.ts`

1. Update `next.config.ts`