We upgraded our servers from Debian12 to Debian13 and woops, wkhtmltopdf is not there anymore, the project closed down, is not being updated anymore and wkhtmltopdf uses an very old Qt4 library.
Now what? I really do not want to go installing headless chrome on these containers and take up so many resources to create PDF files?
What are you guys now using to create PDF files? I’m probably not the only one with this issue right?
Chrome does take a lot of resources but should only do so in a transient fashion. I use it both for generating PDFs and scraping data, on 4GB nodes. I conservatively estimate 900mb of RAM per instance and never have more than 2 running in parallel. The key to stability with running chrome in production IMO is to isolate it and never leave it running between two generations.
The startup time cost is worth the absence of memory creeping over time.
You have headless alternatives that reimplement layout like Weasyprint and that should be great for most layouts. In my case I need 1:1 output with what my user sees, and runtime generation of visuals via HTML5 canvas, so I stuck with chrome.
Sometime ago at my company, we were also using wkhtmltopdf. We didn’t like that it was run on the same machine as our Elixir app. We also faced some challenges with PDF styling.
At first, we switched to client side rendering of PDF. At that period of time, we used: html2pdf.js | Client-side HTML-to-PDF rendering using pure JS. This also resulted with some issues, as sometimes, depending on the customer browser, PDF differed depending on used browser.
In the end, our go-to solution was an external solution: https://pdfmonkey.io/. I’m not in any way associated with them, just really liking their support, when we were starting a co-operation with them. The pricing is pretty decent, if you don’t generate thousands of PDF.
We’re using PDF Monkey together with: https://pagedjs.org/, which allowed us to use some features, like Table of Content, headers, footers, etc.