Warum n8n und nicht Zapier oder Make
Zapier und Make sind solide Einstiegswerkzeuge. Sie sind schnell eingerichtet und benotigen keinen Server. Aber wenn Workflows komplexer werden, stost man an Grenzen: eine Abrechnung pro Aufgabe, die bei hohem Volumen teuer wird, begrenzte Code-Moglichkeiten und kaum Kontrolle daruber, wohin Daten gehen.
n8n geht das anders an. Der visuelle Editor funktioniert ahnlich wie Zapier, aber man kann an jedem Punkt im Workflow eigenes JavaScript oder Python ausfuhren. 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-Gebuhr, volle Datensouveranitat 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. Fur 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-Datensouveranitat).
- ▸Hohe Anzahl an Ausfuhrungen pro Monat: n8n Cloud rechnet per Workflow-Execution ab, beim Self-Hosting nicht.
- ▸Queue Mode fur 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.
Fur Teams ohne DevOps-Kapazitat funktioniert n8n Cloud gut. Fur alle mit einem VPS oder einem Hetzner-Account, die hunderttausende Ausfuhrungen pro Monat haben oder sensible Daten verarbeiten, ist Self-Hosting gunstiger 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 fur die n8n Main-Instanz und einem oder mehreren Worker-Containern fur die Queue-Verarbeitung.
- ▸PostgreSQL als Backend-Datenbank statt dem Standard SQLite, damit Workflow-Verlauf und Anmeldedaten stabil gespeichert sind.
- ▸Redis als Queue-Backend fur 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 uber 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 fur alles, aber fur 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 mussen und Logik oder Bedingungen erforderlich sind. Einfache Eins-zu-eins-Integrationen sind auch moglich, aber dafur 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 unterstutzt. Dafur 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 uber 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 verfugbar und verhalt sich wie jeder andere Node. Anmeldedaten werden uber n8ns eingebautes Credential-System verwaltet, sodass keine Schlussel in der Node-Logik gespeichert werden.
-- Kunden-Fallstudie
Auftragsverarbeitung von manuell zu vollstandig automatisiert
Ein Logistikdienstleister verarbeitete taglich eingehende Auftrage per E-Mail: Ein Mitarbeiter las die Anhange, trug die Daten manuell ins WMS ein und sandte eine Bestatigung zuruck. Das kostete taglich mehrere Stunden und war fehleranfallig.
Nach der Analyse zeigte sich eine ubersichtliche Losung: n8n uberwacht ein dediziertes Postfach, erkennt Auftrags-E-Mails uber ein Muster, parst den Anhang, validiert die Daten und sendet sie uber eine interne API ans WMS. Bei Fehlern oder fehlenden Feldern geht eine Slack-Nachricht mit den Rohdaten an den zustandigen Mitarbeiter.
Das Setup lauft 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 fur alles die richtige Wahl. Ich verwende n8n nicht fur:
- ▸ETL-Prozesse, bei denen Terabytes an Daten durch eine Pipeline mussen: Dafur sind dedizierte Tools wie dbt, Airbyte oder Prefect besser geeignet.
- ▸Ersatz fur ein Message-Queue-System wie BullMQ, RabbitMQ oder Kafka, wenn hunderttausende Nachrichten pro Minute verarbeitet werden und Mikrosekunden-Latenz benotigt wird.
- ▸Komplexe Zustandsmaschinen, bei denen volle Kontrolle uber 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 Ihre Anfrage an einer dieser Grenzen liegt, sage ich das direkt. Dann suche ich gemeinsam mit Ihnen nach dem richtigen Werkzeug.
Was kostet eine n8n-Implementierung?
Der Scope bestimmt den Preis. Eine einzelne Integration ist deutlich weniger Aufwand als ein vollstandiges Self-Hosted-Setup mit Queue Mode, Worker Pool und Backup-Strategie. Nach einem kurzen Gesprach erhalte ich ein ehrliches Angebot.
Kurzes Gesprach planen. Ich schaue mir Ihre Situation an und komme mit einem ehrlichen Vorschlag zuruck.