Skip to main content

A PDF microservice for your platform

The broadest use case: you need document rendering somewhere in your product and don't want to build and maintain a headless-browser pipeline yourself.

Why PDF Server fits​

  • You write templates, not code. Adding a new document type means adding a template directory — no service changes, no redeploy of rendering logic.
  • One image to run. Layer your templates on the base image and deploy it on your own infrastructure (build your image).
  • A clean HTTP contract. POST JSON, get a PDF. A generated OpenAPI spec documents each template's endpoint and schema.
  • Operable. Pooled browsers, OpenTelemetry tracing, structured logs, and a status endpoint (operations).
  • Agent-friendly docs. Machine-readable docs (/llms.md) so AI tooling can integrate against it.

The integration​

your-service  ──POST /templates/<name>/render──▶  pdf-server (your image)
              ◀──────────── application/pdf ──────

Keep PDF Server internal, behind your gateway, and call it from your backend. Follow the hardening checklist if any template data originates from your end users.