PDF Server

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.txt) 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.

Building something bigger, or need a feature? Get in touch .

← static_template