Why does every PDF API boot an entire Chrome browser to render an invoice?

Delwire — Thu, 20 Aug 2026 23:39:27 +0000

Most HTML-to-PDF services run headless Chromium farms. That works, but
it's heavy. Cold starts, big containers, and for invoice-shaped documents
it's overkill. I wanted to see how far pure JS could go, so I built the
render engine for DocPuffin on pdf-lib instead.

The model is template + data, not HTML. You POST a template id and a JSON
payload, the function lays out the document programmatically and streams
the PDF back:

curl -X POST https://docpuffin.com/api/render \
  -H "Content-Type: application/json" \
  -d '{"template":"invoice-eu","data":{"invoice":{"number":"2026-1042"}}}'

Server-side render time is about 35ms because there's no browser to boot,
just deterministic layout code. The function is pinned to fra1, Frankfurt,
and nothing is stored. The payload lives in memory for the render and
then it's gone. That matters to me because the documents I generate are
full of European customer data and I'd rather they never cross the
Atlantic.

The first templates are an EU-style invoice and a receipt, with fields
mapped the way Fortnox and Visma workflows expect them. Org numbers, VAT
rates, payment references. I'm in Sweden, that's the paperwork I know.
These mappings are a formatting convenience, to be clear, not tax or
compliance advice.

You can try the real engine on the landing page. The demo box calls the
same function the API exposes. Edit the JSON, hit render, download the
PDF. Try to break it. Oversize payloads, bad JSON and unknown templates
should all come back as clean 4xx errors, and if you find a way to make
it do something uglier I genuinely want to know.

Where this honestly is: preorder stage. The engine is live, but API keys,
docs and the template editor ship in the coming weeks. I'm selling
founding credit packs first, $39 once for 5,000 renders, refundable until
launch with one email, because I'd rather find out from real developers
whether this deserves to exist before building the rest of it. Credits
rather than a subscription, because bursty workloads shouldn't pay
monthly rent.

What I'd love from dev.to: which document types you'd actually need
beyond invoices and receipts, and whether template + JSON is the right
abstraction or you'd rather bring your own HTML.

https://docpuffin.com/?utm_source=devto&utm_campaign=gate-b

DEV Community: Delwire

Why does every PDF API boot an entire Chrome browser to render an invoice?