What running Puppeteer in production actually involves
These are the figures the Puppeteer community itself documents, not a competitor's caricature.
Memory per instance
A Chromium instance wants roughly 200 to 500 MB; heavy documents with images and fonts push past that, and concurrent renders multiply it. Out-of-memory crashes are the classic failure.
Cold starts and lifecycle
Launching Chromium takes several hundred milliseconds before rendering begins, and something must manage launch, reuse, zombie processes and restarts, especially on serverless.
The harness is yours to build
Queueing, per-document retry, timeout handling, monitoring and horizontal scaling are not in the library; every team reimplements them around it.
Side by side
| KimiDoc | puppeteer | |
|---|---|---|
| Rendering | Chromium-class print engine | Headless Chromium |
| Output fidelity | Equivalent: modern CSS, fonts, SVG, JS | Equivalent: modern CSS, fonts, SVG, JS |
| What you operate | An API key | Browser fleet, queues, monitoring |
| Concurrency | Pooled and queued server-side | Provision and orchestrate yourself |
| Cold starts | None: the render pool is pre-warmed | Several hundred ms per launch, unless you build instance reuse |
| Batch of 40,000 documents | One request, one ZIP, per-document retry | A loop, plus everything that can fail inside it |
| Templates | Stored server-side with sample data and a live editor | String-building or a template library in your code |
| Encryption, watermarks, appending PDFs | Built in | Additional libraries and glue |
| Failure handling | Per-document status; failed documents retry without redoing the run | Crash recovery is your code |
| Cost model | Documents rendered; failures are never counted | Infrastructure, plus the engineering time |
When Puppeteer is the right choice
If you already run Puppeteer or Playwright for testing or scraping and PDFs are an occasional side output, adding a service is overhead. The same goes for low-volume internal tools, for screenshot generation, and for teams with a strict no-external-dependency policy and the engineering time to honour it. The calculus flips when document volume becomes a product feature rather than a byproduct.
Migrating from page.pdf()
- Map the options. format becomes pageSize, margin becomes marginsMm, landscape stays landscape. Backgrounds always render.
- Move headerTemplate and footerTemplate into CSS. @page margin boxes with counter(page) / counter(pages) replace them, inside the document itself.
- Replace waitUntil with an explicit signal. Call window.pdfReady() when your charts or fonts are done and render with waitForReady: deterministic, instead of network heuristics.
- Move templating server-side. Store the template once with {{placeholders}} and sample data; requests then carry only data. Batches become one job submission instead of a loop.
Questions engineers ask
Is Puppeteer bad at generating PDFs?
No. The output is fine; Puppeteer and Playwright are actively maintained. The comparison is operational: with a library you run the browsers, with KimiDoc you call an API and the pool, queue and retries are already there.
Does this apply to Playwright too?
Yes. Playwright's PDF support drives the same headless Chromium, so the memory, lifecycle and harness considerations are identical.
Can we still keep rendering on our own infrastructure?
Yes. KimiDoc self-hosted runs the same engine inside your network under a per-server licence; your data never leaves. The hosted API is the zero-ops option.
How do we try it against our real documents?
Paste a template into the editor on the free tier: previews are unmetered, and the free tier renders 100 documents a month through the API.
Related comparisons
wkhtmltopdf alternative
Archived in 2023 with a critical unpatched SSRF; KimiDoc is a maintained engine you can still run on your own servers.
PDFShift alternative
Documents instead of size-counted credits, self-hosting, and a lower price at every tier until the two meet at 50,000.
DocRaptor alternative
Web-standard rendering at a fraction of the per-document price, with self-hosting DocRaptor does not offer.
PDFBolt alternative
The same generous free tier; at paid volume KimiDoc costs less, bills annually, and can run on your servers.
All comparisons
The full list, kept factual and current.
Try it against a real document
The editor previews are free and unmetered; the free tier renders 100 documents a month through the API.