Chromium does not fit in an AWS Lambda deployment package

What is actually happening

A full browser build is several hundred megabytes and the unzipped package limit is 250MB. This is why a genre of size-reduced browser packages exists. Even when it fits, the cold start has to load that binary before your code runs, which is seconds of latency on the first request after every scale-up.

Confirming it is this and not something that looks like it

Compare your unzipped package size against the limit. This one is arithmetic rather than diagnosis.

The fix

Move the render out of the function. A Lambda that makes an HTTP call has a package measured in kilobytes, a cold start measured in milliseconds, and no binary to keep compatible with the runtime as it is upgraded.

// The whole function. No layer, no binary, no cold start penalty.
export const handler = async (event) => {
  const html = await buildDocument(JSON.parse(event.body));

  const upstream = await fetch("https://api.pdfpipe.xyz/v1/pdf", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.PDFPIPE_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ html, options: { format: "A4", printBackground: true } }),
  });

  return {
    statusCode: 200,
    isBase64Encoded: true,
    headers: { "Content-Type": "application/pdf" },
    body: Buffer.from(await upstream.arrayBuffer()).toString("base64"),
  };
};

If that was not it

These produce the same symptom often enough to be worth ruling out before assuming the fix above did not work.

• A layer that fits but pushes the total past the limit when combined with your dependencies
• The /tmp limit, which a browser will use for its own scratch space
• Function memory sized for JSON, where a browser needs an order of magnitude more
• The same limits, at different numbers, on other serverless platforms

Frequently asked

Related failures

Problems people arrive at from the same starting point, or mistake for this one.