Adding Gotenberg to a Node stack does not look like a dependency, it looks like a deployment. You pull a Docker image, run it as a service, and your app sends it an HTTP request for every PDF it needs.
import FormData from "form-data";
import fetch from "node-fetch";
const form = new FormData();
form.append("files", Buffer.from("<h1>Invoice #1042</h1>"), "index.html");
const res = await fetch("http://localhost:3000/forms/chromium/convert/html", { method: "POST", body: form });
const pdfBuffer = await res.buffer();
From that call on, the PDF path runs through a container your team deploys, monitors, scales, network-secures, and patches, rather than a function inside the process that needs the document. IronPDF for Node.js is an in-process library rather than a service, which is the difference this piece is about.
Full disclosure. We build IronPDF for Node.js at Iron Software, and this read looks at where Gotenberg's service model and SSRF history cost a team and where an in-process library sidesteps that category of work.
What running a PDF service actually costs
Gotenberg is infrastructure, not a dependency, so adopting it adds a service to the architecture rather than a package to package.json. Every conversion becomes a network request rather than a function call, so a failure that used to be a caught exception in your own process turns into an infrastructure incident, a timeout, a refused connection, a service that needs its own alerting. The runtime footprint is real too, around a gigabyte of memory recommended, and while a single instance runs up to six parallel Chromium conversions, it handles only one LibreOffice conversion at a time by default, so an Office-heavy load queues behind that limit until you tune it or add replicas.
The SSRF pattern in the URL fetcher
Gotenberg's own Go code carries 21 confirmed advisories in the GitHub Advisory Database, and the dominant pattern is server-side request forgery. Its endpoints fetch remote URLs on your behalf, to render a page or pull a file to convert, and the deny-list meant to block requests to internal addresses has been bypassed and re-patched repeatedly across a tight run of releases, each one closing a slightly different bypass in the URL-filtering logic. Every advisory is fixed in the current 8.35.0, and the fixes have landed fast, but that history means running Gotenberg safely is a standing discipline of staying current rather than a one-time setup, because the deny-list has been wrong before and the URL-fetching surface is the orchestration layer's own code, not a bundled dependency you can wave off.
Rendered in process, with no service to run
IronPDF renders the same HTML from inside the Node process, with no container in the path and no URL-fetching service to keep patched.
import { PdfDocument } from "@ironsoftware/ironpdf";
const invoice = await PdfDocument.fromHtml(
"<h1>Invoice #1042</h1><p>Total due: $250.00</p>"
);
await invoice.saveAs("invoice.pdf");
That renders a document with no network hop, no container to deploy and patch, and no separate service carrying its own SSRF surface. You can pull IronPDF for Node.js from npm and run this in a couple of minutes, and the HTML-to-PDF guide walks the path end to end.
Service versus in-process, row by row
| Capability | Gotenberg | IronPDF for Node.js |
|---|---|---|
| Deployment model | Docker service, called over HTTP |
@ironsoftware/ironpdf, in-process |
| Network round-trip per PDF | Yes, and it can time out or refuse | None, PdfDocument.fromHtml runs in process |
| Own-code CVE history | 21 advisories, recurring SSRF | None found |
| Staying safe | Patch the service on every release | Update the package |
| Runtime footprint | Container, ~1 GB recommended | In-process library |
Table 1. Gotenberg and IronPDF for Node.js across the deployment and security questions, from Gotenberg's own documentation and the GitHub Advisory Database.
IronPDF keeps the PDF inside the app
The one case for Gotenberg is a team already operating a platform layer that also needs Office-document conversion from the same service. That is a narrow overlap, though, since most Node apps generating PDFs are neither standing up that platform nor converting Word and Excel files, and for them the service is operational cost and an SSRF surface against a job an in-process call already does.
If PDF generation is one feature of a Node application rather than a platform your team runs, IronPDF for Node.js covers it in process. IronPDF for Node.js has a free trial if you want to run your own HTML through it before deciding.
Is your team already set up to keep a service like this patched on an ongoing basis, or would that be new operational overhead? Tell us in the comments, we think that answer matters more here than any feature row.
Gotenberg is an open-source project distributed under the MIT licence, and is not affiliated with Iron Software. The details above are drawn from the project's own documentation and the GitHub Advisory Database. If something has changed since, correct us in the comments.
Top comments (0)