I am building a PDF API because every codebase I touch has a haunted PDF service

Source: Dev.to

There is a file in almost every backend I have worked on. It generates PDFs. Invoices, mostly. Sometimes reports or certificates. It was written years ago by someone who left, it runs a headless browser nobody fully understands, and it falls over on the last day of the month when finance needs the invoices out. I have rebuilt this same haunted corner enough times that I decided to fix it once, properly, for everyone. It is called PDFPipe. The actual problem Chromium wants 0.5 to 1 GB of RAM per instance and falls over under load. What PDFPipe does curl https://api.pdfpipe.xyz/v1/pdf \

That is the whole integration. No browser in your infra, no queue to babysit. Three decisions I made on purpose A real free tier. The industry standard free tier is around 50 documents a month, which is not enough to ship anything. PDFPipe gives 500. Security as a feature, not an afterthought. HTML-to-PDF services are a textbook SSRF target. Rendered markup can embed an iframe pointing at file:///etc/passwd or the cloud metadata endpoint at 169.254.169.254 and leak credentials straight into the returned PDF. There are CVEs for exactly this. PDFPipe renders in an isolated sandbox with no credentials and no route to private networks, and every outbound request a page makes is resolved and checked first. Built for agents too Where it is https://pdfpipe.xyz I would genuinely like to hear how you generate PDFs today and what breaks. Drop it in the comments.