Workflow-Automatisierung mit n8n: wann ein Node genügt
KI-generiert, menschlich reviewt
Zwei Systeme, die dasselbe wissen müssen, und dazwischen ein Cronjob, den vor drei Jahren jemand geschrieben hat, der nicht mehr im Haus ist: Das ist der Normalzustand in gewachsenen Landschaften. Der Job läuft nachts, meldet sich nie, und wenn er ausfällt, merkt es zuerst die Buchhaltung oder der Support. Die Frage ist selten, ob so ein Ablauf automatisiert gehört — er ist es ja bereits. Die Frage ist, in welcher Form: als Workflow in einem Werkzeug wie n8n oder als Pipeline im Repository.
Wir betreiben n8n self-hosted und setzen es dort ein, wo es die ehrlichere Lösung ist. Dieser Artikel beschreibt, wo diese Grenze in unseren Projekten verläuft, wie wir Workflow-Automatisierung mit n8n in der Praxis schneiden — API-Orchestrierung, Middleware-Synchronisation, Daten- und Dokumentenflüsse mit KI-Schritt — und was davon in den Betrieb gehört, nicht in den Entwurf.
Wo n8n genügt — und wo nicht
n8n ist ein Workflow-Werkzeug: Sie verketten Trigger, HTTP-Aufrufe, Transformationen und Zielsysteme in einem Graphen, jeder Knoten ist ein Schritt, jeder Lauf ist mit seinen tatsächlichen Daten einsehbar. Diese Einsehbarkeit ist der eigentliche Gewinn gegenüber einem stillen Cronjob — nicht die grafische Oberfläche.
Die Entscheidung fällt entlang weniger Kriterien:
| Kriterium | n8n | Pipeline als Code |
|---|---|---|
| Viele Systeme, wenig Logik dazwischen | passt | Overhead |
| Fachlogik mit Zustand, Sonderfällen, Rechenregeln | wird unübersichtlich | passt |
| Automatisierte Tests, CI, Code-Review | schwach | Kernstärke |
| Änderungen ohne Deployment, auch durch Fachabteilung | passt | Deployment nötig |
| Hoher Durchsatz, große Datenmengen | Grenzen erreichbar | passt |
| Einzelner Lauf muss nachvollziehbar sein | eingebaut | müssen Sie bauen |
Die Faustregel, nach der wir arbeiten: Transport, Auslösung und Verkettung nach n8n — Fachlogik in Code. Sobald ein Workflow anfängt, Preise zu berechnen, Steuersätze zu unterscheiden oder Zustände über mehrere Läufe zu tragen, ist er im falschen Werkzeug. Ein Graph mit vierzig Knoten und Verzweigungen ist kein Workflow mehr, sondern ein Programm ohne Tests.
Zur Einordnung gehört auch die Lizenz: n8n steht unter der Sustainable Use License. Der Quellcode ist einsehbar, der Betrieb auf eigener Infrastruktur für den internen Geschäftsbetrieb möglich — eine von der OSI anerkannte Open-Source-Lizenz ist es nicht. Wer Nachnutzung oder Weiterverkauf plant, muss das vorher prüfen.
API-Orchestrierung: der häufigste Fall
Der Standardfall ist unspektakulär: Ein Ereignis in System A soll etwas in System B auslösen. Ein Webhook oder ein Zeitplan startet den Lauf, ein HTTP-Knoten holt Daten, ein Transformationsschritt bringt sie in die Zielstruktur, ein weiterer Aufruf schreibt sie fort.
Was n8n hier mitbringt, ist der Umgang mit der Realität fremder APIs: Wiederholung pro Knoten mit Wartezeit, ein eigener Fehlerausgang statt eines Abbruchs, Paginierung und Rate-Limits als Konfiguration statt als handgeschriebene Schleife. Was Sie trotzdem entwerfen müssen, nimmt Ihnen kein Werkzeug ab:
- Idempotenz. Ein zweiter Lauf über dieselben Daten darf keine Dubletten erzeugen. Das verlangt einen stabilen Schlüssel im Zielsystem — eine externe ID, kein Zeitstempel.
- Wiederaufsetzpunkt. Nach einem Ausfall muss der Lauf wissen, ab wo er weitermacht. Wir führen dafür eine Wasserstandsmarke mit, statt jedes Mal alles zu ziehen.
- Was bei Teilerfolg gilt. 200 von 300 Datensätzen geschrieben, dann Abbruch — ist das ein Fehlschlag oder ein Zwischenstand? Die Antwort gehört in den Entwurf, nicht in die Nachbereitung.
Middleware-Synchronisation zwischen Fachsystemen
Der interessantere Fall sind zwei Systeme, die dauerhaft denselben Ausschnitt der Wirklichkeit führen. In unseren Projekten ist das oft ein Ticketing-System auf pretix-Basis auf der einen Seite und eine Verlags- oder Abo-Plattform auf der anderen — Veranstaltungen, Kontingente und Bestellungen hier, Kundenkonten, Abonnements und Rechnungslauf dort. Für die Ticketing-Seite haben wir diese Anbindung als eigene Middleware gebaut (Ticketing-Plattform als Proof of Concept); n8n ist in solchen Aufbauten die Schicht, die sie auslöst, überwacht und mit den übrigen Systemen verbindet.
Drei Festlegungen entscheiden, ob eine solche Synchronisation trägt:
- Richtung der Wahrheit. Für jedes Feld gibt es genau ein führendes System. „Beide dürfen schreiben” ist keine Architektur, sondern eine Verabredung, sich später zu streiten.
- Delta statt Vollabgleich. Wo das Quellsystem Webhooks anbietet, nehmen wir Ereignisse. Wo nicht, fragen wir gegen eine Wasserstandsmarke ab. Der nächtliche Vollabgleich bleibt als Korrektiv — er findet, was der Delta-Pfad verloren hat, und ist damit ein Messinstrument, kein Ersatz.
- Konfliktregel vor dem ersten Lauf. Was passiert, wenn derselbe Datensatz auf beiden Seiten verändert wurde? Die Antwort ist selten „der neuere gewinnt” — häufiger gehört der Fall in eine Prüfliste für Menschen.
Genau hier liegt auch die Grenze des Werkzeugs. Solange n8n Datensätze transportiert, auslöst und protokolliert, ist es richtig eingesetzt. Sobald das Mapping Geschäftsregeln trägt — Preiskategorien, Rabattlogik, steuerliche Unterscheidungen —, ziehen wir diesen Teil in einen eigenen Dienst mit Tests. Der Workflow ruft ihn dann auf, statt ihn nachzubauen.
Daten- und Dokumentenflüsse mit KI-Schritt
Der dritte Musterfall verbindet Quellen, die niemand manuell durchsieht: ein KI-News-Scout, der Feeds, Herstellerblogs und Normungsseiten beobachtet, Neues gegen bereits Gesehenes abgleicht, thematisch einordnet und das Relevante zusammengefasst dort ablegt, wo es gelesen wird — als Ticket, als Dokument, als Nachricht im Team-Kanal. Derselbe Aufbau trägt Dokumentenflüsse: Eingang, Extraktion, Klassifikation, Ablage.
Der entscheidende Punkt ist die Rolle des Modells. Das Sprachmodell ist ein Knoten, nicht das System. Was den Ablauf brauchbar macht, steht drumherum:
- Strukturierte Ausgabe. Das Modell liefert Felder, keine Prosa — sonst kann der nächste Knoten damit nicht arbeiten.
- Quellenpflicht. Jede Zusammenfassung trägt den Link zum Original. Ohne Nachweis ist eine Einschätzung wertlos.
- Schwelle und Deduplizierung. Was nicht über die Relevanzschwelle kommt, wird nicht weitergereicht; was schon einmal gemeldet wurde, nicht erneut.
- Mensch am Ende. Der Scout schlägt vor, er veröffentlicht nicht.
Die Redaktionspipeline dieser Website funktioniert nach demselben Muster — dort allerdings bewusst als Code, weil sie versioniert, getestet und im Review nachvollziehbar sein muss. Das ist die Trennlinie aus dem ersten Abschnitt, angewandt auf den eigenen Betrieb. Soll das Ergebnis eines solchen Flusses anschließend abfragbar sein, endet der Workflow nicht im Posteingang, sondern in einem Wissensspeicher — für dessen Wahl gelten dann andere Kriterien. Und wenn ein Assistent den Ablauf selbst auslösen soll, statt nur sein Ergebnis zu lesen, gehört davor eine Kontrollschicht: ein eigener MCP-Server mit eng geschnittenen Werkzeugen, nicht ein offener Webhook.
Betrieb: self-hosted, versioniert, mit Fehlerpfad
n8n ist schnell aufgesetzt und genauso schnell ein unbeaufsichtigtes System mit Schreibrechten auf Ihre Fachsysteme. Was wir deshalb von Anfang an festlegen:
- Postgres statt der Standard-SQLite, Docker-Betrieb auf eigener Infrastruktur, gesetzter Verschlüsselungsschlüssel. Ohne gesichertes Datenverzeichnis und Schlüssel sind die hinterlegten Zugangsdaten nach einem Wiederherstellungsversuch unbrauchbar — das merkt man im Ernstfall, nicht vorher.
- Workflows als Export im Git. Der JSON-Export ist versionierbar, und genau deshalb halten wir Workflows klein und benannt: Ein Diff über einen Graphen mit vierzig Knoten ist nicht mehr reviewbar. Zugangsdaten liegen verschlüsselt in der Datenbank und stehen nicht im Export — die Trennung muss man beim Deployment mitdenken.
- Ein zentraler Fehler-Workflow. Jeder produktive Ablauf verweist darauf; von dort geht die Alarmierung raus. Ein fehlgeschlagener Lauf, den nur die Oberfläche kennt, ist ein stiller Cronjob mit Web-UI.
- Aufbewahrung der Laufdaten begrenzen. n8n speichert die Nutzdaten jedes Laufs — bei personenbezogenen Daten ist die Ausführungshistorie ein eigener Datenbestand mit Löschfrist, kein Debugging-Komfort.
- Getrennte Umgebungen. Ein Workflow, der gegen das Produktivsystem schreibt, wird nicht im Produktivsystem entwickelt.
Fazit
- Die Frage ist nicht n8n oder Code, sondern der Schnitt dazwischen: Transport, Auslösung und Verkettung ins Werkzeug, Fachlogik in getesteten Code.
- Idempotenz, Wiederaufsetzpunkt und Konfliktregel entscheiden über die Haltbarkeit einer Synchronisation — nicht die Zahl der verfügbaren Knoten.
- Bei KI-Schritten ist das Modell ein Knoten unter vielen; strukturierte Ausgabe, Quellenpflicht und eine menschliche Freigabe machen den Ablauf verwendbar.
- Der Betrieb entscheidet: eigener Verschlüsselungsschlüssel, Workflows im Git, zentraler Fehlerpfad, begrenzte Aufbewahrung der Laufdaten.
- n8n ist quelloffen einsehbar, aber nicht OSI-Open-Source — vor Nachnutzungsplänen die Lizenz prüfen.
Wenn Sie wiederkehrende Abläufe automatisieren wollen und vorher wissen möchten, welcher Teil davon ins Werkzeug gehört und welcher in Code: So gehen wir bei Prozessautomatisierung vor.