PDFMonkey

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the PDF generation service that replaces PDFMonkey.

One decision dominates the whole design: **which renderer.** Get it right and this is a weekend; get it wrong and you fight page breaks for a month.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Playwright driving headless Chromium for rendering, or Typst for documents that suit it
- Caddy in front

CHOOSING THE RENDERER, HONESTLY
- **Headless Chromium is the right default.** It is heavy — a few hundred megabytes and real memory per instance — but it is the only thing that renders modern CSS the way a designer expects, and page-break control in print CSS actually works
- Typst or LaTeX are far lighter and better for genuinely typographic documents — reports, contracts — but the template is not HTML and a designer cannot edit it
- Do not use a lightweight HTML-to-PDF library for anything with a layout. They fail on flexbox, grid and web fonts, and you will discover it after building everything

THE DATA MODEL
- templates: id, name, html, css, version, updated_at — **versioned, and the version recorded on every document.** A regenerated invoice from last year must look like last year's invoice
- documents: id, template_id, template_version, payload_json, path, sha256, status, requested_at, completed_at
- The payload stored, so a document is reproducible from its inputs

RENDERING PROPERLY
- A worker pool of browser instances with a hard concurrency cap and a restart after N documents — **Chromium leaks memory over long runs and a pool that never recycles will eventually take the machine down**
- A per-document timeout, and kill the page on timeout rather than waiting
- Wait for fonts and images to load before printing, explicitly. The most common bug in generated PDFs is text rendering in a fallback font because the print fired first
- Self-host the fonts. A template pulling a font from a third-party CDN produces different output when that CDN is slow, and it is a privacy problem

PRINT CSS, WHICH IS THE ACTUAL SKILL
- `@page` with size and margins, `page-break-inside: avoid` on rows and blocks that must not split
- Running headers and footers with page numbers using the print counters
- **Test with content that overflows to three pages.** A template that looks right on one page and breaks a table row across two is the failure everybody ships
- Millimetres, not pixels, for anything that will be physically printed

SAFETY, WHICH IS EASY TO MISS
- **A template renders arbitrary HTML in a browser on your server.** Escape every value from the payload, disable JavaScript in the rendering context unless a template genuinely needs it, and block network requests to internal addresses — otherwise a template becomes a server-side request forgery
- Run the browser as an unprivileged user in a container

DELIVERY
- Queue everything; never render inside the request. Return a document id and a webhook or a poll endpoint
- Store the hash, deduplicate identical payloads, and serve through signed expiring URLs

WHAT MATTERS MOST
Browser pool recycling, waiting for fonts, and blocking internal network access from templates. The first keeps it alive, the second keeps it correct, the third keeps it safe.