Dokumente als PDF erzeugen mit n8n und Gotenberg

Der Workflow ist fertig: Der Auftrag kommt rein, die Daten sind geprüft, die Freigabe ist erteilt – und am Ende soll ein sauberes PDF herauskommen, ein Angebot, eine Auftragsbestätigung, eine Rechnung. An dieser Stelle stutzen viele, die n8n produktiv einsetzen: Es gibt keinen Node, der aus Daten einfach ein PDF macht. Dieser Artikel zeigt, warum das so ist, welche drei Wege trotzdem zum PDF führen und wie Sie den saubersten davon – einen selbst gehosteten Renderer – konkret in n8n verdrahten, ohne dass Ihre Dokumentdaten das Haus verlassen.

Warum n8n PDFs nicht selbst erzeugt

n8n bringt einen Node zum Erzeugen von Dateien mit, aber der hat eine Grenze, die im ersten Moment überrascht. Der Convert-to-File-Node schreibt laut n8n-Dokumentation CSV, XLSX, ODS, JSON, eine HTML-Tabelle, iCalendar oder eine reine Textdatei. PDF ist nicht dabei – und das ist kein Versehen.

Ein PDF ist kein Datenformat, das man aus einer Tabelle serialisiert, sondern ein Layout: Schriften, Umbrüche, Seitenränder, Grafiken. Um daraus eine gesetzte Seite zu machen, braucht es eine Render-Engine – im Kern denselben Motor, der auch eine Webseite darstellt. Genau die steckt nicht in n8n. Statt eine solche Engine mitzuschleppen, überlässt n8n das Rendern einem spezialisierten Dienst und spricht ihn über den HTTP-Request-Node an. Das klingt nach Umweg, ist aber der saubere Schnitt: Der Workflow orchestriert, das Rendern macht ein Werkzeug, das dafür gebaut ist.

Drei Wege vom Datensatz zum PDF

Für den Renderer gibt es drei Möglichkeiten. Sie unterscheiden sich vor allem darin, wo Ihre Daten verarbeitet werden und wie viel Betrieb Sie selbst übernehmen wollen.

Weg	Wann sinnvoll
Selbst gehosteter Renderer (Gotenberg)	Dokumente mit Personenbezug, höhere Volumina, volle Kontrolle
Template-/Konvertierungs-API (SaaS)	wenig Volumen, keine sensiblen Daten, kein Betriebsaufwand gewünscht
Community-Node im Workflow	kleine Fälle, wenn kein Zusatzdienst laufen soll

Der SaaS-Weg (etwa PDFMonkey oder APITemplate) ist am schnellsten eingerichtet: Vorlage im Anbieter-Portal pflegen, Daten per Node einspeisen, PDF zurückbekommen. Der Haken ist der Datenschutz, dazu weiter unten. Community-Nodes wiederum konvertieren HTML im Workflow selbst – praktisch für Kleinstfälle, aber es ist Drittcode, für dessen Wartung und Sicherheit Sie geradestehen. Für den produktiven Regelfall im Mittelstand ist der selbst gehostete Renderer meist die tragfähigste Wahl. Schauen wir ihn uns genauer an.

HTML zu PDF mit Gotenberg

Gotenberg ist ein quelloffener, unter MIT-Lizenz frei nutzbarer Dienst, der Dokumente in PDF umwandelt. Er läuft als Docker-Container und bringt zwei Render-Engines mit: Chromium für HTML, URLs und Markdown, LibreOffice für Office-Dateien. Sie starten ihn am einfachsten direkt neben n8n im selben Docker-Netz:

services:
  gotenberg:
    image: gotenberg/gotenberg:8
    # aus dem n8n-Container erreichbar unter http://gotenberg:3000

In n8n bauen Sie das HTML im Workflow – mit dem HTML-Node (Operation „HTML-Template erzeugen“) oder einem Code-Node, in den Sie Ihre Daten einsetzen. Das Ergebnis wandeln Sie in eine Binärdatei mit dem Namen index.html und schicken es mit dem HTTP-Request-Node an die Chromium-Route POST /forms/chromium/convert/html: Methode POST, Body-Typ „Form-Data (multipart)“, ein Datei-Feld namens files. Als Antwort kommt das fertige PDF als Binärdaten zurück, das Sie anhängen, ablegen oder weiterreichen. Zum Ausprobieren auf der Kommandozeile genügt ein Aufruf:

curl --request POST http://gotenberg:3000/forms/chromium/convert/html \
  --form 'files=@"index.html"' \
  --form 'paperWidth=8.27' \
  --form 'paperHeight=11.7' \
  --form 'printBackground=true' \
  -o rechnung.pdf

Das Aussehen steuern Sie über Formularfelder: paperWidth und paperHeight setzen das Format (A4 sind 8,27 × 11,7 Zoll), die vier margin-Felder die Ränder, landscape das Querformat. Wichtig für gebrandete Dokumente: printBackground steht standardmäßig auf false – ohne diesen Schalter fehlen Hintergrundfarben und -grafiken im PDF. Für die revisionssichere Archivierung erzeugt das Feld pdfa ein PDF/A (etwa PDF/A-3b).

Bilder, Schriften und Stylesheets schicken Sie als weitere Dateien im selben Request mit. Gotenberg legt alle Uploads in ein flaches Verzeichnis; im HTML referenzieren Sie sie deshalb nur über den Dateinamen – also src="logo.png", nicht src="/bilder/logo.png". Alternativ funktionieren absolute Remote-URLs oder Base64-Data-URIs.

Word-Vorlagen statt HTML

Nicht jedes Team will Rechnungen in HTML pflegen. Wenn Ihre Vorlagen als Word- oder LibreOffice-Datei vorliegen, nimmt die zweite Engine sie direkt: Die Route POST /forms/libreoffice/convert wandelt DOCX, ODT, XLSX und rund hundert weitere Office-Formate per LibreOffice in PDF. Sie befüllen die Vorlage im Workflow – Platzhalter ersetzen, Positionen einfügen – und schicken die fertige Datei an die Route. So bleibt die Vorlagenpflege in der Fachabteilung, die Umwandlung übernimmt der Workflow.

Wohin fließen die Daten? Der DSGVO-Unterschied

Ein Angebot, ein Vertrag, eine Rechnung enthalten fast immer personenbezogene Daten – Namen, Adressen, Beträge. Genau das macht die Wahl des Renderers zu einer Datenschutzfrage, nicht bloß zu einer technischen.

Ob ein PDF-Dienst DSGVO-konform ist, entscheidet sich daran, wohin die Dokumentdaten fließen. Ein selbst gehosteter Renderer wie Gotenberg verarbeitet Angebote, Verträge und Rechnungen innerhalb der eigenen Infrastruktur – die personenbezogenen Daten verlassen das Haus nicht. Eine externe Template-API dagegen ist eine Auftragsverarbeitung nach Art. 28 DSGVO: Sie braucht einen Vertrag und einen geprüften Serverstandort.

Das ist kein Argument gegen SaaS-Dienste – für unkritische Dokumente oder geringe Mengen können sie die pragmatische Wahl sein. Aber die Entscheidung sollte bewusst fallen: Für alles mit sensiblem Inhalt spricht der Datenschutz für die Verarbeitung im eigenen Haus. Welche Punkte in einen sauberen Aufbau sonst noch gehören – vom Auftragsverarbeitungsvertrag bis zum Löschkonzept –, steht in der DSGVO-Checkliste für Automatisierungsprojekte.

Was nach dem PDF kommt

Ein PDF ist selten Selbstzweck. Meist hängt es an einer E-Mail, landet in einem Ordner oder Dokumentenmanagement – oder geht als physischer Brief raus. Für den letzten Fall führt der automatisierte Postausgang über eine Brief-API den Faden genau dort weiter, wo dieser Artikel aufhört: Er erwartet ein fertiges PDF und übernimmt Druck, Kuvertierung und Versand.

Bei Ausgangsrechnungen lohnt zusätzlich ein Blick auf das Format. Gotenberg unterstützt laut Funktionsliste auch ZUGFeRD beziehungsweise Factur-X – also PDFs mit eingebettetem, maschinenlesbarem Rechnungsdatensatz, wie ihn die E-Rechnung inzwischen verlangt. Das ist ein eigenes Thema, aber es ist gut zu wissen, dass derselbe Dienst diesen Schritt mit abdeckt, statt dass Sie ein weiteres Werkzeug einführen müssen.

Fazit

Dass n8n kein PDF nativ erzeugt, ist kein Mangel, sondern eine Arbeitsteilung: Der Workflow steuert, ein Renderer setzt die Seite. Für die meisten Betriebe mit personenbezogenen Dokumenten ist ein selbst gehostetes Gotenberg der ehrlichste Weg – kostenlos, quelloffen, und die Daten bleiben im Haus. Wer nur gelegentlich ein PDF braucht und keine sensiblen Inhalte verschickt, ist mit einer API schneller. Falsch ist vor allem eins: die Vorlage von Hand in Word auszufüllen und zu exportieren, während der Rest längst automatisch läuft. Wenn Sie überlegen, welcher Weg zu Ihren Dokumenten, Ihrem Volumen und Ihren Datenschutzanforderungen passt, schauen wir uns das im kostenlosen Prozess-Check gemeinsam an.