n8n

Ein Trigger startet den Ablauf, etwa zu einer Uhrzeit oder über einen Webhook. Weitere Nodes lesen Daten, verändern Felder oder rufen Anwendungen auf. Neben fertigen Integrationen können HTTP-Anfragen und eigener Code eingesetzt werden.

Ein Beispiel ist die Übernahme einer freigegebenen Serviceanfrage: Pflichtfelder prüfen, eine eindeutige Vorgangsnummer bilden, einen Datensatz im Zielsystem anlegen und das Ergebnis zurückmelden. Vorher festlegen, welches System führend ist und welche Daten nur kopiert werden. Sonst entstehen bei späteren Änderungen widersprüchliche Datensätze.

Auch ein kurzer Workflow braucht eine verantwortliche Person und eine verständliche Beschreibung. Namen wie „HTTP Request 7“ erklären den fachlichen Zweck nicht. Die Schritte sollten erkennen lassen, welche Daten sie erwarten und welche Wirkung ein erneuter Lauf hat.

Webhooks und API-Aufrufe können wiederholt werden. Hat das Ziel einen Auftrag bereits angelegt, während die Antwort verloren ging, kann ein erneuter Lauf einen zweiten Auftrag erzeugen. Eine eindeutige Vorgangskennung oder die Idempotenzfunktion des Zielsystems verhindert solche Doppelwirkungen.

Wiederholungen nur für geeignete Fehler vorsehen, begrenzt und mit Wartezeit. Ein ungültiges Datenfeld wird durch häufigeres Senden nicht korrekt. Fehlerwege sollten festhalten, was bereits erfolgreich war und was noch fehlt. Für kritische Übergaben eine manuelle Nachbearbeitung ermöglichen.

Vor der Freigabe mindestens vier Fälle prüfen: normaler Ablauf, doppelte Nachricht, vorübergehend nicht erreichbares Ziel und ein fachlich abgelehnter Datensatz. Ein Test mit ausschließlich erfolgreichen Antworten deckt die typischen Betriebsprobleme nicht ab.

Für Integrationen eigene technische Konten und möglichst begrenzte API-Berechtigungen verwenden. Ein Ticketabgleich braucht keinen administrativen Zugang zur gesamten Zielplattform. Zugangsdaten gehören in die vorgesehenen Credential-Funktionen, nicht als Klartext in Nodes, Kommentare oder Beispielausgaben.

Öffentliche Webhooks müssen den Absender beziehungsweise die Nachricht prüfen, etwa über die vom Quellsystem vorgesehenen Signaturen oder Authentifizierungsverfahren. Editor und Verwaltung nicht deshalb öffentlich freigeben, weil ein Webhook aus dem Internet erreichbar sein muss.

Ausführungsverläufe können personenbezogene Daten, Dokumente und API-Antworten enthalten. Aufbewahrung und Zugriffsrechte passend zum Zweck festlegen. Community Nodes und eigener Code erweitern die Möglichkeiten, aber auch die Vertrauensgrenze. Vor der Installation Herkunft, Pflege und benötigte Zugänge prüfen.

Im Queue Mode nimmt eine Hauptinstanz Aufgaben an. Redis vermittelt Ausführungen an Worker, die Daten aus der gemeinsamen Datenbank laden und Ergebnisse dort ablegen. Für einen verteilten Aufbau ist PostgreSQL vorgesehen, ein verteilter Betrieb über SQLite wird nicht unterstützt.

Alle beteiligten Worker benötigen den passenden Verschlüsselungsschlüssel, um hinterlegte Credentials lesen zu können. Auch Dateien und andere Binärdaten müssen an ihrem tatsächlichen Verarbeitungsort erreichbar sein. Die gewählte Speicherart und ihre Verfügbarkeit in der Edition vor dem Ausbau prüfen.

Zusätzliche Worker schaffen keine Hochverfügbarkeit für jede andere Komponente. Datenbank, Redis, Webhook-Annahme und Hauptinstanz bleiben eigene Ausfallpunkte. Queue Mode ist außerdem von Multi-main-Betrieb zu unterscheiden, der nach aktueller Editionsübersicht nicht zur Community-Ausgabe gehört.

Für eine vollständige Wiederherstellung sind Datenbank, Konfiguration und Credential-Schlüssel erforderlich. Je nach Aufbau kommen lokale oder externe Binärdaten und zusätzliche Nodes hinzu. Ohne passenden Schlüssel lassen sich verschlüsselte Zugangsdaten aus der gesicherten Datenbank nicht wiederverwenden.

Die CLI kann Workflows und Credentials exportieren. Diese Exporte enthalten aber nicht automatisch Benutzer, Ausführungsverlauf und alle Instanzeinstellungen. Vor Updates einen zusammenpassenden Stand sichern und den Wiederanlauf getrennt testen.

Ändert sich eine externe API oder die Version eines Nodes, kann ein bisher funktionierender Ablauf andere Ergebnisse liefern. Für zentrale Workflows einen kleinen Satz repräsentativer Testvorgänge pflegen. Neue Versionen zuerst gegen Testsysteme ausführen, damit ein Prüflauf keine echten Bestellungen oder Nachrichten erzeugt.

n8n veröffentlicht den Community-Code unter der Sustainable Use License. Sie erlaubt insbesondere die Nutzung für eigene interne Geschäftszwecke, ist aber keine uneingeschränkte Open-Source-Lizenz nach dem üblichen OSI-Verständnis. Ein eigenes Hostingangebot für Kunden oder eine Einbettung in ein kommerzielles Produkt muss gesondert gegen die Bedingungen geprüft werden.

Die Community-Ausgabe enthält nach aktueller Dokumentation unter anderem keine Projects, kein Teilen von Workflows und Credentials zwischen normalen Benutzern und kein SSO über SAML oder LDAP. Auch externe Secret Stores, Git-basierte Versionsverwaltung und Multi-main gehören nicht zum Community-Umfang. Queue Mode ist dagegen enthalten.

Die Lizenzfrage und die Funktionsauswahl sind zwei getrennte Prüfungen. Ein zulässiger interner Einsatz kann trotzdem eine kostenpflichtige Edition benötigen, wenn das Team bestimmte Rollen-, Anmelde- oder Betriebsfunktionen voraussetzt.

Geprüft am 20. September 2026 anhand der Herstellerdokumentation und der veröffentlichten Lizenz. Keine pauschale Lizenzfreigabe für kundenbezogene Hosting- oder Produktangebote.