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.
Top comments (1)
Template + JSON seems a good fit for invoices if the overflow behavior is part of the template contract. I'd want a fixture with enough line items to cross a page boundary, one very long description, and a payment reference near the bottom. Then inspect the actual PDF for repeated table headers, clipped text, and totals staying with their labels.
A fast 200 response can still deliver an invoice that's hard to use. Do templates paginate those cases, reject content they can't lay out, or have documented limits? That would help me judge the abstraction more than support for arbitrary HTML.