Skip to content

Why Nebula PDF

Nebula is built for documents you author yourself: invoices, statements, reports, and labels. You write templates in JSX with Flexbox, get deterministic measurement and pagination, and ship a Node-friendly pipeline with no Chromium process.

The path is: JSX templates → layout engine → Satori SVG → Resvg PNG → pdf-lib PDF.

  • Templates you own — compose Page, Box, Text, Image, and Table instead of scraping or printing arbitrary HTML
  • Edge / serverless — small runtime footprint; no browser binary, better cold starts and memory than headless Chrome
  • Deterministic layout — measure and bin-pack content so page breaks stay predictable
  • First-class tables — schema-driven columns, repeating headers, and rows that don’t split mid-row
Category Nebula PDF Engine Puppeteer pdfmake
Runtime footprint Lightweight; no Chromium binary Heavy Chromium dependency Lightweight JS library
Styling model JSX + Flexbox (Page, Box, Text, Image, Table) Full HTML/CSS via headless browser JSON document-definition API
Edge / Serverless Node-friendly; no browser process Weak fit (memory, cold start) Good for Node; not JSX/Flexbox-native
Layout Deterministic measurement + pagination Browser print engine Declarative PDF primitives
JSX Template
PdfEngine.generate()
├─ extractPages()
├─ resolveImages()
├─ layoutEngine.paginate() ← measure + bin-pack + table segments
├─ renderToImage() ← Satori SVG → Resvg PNG
└─ assemblePdf() ← pdf-lib merges PNGs
PDF Buffer
  • You must print arbitrary HTML/CSS (third-party pages, complex web UIs).
  • You need browser print CSS (@page, print media queries) exactly as Chrome does.

For reports, invoices, statements, and labels authored in your own templates, Nebula is usually the better fit.