Gotenberg alternative for teams that do not want to self-host PDF infrastructure
Gotenberg is a strong open-source PDF service with Headless Chromium and LibreOffice support. The trade-off is operational: you run it, patch it, scale it, and monitor it. pdfkitt gives you a managed HTML-to-PDF endpoint instead.
The problem: free software still needs production ops
Gotenberg is MIT licensed and built to be self-hosted. That is great when you need control, but it also means owning the Docker deployment, server capacity, upgrades, monitoring, retries, and uptime for every PDF your product generates.
For teams whose main need is HTML to PDF, the operational work can become larger than the feature. A rendering service still has to be reliable when exports spike, Chrome changes, or workers fail.
pdfkitt is the managed path
pdfkitt gives you Chromium rendering through a hosted API. Your application sends HTML and receives a PDF. You avoid provisioning a separate rendering service and keep your team focused on the document templates and product workflow.
The result is a simpler operating model: no Docker service to run, no browser fleet to patch, and no PDF worker uptime to own.
Side-by-side comparison
| Gotenberg | pdfkitt API | |
|---|---|---|
| Hosting model | Self-hosted service, commonly run from Docker | Fully managed API |
| Cost | MIT-licensed software plus your servers and operations time | Hosted plans with a free tier of 1,000 PDFs / month |
| Rendering stack | Headless Chromium for HTML plus LibreOffice for office documents | Chromium via Playwright for HTML to PDF |
| Operations | You handle deployment, scaling, monitoring, updates, and uptime | pdfkitt operates the rendering infrastructure |
| Best fit | Teams that need self-hosting, on-prem, or office-document conversion | Teams that want HTML-to-PDF without owning the service |
A managed API replacement for HTML to PDF
If your Gotenberg usage is mostly HTML to PDF, the migration can be as small as replacing the self-hosted endpoint with https://api.pdfkitt.dev/v1/convert. Keep the template generation in your app and let pdfkitt handle the render.
You get a predictable API surface for invoices, reports, exports, and customer-facing PDFs without operating a document service yourself.
Quick start
Use the same curl, Node.js, or Python snippets from the pdfkitt dashboard. Swap in your API key, send HTML, and write the PDF response to a file.
Try it now — run this in your terminal (30 seconds)
No setup needed. Just paste this command and you'll get a real PDF back.
curl https://api.pdfkitt.dev/v1/convert \
-H "Authorization: Bearer pdfk_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"html":"<h1>Hello, world!</h1>"}' \
--output document.pdfWhen Gotenberg still makes sense
Gotenberg is a better fit when you need to keep conversion infrastructure inside your own environment, need LibreOffice-based office-document conversion, or have enough platform capacity to operate the service well.
pdfkitt is the better fit when HTML-to-PDF is a feature you want to ship, not a service you want to run.
Try pdfkitt free - 1,000 PDFs/month, no credit card
Get an API key and replace your first self-hosted HTML-to-PDF render in minutes.