Warum n8n und nicht Zapier oder Make
Zapier und Make sind solide Einstiegswerkzeuge. Sie sind schnell eingerichtet und benötigen keinen Server. Aber wenn Workflows komplexer werden, stößt man an Grenzen: eine Abrechnung pro Aufgabe, die bei hohem Volumen teuer wird, begrenzte Code-Möglichkeiten und kaum Kontrolle darüber, wohin Daten gehen.
n8n geht das anders an. Der visuelle Editor funktioniert ähnlich wie Zapier, aber man kann an jedem Punkt im Workflow eigenes JavaScript oder Python ausführen. Man ist nicht auf das beschrankt, was der Tool-Anbieter vorgegeben hat. Und da n8n Open Source ist, lasst sich das auf eigener Infrastruktur betreiben: keine Aufgaben-Gebühr, volle Datensouveranität und keine Abhangigkeit von externer Verfugbarkeit.
Der Nachteil des Self-Hostings ist etwas mehr Verwaltungsaufwand. Das ist genau die Abwagung: mehr Kontrolle, etwas mehr Verantwortung. Ich lose das, indem ich das Setup so aufbaue, dass man sich kaum darum kummern muss.
Self-Hosting oder n8n Cloud: die Abwagung
n8n bietet einen verwalteten Cloud-Plan an. Für kleine Teams oder wenn kein VPS verwaltet werden soll, ist das eine valide Wahl. Aber es gibt Situationen, in denen Self-Hosting klar besser ist:
- Personenbezogene Daten oder Kundendaten werden verarbeitet, die nicht bei einem externen Anbieter gespeichert werden sollen (DSGVO-Datensouveranität).
- Hohe Anzahl an Ausfuhrungen pro Monat: n8n Cloud rechnet per Workflow-Execution ab, beim Self-Hosting nicht.
- Queue Mode für zuverlassige Verarbeitung groster Batches ohne Timeouts.
- Horizontale Skalierung der Worker bei steigender Last.
- Anmeldedaten in einem eigenen Vault oder verschlusseltem Postgres statt bei Dritten speichern.
Für Teams ohne DevOps-Kapazität funktioniert n8n Cloud gut. Für alle mit einem VPS oder einem Hetzner-Account, die hunderttausende Ausfuhrungen pro Monat haben oder sensible Daten verarbeiten, ist Self-Hosting günstiger und sicherer.
Mein Standard-n8n-Setup
Ich betreibe n8n selbst gehostet im Produktionsbetrieb auf einem Hetzner VPS. Der Stack, den ich verwende und auch bei Kunden ausrolle:
- Docker Compose mit einem separaten Container für die n8n Main-Instanz und einem oder mehreren Worker-Containern für die Queue-Verarbeitung.
- PostgreSQL als Backend-Datenbank statt dem Standard SQLite, damit Workflow-Verlauf und Anmeldedaten stabil gespeichert sind.
- Redis als Queue-Backend für den Queue Mode: Workflows werden in eine Warteschlange gestellt und von Workers verarbeitet, auch wenn die Main-Instanz neustartet.
- Traefik als Reverse Proxy mit automatischem TLS via Let's Encrypt.
- Tagliches automatisiertes Backup der Postgres-Datenbank in einen S3-kompatiblen Object Store (Hetzner Object Storage oder Backblaze B2).
- Webhook-Absicherung über n8ns eingebaute Basic Auth oder API-Key-Verifizierung an sensiblen Endpunkten.
Das Ergebnis ist ein Setup, das absturtzt und sich erholt, ohne Workflows zu verlieren. Der Queue Mode stellt sicher, dass ein n8n-Neustart oder ein Server-Reboot keine verlorenen Ausfuhrungen bedeutet.
Was ich typischerweise mit n8n automatisiere
n8n ist kein Ersatz für alles, aber für eine breite Kategorie von Integrations- und Orchestrierungsproblemen ist es das richtige Werkzeug. Beispiele aus der Praxis:
- Formular-Einsendungen von einer Website oder Typeform werden direkt an ein CRM weitergeleitet, mit Unternehmensdaten angereichert und eine Slack-Benachrichtigung gesendet.
- Eingehende E-Mail-Anhange werden heruntergeladen, verarbeitet (PDF-Extraktion, OCR oder Umwandlung in CSV) und in einem gemeinsamen Laufwerk gespeichert.
- Webhook-Orchestrierung: Mehrere externe Dienste senden Events, die n8n zusammenfuhrt, dedupliziert und in der richtigen Reihenfolge verarbeitet.
- Tagliche Berichte: Daten aus mehreren Quellen abrufen, zusammenfuhren und als Tabelle oder PDF per E-Mail versenden.
- Mehrstufige Genehmigungsflows, bei denen ein Vorgesetzter eine Aktion per E-Mail oder Slack genehmigt, bevor ein nachgelagertes System aktualisiert wird.
Der rote Faden: n8n ist stark, wenn mehrere Tools miteinander kommunizieren müssen und Logik oder Bedingungen erforderlich sind. Einfache Eins-zu-eins-Integrationen sind auch möglich, aber dafür ware n8n vielleicht uberdimensioniert.
Custom Nodes in TypeScript erstellen
Die eingebaute Node-Bibliothek von n8n deckt die meisten gangigen Tools ab. Manchmal braucht man jedoch eine Anbindung an ein internes System, eine Nischen-API oder einen Dienst, den n8n nicht standardmasig unterstützt. Dafür baue ich Custom Nodes.
Ein Custom Node ist ein TypeScript-Paket, das neben n8n deployt wird. Der Node hat ein Manifest mit den Feldern, die im Editor sichtbar sind, und eine Execute-Methode, die den eigentlichen API-Aufruf oder die Logik ausfuhrt. Der Node wird als npm-Paket veroffentlicht oder über das n8n Custom Extension-Verzeichnis geladen.
Der Build-Prozess ist ubersichtlich: TypeScript kompilieren, Paketstruktur erstellen, optional in eine private npm-Registry veroffentlichen. Nach dem Deployment ist der Node sofort im Editor verfügbar und verhalt sich wie jeder andere Node. Anmeldedaten werden über n8ns eingebautes Credential-System verwaltet, sodass keine Schlüssel in der Node-Logik gespeichert werden.
Kunden-Fallstudie
Auftragsverarbeitung von manuell zu vollständig automatisiert
Ein Logistikdienstleister verarbeitete täglich eingehende Auftrage per E-Mail: Ein Mitarbeiter las die Anhange, trug die Daten manuell ins WMS ein und sandte eine Bestätigung zurück. Das kostete täglich mehrere Stunden und war fehleranfallig.
Nach der Analyse zeigte sich eine ubersichtliche Lösung: n8n uberwacht ein dediziertes Postfach, erkennt Auftrags-E-Mails über ein Muster, parst den Anhang, validiert die Daten und sendet sie über eine interne API ans WMS. Bei Fehlern oder fehlenden Feldern geht eine Slack-Nachricht mit den Rohdaten an den zustandigen Mitarbeiter.
Das Setup läuft auf derselben selbst gehosteten n8n-Instanz wie die anderen Workflows des Kunden. Der Wartungsaufwand ist minimal: Das WMS-Schema andert sich selten, und wenn doch, ist die Anpassung im Node sofort sichtbar.
Wofur ich n8n nicht verwende
n8n ist ein leistungsfahiges Werkzeug, aber nicht für alles die richtige Wahl. Ich verwende n8n nicht für:
- ETL-Prozesse, bei denen Terabytes an Daten durch eine Pipeline müssen: Dafür sind dedizierte Tools wie dbt, Airbyte oder Prefect besser geeignet.
- Ersatz für ein Message-Queue-System wie BullMQ, RabbitMQ oder Kafka, wenn hunderttausende Nachrichten pro Minute verarbeitet werden und Mikrosekunden-Latenz benötigt wird.
- Komplexe Zustandsmaschinen, bei denen volle Kontrolle über den Ausfuhrungsstack und die Retry-Logik notwendig ist: Dann baue ich lieber einen leichten Service in Node.js oder Python.
- Workflows, die so geschaftskritisch sind, dass selbst der Queue Mode keine ausreichenden Garantien bietet: Dann ist ein professionelles Job-Orchestrierungs-System mit SLA-Monitoring die bessere Wahl.
Wenn deine Anfrage an einer dieser Grenzen liegt, sage ich das direkt. Dann suche ich gemeinsam mit dir nach dem richtigen Werkzeug.
Was kostet eine n8n-Implementierung?
Der Scope bestimmt den Preis. Eine einzelne Integration ist deutlich weniger Aufwand als ein vollständiges Self-Hosted-Setup mit Queue Mode, Worker Pool und Backup-Strategie. Nach einem kurzen Gespräch erhalte ich ein ehrliches Angebot.
Kurzes Gespräch planen. Ich schaue mir deine Situation an und komme mit einem ehrlichen Vorschlag zurück.