Eine neue E-Mail trifft ein.

Sie soll automatisch analysiert werden.

Handelt es sich um eine Rechnung, soll der Anhang gespeichert werden.

Handelt es sich um eine Supportanfrage, soll ein Ticket entstehen.

Ist es eine Kaufanfrage, soll der Kontakt ins CRM.

Bei unklaren Nachrichten soll eine KI helfen.

Das Ergebnis soll anschließend in einer Datenbank protokolliert werden.

Man könnte dafür ein eigenes Programm schreiben.

Zum Beispiel:

E-Mail-API
↓
Python
↓
KI-API
↓
CRM-API
↓
Datenbank
↓
Fehlerbehandlung
↓
Logging

Das funktioniert.

Aber schon ein relativ einfacher Geschäftsprozess verlangt plötzlich:

API-Clients,

Authentifizierung,

Zeitpläne,

Webhook-Endpunkte,

Verzweigungen,

Datenmapping,

Fehlerbehandlung.

Genau an dieser Stelle setzt n8n an.

n8n ist eine Workflow-Automatisierungsplattform, mit der Anwendungen und APIs über grafisch aufgebaute Workflows verbunden werden können. Die offizielle Dokumentation beschreibt n8n als „fair-code“-lizenziertes Workflow-Automatisierungswerkzeug, das klassische Geschäftsprozessautomatisierung und KI-Funktionen kombiniert; n8n kann als Cloud-Dienst genutzt oder selbst betrieben werden. (n8n Docs)

Vereinfacht:

Ereignis
↓
n8n
↓
mehrere Systeme verbinden
↓
Daten verarbeiten
↓
Entscheidungen treffen
↓
Aktionen ausführen

n8n ist ein Workflow-Orchestrator

Unter Workflows verstehen haben wir einen Workflow als geordnete Folge von Arbeitsschritten kennengelernt.

n8n macht diese Schritte sichtbar.

Statt beispielsweise im Programmcode:

receiveMail()
classifyMail()
findCustomer()
createTicket()
sendNotification()

zu schreiben, entsteht auf einer grafischen Arbeitsfläche ungefähr:

E-Mail Trigger
      ↓
KI-Klassifikation
      ↓
     Switch
     /   \
Support   Rechnung
   ↓         ↓
Ticket     Archiv

Jeder Kasten ist dabei typischerweise ein Node.

Was ist ein Node?

Ein Node ist ein einzelner Baustein innerhalb eines n8n-Workflows.

Er kann beispielsweise:

eine E-Mail lesen,

eine API aufrufen,

einen Datensatz verändern,

eine Bedingung prüfen,

eine Datei bearbeiten,

ein KI-Modell ansprechen

oder einen neuen Workflow starten.

n8n stellt Nodes für zahlreiche Anwendungen und technische Funktionen bereit; bei unterstützten App-Nodes können konkrete Operationen direkt ausgewählt werden. Wenn eine benötigte Operation nicht als fertige Funktion vorhanden ist, kann häufig der HTTP-Request-Node verwendet werden, um die zugrunde liegende API direkt anzusprechen. (n8n Docs)

Das ist eines der wichtigsten Prinzipien von n8n:

Node
=
eine klar begrenzte Fähigkeit

Ein Workflow besteht aus verbundenen Nodes

Ein einfaches Beispiel:

Schedule Trigger
↓
HTTP Request
↓
Edit Fields
↓
E-Mail

Der Workflow könnte bedeuten:

jeden Morgen
↓
Daten über API holen
↓
Daten aufbereiten
↓
Bericht per E-Mail senden

Die Verbindungslinien beschreiben, wie der Prozess und seine Daten von einem Node zum nächsten wandern.

n8n ist deshalb mehr als ein grafischer Programmiereditor

Ein Workflow beschreibt gleichzeitig:

Kontrollfluss

Was kommt als Nächstes?

und:

Datenfluss

Welche Informationen bekommt der nächste Schritt?

Genau diese beiden Ebenen haben wir bereits bei Workflows getrennt.

n8n bringt sie auf einer Oberfläche zusammen.

Was ist ein Trigger Node?

Jeder automatisch gestartete Workflow braucht einen Auslöser.

Ein Trigger Node beantwortet:

Wann soll dieser Workflow beginnen?

Zum Beispiel:

jeden Morgen um 08:00 Uhr

oder:

neue E-Mail eingetroffen

oder:

Webhook empfangen

oder:

neues Ereignis in einer Anwendung

n8n besitzt sowohl eigene Triggermechanismen als auch zahlreiche anwendungsspezifische Trigger-Nodes; die offizielle Integrationsdokumentation führt beispielsweise Trigger für Gmail, GitHub, Shopify, Stripe, WooCommerce und viele weitere Systeme. (n8n Docs)

Ein zeitgesteuerter Workflow

Beispiel:

Schedule Trigger
↓
Datenbank
↓
Bericht
↓
E-Mail

Bedeutung:

Montag 08:00 Uhr
↓
letzte Woche auswerten
↓
Bericht erstellen
↓
versenden

Für solche Aufgaben braucht es weder Webhook noch KI.

n8n ist nicht primär ein KI-Werkzeug.

Es ist zunächst eine Automatisierungsplattform.

Ein ereignisgesteuerter Workflow

Zum Beispiel:

Shopify Trigger
↓
neue Bestellung
↓
CRM
↓
Benachrichtigung

Hier startet nicht die Uhr den Prozess.

Ein externes Ereignis tut es.

Damit kommen wir direkt zu Webhooks.

Der Webhook Node ist besonders universell

Ein System besitzt keine fertige n8n-Integration.

Aber es kann einen HTTP-Webhook senden.

Dann reicht konzeptionell:

externes System
↓
Webhook
↓
n8n

Der Webhook wird zum Eingangstor des Workflows.

Dadurch kann n8n auch mit Systemen verbunden werden, für die kein spezieller App-Node vorhanden ist.

Der HTTP Request Node ist das Gegenstück

Der Webhook Node bedeutet:

anderes System
→ n8n

Der HTTP Request Node:

n8n
→ anderes System

Damit besitzt man zwei ausgesprochen universelle Werkzeuge:

Webhook
→ Ereignisse empfangen

HTTP Request
→ APIs aufrufen

n8n weist in seinen Integrationsdokumenten ausdrücklich darauf hin, dass der HTTP Request Node für API-Operationen verwendet werden kann, die ein vorhandener App-Node selbst nicht unterstützt; vorhandene n8n-Credentials können dabei bei unterstützten Diensten teilweise weiterverwendet werden. (n8n Docs)

Damit braucht n8n nicht für jedes System einen eigenen Node

Angenommen, ein neues SaaS-Produkt erscheint.

Es besitzt:

keinen n8n-Node,

aber:

eine REST-API.

Dann:

HTTP Request
↓
REST API

genügt möglicherweise vollständig.

Genau deshalb war es wichtig, vor diesem Artikel APIs zu verstehen.

Wer APIs versteht, ist mit n8n wesentlich weniger abhängig von fertigen Integrationen.

Ein fertiger App-Node ist hauptsächlich Komfort

Beispiel:

Gmail Node

zeigt vielleicht Felder wie:

Empfänger,

Betreff,

Nachricht.

Intern benutzt die Integration letztlich die entsprechende Schnittstelle des Dienstes.

Für den Nutzer ist der App-Node bequemer.

Man braucht:

Endpoint,

HTTP-Methode,

Header

nicht selbst zusammenzubauen.

Der HTTP Request Node gibt dagegen maximale Flexibilität

Mit einer dokumentierten API kann man beispielsweise selbst konfigurieren:

Methode:
POST

Endpoint:
/api/articles

Authentication:
Bearer Token

Body:
JSON

Das ist näher an klassischer API-Programmierung.

Aber weiterhin innerhalb des Workfloweditors.

n8n ersetzt API-Wissen deshalb nicht

Ein häufiger Irrtum bei Low-Code-Tools lautet:

Ich brauche keine technischen Grundlagen mehr.

In Wahrheit wird n8n umso mächtiger, je besser du verstehst:

HTTP,

JSON,

APIs,

Webhooks,

Authentifizierung,

Datenbanken.

Die grafische Oberfläche nimmt Tipparbeit ab.

Sie beseitigt nicht die zugrunde liegenden Konzepte.

Wie bewegen sich Daten durch n8n?

Ein Node liefert Daten.

Der nächste Node erhält sie.

Zum Beispiel:

Webhook
↓
{
  "customer_id": 4711,
  "message": "..."
}

Dann:

CRM Node
↓
Kundendaten

Dann:

KI Node
↓
Klassifikation

n8n verarbeitet Daten in sogenannten Items; Daten aus vorherigen Nodes können in späteren Nodes referenziert werden. Die Oberfläche unterstützt dieses Mapping sowohl über Expressions als auch per Drag-and-drop aus den verfügbaren Eingangsdaten. (n8n Docs)

Was ist ein Item?

Ein Item kannst du dir vereinfacht als einen Datensatz vorstellen.

Zum Beispiel:

{
  "id": 4711,
  "name": "Anna"
}

Ein Node kann auch mehrere Items erhalten:

Item 1
Item 2
Item 3
...

Das ist wichtig.

Denn viele n8n-Nodes arbeiten automatisch über mehrere eingehende Datensätze.

Ein API-Node könnte 100 Kunden liefern

Zum Beispiel:

HTTP Request
↓
100 Kunden

Der nächste Node erhält nun nicht zwingend:

„eine riesige Sache“.

Sondern viele einzelne Items.

Kunde 1
Kunde 2
Kunde 3
...
Kunde 100

Damit lassen sich Datenlisten sehr natürlich verarbeiten.

Datenmapping verbindet die Felder

Angenommen, der vorherige Node liefert:

{
  "first_name": "Anna",
  "email": "anna@example.com"
}

Der nächste E-Mail-Node braucht:

To

Dann wird das Feld:

email

auf:

To

gemappt.

Die n8n-Oberfläche kann Daten vorheriger Nodes referenzieren und daraus automatisch Expressions erzeugen. (n8n Docs)

Was sind Expressions?

Ein statisches Feld lautet:

support@example.com

Es ist bei jeder Ausführung gleich.

Ein dynamisches Feld lautet sinngemäß:

E-Mail-Adresse des aktuellen Items

Dafür verwendet n8n Expressions.

Eine typische n8n-Expression kann beispielsweise so aussehen:

{{ $json.email }}

Das bedeutet vereinfacht:

Verwende aus dem aktuellen JSON-Datensatz das Feld email.

n8n dokumentiert Expressions als zentralen Mechanismus zum Referenzieren und Transformieren von Workflowdaten; das Mapping kann unter anderem über den Expression Editor erfolgen. (n8n Docs)

Expressions machen Workflows dynamisch

Ohne Expression:

Empfänger:
anna@example.com

Mit Expression:

Empfänger:
{{ $json.email }}

Nun funktioniert derselbe Node für:

Anna,

Max,

Peter,

10.000 weitere Empfänger.

Der Workflow ist nicht mehr auf einen einzelnen Datensatz festgelegt.

Ein typischer Workflow lebt von solchen Variablen

Zum Beispiel:

Webhook
↓
customer_id
↓
API:
GET /customers/{{ customer_id }}

oder:

Artikel
↓
slug
↓
WordPress

Die konkrete Syntax ist Werkzeugdetail.

Das zugrunde liegende Prinzip lautet:

Daten aus früheren Schritten werden in späteren Schritten eingesetzt.

Expressions sind kein Ersatz für komplexen Code

Man kann immer kompliziertere Ausdrücke bauen.

Irgendwann entsteht:

{{ sehr_lange_unlesbare_logik(...) }}

Dann stellt sich die Frage:

Soll diese Logik wirklich noch in einem Ausdruck leben?

Vielleicht ist ein eigener Code Node oder Unterworkflow verständlicher.

Der Edit Fields Node hilft beim Datenmodell

Angenommen, eine API liefert:

{
  "firstName": "Anna",
  "lastName": "Muster",
  "mailAddress": "anna@example.com"
}

Intern möchtest du:

{
  "name": "Anna Muster",
  "email": "anna@example.com"
}

Ein Transformationsschritt bringt die externen Daten in deine interne Form.

Das entspricht der Normalisierung aus unserem Workflow-Artikel.

Daten früh normalisieren macht n8n-Workflows einfacher

Wenn fünf Systeme unterschiedliche Feldnamen liefern:

mail
email
emailAddress
customer_mail

kannst du möglichst früh daraus machen:

email

Danach kennt der restliche Workflow nur noch deine interne Struktur.

Das ist wesentlich wartbarer.

Der IF Node erzeugt zwei Wege

Zum Beispiel:

amount > 1000?

Dann:

IF
├── true
└── false

Das ist klassische deterministische Logik.

Für eine solche Entscheidung braucht n8n keine KI.

Ein Switch eignet sich für mehrere mögliche Wege

Beispiel:

category
↓
Switch
├── billing
├── support
├── sales
└── other

Damit passt n8n hervorragend zu strukturierten KI-Ausgaben.

Die KI liefert:

{
  "category": "billing"
}

n8n übernimmt:

billing
↓
Buchhaltungsworkflow

Das ist ein gutes Muster für KI-Automatisierung

unstrukturierte Nachricht
↓
KI
↓
strukturierte Kategorie
↓
n8n Switch
↓
deterministischer Prozess

Nicht:

KI
↓
soll selbst irgendwie alles erledigen

n8n wird damit zur Kontrollschicht um das Sprachmodell.

Was ist der Code Node?

Nicht jede Datenverarbeitung lässt sich angenehm über Standardnodes und Expressions darstellen.

Dann kann Code eingesetzt werden.

n8n bietet einen Code Node und dokumentiert dort die Verwendung von JavaScript sowie – je nach Ausführungskontext – Python-Unterstützung; die Dokumentation unterscheidet dabei auch klar zwischen dem Code Node und Expressions. (n8n Docs)

Das ermöglicht beispielsweise:

kompliziertere Transformationen,

eigene Berechnungen,

spezielle Parsinglogik.

Low-Code bedeutet deshalb nicht „kein Code möglich“

n8n liegt irgendwo zwischen:

No-Code

und:

klassischer Softwareentwicklung

Du kannst viele Dinge grafisch lösen.

Wenn es notwendig wird, kannst du tiefer gehen.

Das ist eine der Stärken des Ansatzes.

Trotzdem sollte Code nicht automatisch in jeden Workflow

Wenn ein fertiger Node die Aufgabe sauber löst:

verwenden.

Wenn eine einfache Expression reicht:

verwenden.

Code wird interessant, wenn er tatsächlich:

übersichtlicher,

wiederverwendbarer

oder:

leistungsfähiger

ist.

Credentials lösen das Geheimnisproblem

Viele Integrationen brauchen:

API-Key,

Passwort,

OAuth-Verbindung,

Access Token.

Diese Werte sollten nicht in jedem Workflowfeld frei herumstehen.

n8n verwaltet solche Zugangsdaten als Credentials und bindet sie an die jeweiligen Nodes; die Dokumentation behandelt Credentials als eigene verwaltete Ressource und berücksichtigt bei Workflow-Sharing auch Einschränkungen für nicht geteilte Credentials. (n8n Docs)

Vereinfacht:

Workflow
↓
Credential
↓
API

Das ist besser als API-Schlüssel in Expressions

Schlecht:

Authorization:
Bearer sk-geheimer-schlüssel

direkt im Workflow.

Besser:

Credential:
CRM Production

Der Node greift intern auf das Secret zu.

Der Workflow bleibt lesbarer und sicherer.

Credentials sollten nach Zweck benannt werden

Zum Beispiel:

WordPress Casiopeya Production

WordPress Casiopeya Staging

CRM Read Only

CRM Write

Das ist deutlich besser als:

API 1

oder:

Test Neu

Bei vielen Workflows wird Namensgebung schnell wichtig.

Least Privilege gilt auch in n8n

Wenn ein Workflow nur Daten lesen muss, sollte das zugehörige Konto möglichst nicht sämtliche administrativen Rechte besitzen.

Workflow:
Produkte lesen

Credential:

read-only

statt:

global administrator

Das begrenzt den möglichen Schaden bei einem Workflowfehler.

n8n selbst weist auf Credential- und Node-Risiken hin

Die selbst gehostete Plattform bietet einen Security Audit, der unter anderem ungeschützte Webhooks, ungenutzte Credentials, riskante Nodes, Community Nodes und fehlende Sicherheitseinstellungen untersuchen kann. (n8n Docs)

Das unterstreicht einen wichtigen Punkt:

Eine Automatisierungsplattform besitzt oft Zugang zu sehr vielen Systemen.

Sie ist dadurch selbst ein besonders schützenswertes System.

n8n kann zum Schlüsselbund des Unternehmens werden

Dort liegen vielleicht Credentials für:

WordPress,

Mail,

CRM,

Datenbanken,

Cloud,

KI-APIs.

Ein kompromittiertes n8n kann deshalb erheblichen Schaden verursachen.

Self-Hosting bedeutet hier nicht:

Es läuft bei mir, also ist es sicher.

Sondern:

Ich bin selbst für die Sicherheit verantwortlich.

Community Nodes brauchen besondere Vorsicht

Neben offiziellen Nodes können Automatisierungsplattformen Erweiterungen aus der Community unterstützen.

Das ist praktisch.

Aber zusätzlicher Code kann auch zusätzliches Risiko bedeuten.

Der n8n Security Audit führt Community- und Custom-Nodes ausdrücklich unter den prüfbaren Node-Risiken auf. (n8n Docs)

Darum sollte nicht jede beliebige Erweiterung blind auf einem produktiven Automatisierungsserver installiert werden.

Wenn eine API direkt erreichbar ist, ist HTTP Request häufig die sauberere Alternative

Statt einen unbekannten Community Node zu installieren:

HTTP Request
↓
offizielle API

kann eine sehr transparente Lösung sein.

Man sieht:

Endpoint,

Daten,

Authentifizierung,

Response.

Das reduziert Abhängigkeit von fremdem Node-Code.

Was sind Subworkflows?

Ein großer Workflow wird schnell unübersichtlich.

Beispiel:

Support Workflow
├── Kunde suchen
├── E-Mail normalisieren
├── Klassifizieren
├── Wissenssuche
├── Ticket erstellen
└── Benachrichtigen

Bestimmte Funktionen könnten auch in anderen Workflows gebraucht werden.

Dann lohnt sich:

find-customer

als eigener Unterworkflow.

n8n unterstützt das Aufrufen anderer Workflows über eigene Subworkflow-Mechanismen; die aktuelle Dokumentation führt dafür unter anderem Execute Sub-workflow und Execute Sub-workflow Trigger als Core Nodes. (n8n Docs)

Subworkflows sind wie Funktionen

Statt:

denselben Ablauf kopieren
↓
20-mal

besser:

Hauptworkflow A ─┐
                 ├→ find_customer
Hauptworkflow B ─┘

Eine Änderung an der Kundensuche findet dann an einer Stelle statt.

Das verhindert Copy-and-Paste-Architektur

Ohne Unterworkflows:

Workflow A:
Kundensuche v1

Workflow B:
Kundensuche v2

Workflow C:
Kundensuche v1.5 mit Sonderfall

Irgendwann weiß niemand mehr, welche Variante korrekt ist.

Subworkflows schaffen Wiederverwendung.

Gute Subworkflows besitzen einen klaren Vertrag

Zum Beispiel:

Input:

{
  "email": "anna@example.com"
}

Output:

{
  "customer_id": 4711,
  "status": "found"
}

Der Hauptworkflow muss nicht wissen:

welche Datenbank,

welche API,

welche Suchlogik

dahinter steckt.

Das ist auch für KI-Bausteine sehr sinnvoll

Zum Beispiel:

classify_text

oder:

search_knowledge

oder:

generate_embedding

Der Hauptworkflow behandelt sie wie Fähigkeiten.

Die konkrete Modellimplementierung kann später ausgetauscht werden.

Was passiert bei einem Fehler?

Eine API ist offline.

Eine Datenbank antwortet nicht.

Der KI-Aufruf schlägt fehl.

Ein Node erhält ungültige Daten.

Produktive Workflows müssen diese Fälle berücksichtigen.

n8n speichert Workflow-Ausführungen mit Zuständen wie erfolgreich, fehlgeschlagen, laufend oder wartend und erlaubt in der Ausführungsansicht unter anderem das erneute Starten fehlgeschlagener Ausführungen. (n8n Docs)

Das ist für Betrieb und Debugging zentral.

Execution History ist ein großer Unterschied zum einfachen Skript

Ein Cron-Skript läuft nachts.

Es scheitert.

Niemand merkt es.

Mit einer Workflowplattform können Ausführungen zentral sichtbar werden.

Zum Beispiel:

Execution 4711
Status: Failed

Dann lässt sich untersuchen:

Bei welchem Node?

Mit welchen Daten?

Das erleichtert Betrieb erheblich.

Gespeicherte Ausführungsdaten sind allerdings selbst sensibel

Ein Workflow verarbeitet:

Kundendaten.

E-Mails.

Rechnungen.

Passwörter sollte er hoffentlich nicht verarbeiten, aber andere vertrauliche Inhalte durchaus.

Wenn sämtliche Ausführungsdaten lange gespeichert werden, entsteht eine zusätzliche Datenkopie.

Darum sollte bei produktivem Betrieb bewusst entschieden werden:

Was wird gespeichert?

Wie lange?

Wer darf darauf zugreifen?

Error Workflows können zentrale Fehlerbehandlung ermöglichen

Statt in jedem Workflow separat:

Fehler
↓
E-Mail an Admin

zu bauen, ist eine zentrale Fehlerbehandlung sinnvoll.

Zum Beispiel:

Workflow scheitert
↓
Error Handler
↓
Fehler klassifizieren
↓
Monitoring
↓
Benachrichtigung

Das schafft einen zentralen Ort für Betriebsprobleme.

Retry muss trotzdem fachlich passen

Ein HTTP-Aufruf scheitert mit temporärem Serverfehler.

Retry:

sinnvoll.

Eine E-Mail-Adresse ist ungültig.

Retry:

meist sinnlos.

Eine Zahlung hat Timeout.

Blind erneut ausführen:

möglicherweise gefährlich.

n8n automatisiert die Ausführung.

Die Retrystrategie muss trotzdem fachlich richtig entworfen sein.

Idempotenz bleibt auch in n8n notwendig

Ein Webhook trifft doppelt ein.

Dann kann n8n denselben Workflow zweimal starten.

Wenn darin steht:

Gutschrift erzeugen

können zwei Gutschriften entstehen.

Die Workflowplattform nimmt dir dieses Geschäftsproblem nicht automatisch ab.

Darum bleibt unser Muster:

event_id
↓
bereits verarbeitet?
├── ja → Ende
└── nein → weiter

fundamental.

n8n macht schlechte Workflows nicht automatisch gut

Das ist vielleicht die wichtigste Grenze.

Man kann auch einen schlechten Prozess sehr schön visualisieren.

Node
↓
Node
↓
Node
↓
200 weitere Nodes

Das sieht beeindruckend aus.

Kann trotzdem:

fragil,

unverständlich,

gefährlich

sein.

Die Prinzipien aus Workflows gelten weiterhin.

Große Workflows sollten aufgeteilt werden

Ein Workflow mit:

150 Nodes

kann funktionieren.

Aber Wartbarkeit leidet schnell.

Besser sind häufig fachlich getrennte Bausteine:

content-research
content-write
content-review
content-publish
update-rag-index

statt:

everything-content-mega-workflow

n8n eignet sich besonders als Orchestrator

Komplizierte Spezialaufgaben müssen nicht vollständig in n8n implementiert sein.

Zum Beispiel:

n8n
↓
eigener Python-Service
↓
Ergebnis

oder:

n8n
↓
lokaler KI-Server
↓
Antwort

oder:

n8n
↓
Datenbankservice

n8n koordiniert.

Spezialisierte Dienste rechnen.

Das verhindert riesige Code-Nodes

Wenn ein Algorithmus:

500 Zeilen Python

benötigt, ist es vielleicht keine gute Idee, ihn in einen Workflownode zu quetschen.

Besser:

eigener Service
↓
API

und n8n ruft ihn auf.

Damit bleibt:

Code versionierbar,

testbar,

wiederverwendbar.

n8n und Docker

Wer n8n nicht als Cloud-Dienst nutzen möchte, kann es selbst betreiben. Die n8n-Dokumentation nennt unter anderem npm und Docker als Installationswege und führt zusätzlich zahlreiche Self-Hosting-Setups auf. (n8n Docs)

Für einen Server ist Docker besonders interessant, weil n8n dadurch als klar abgegrenzter Dienst betrieben werden kann.

Konzeptionell:

Server
│
├── Reverse Proxy
├── n8n Container
├── PostgreSQL
└── weitere Dienste

Warum Docker gut zu n8n passt

Eine Workflowplattform besitzt:

Anwendungscode,

Konfiguration,

Abhängigkeiten.

Docker kapselt diese Laufzeit.

Dadurch wird ein Update eher zu:

neues Image
↓
Container neu starten

statt:

viele Pakete manuell ändern

Das ist gerade auf Servern mit mehreren Anwendungen attraktiv.

Container bedeutet aber nicht: Daten im Container vergessen

Ein Container kann ersetzt werden.

Dauerhafte Daten müssen deshalb außerhalb seines flüchtigen Dateisystems liegen beziehungsweise über persistente Volumes oder externe Dienste gespeichert werden.

Das ist normales Dockerdesign.

Für produktive Automatisierung sind vor allem wichtig:

Workflowdaten,

Credentials,

Konfiguration,

Datenbank.

Self-Hosting ist nicht dasselbe wie n8n Cloud

Cloud:

Anbieter
↓
betreibt Infrastruktur

Self-hosted:

du
↓
betreibst Infrastruktur

n8n weist selbst darauf hin, dass Self-Hosting insbesondere Kontrolle über Privatsphäre und Infrastruktur ermöglicht, während n8n Cloud den Betrieb übernimmt. (n8n Docs)

Die Softwareidee bleibt ähnlich.

Die Betriebsverantwortung ändert sich.

Self-Hosting bedeutet Updates

Du musst dich kümmern um:

n8n-Version,

Datenbank,

Betriebssystem,

Reverse Proxy,

TLS,

Backups.

Der Vorteil:

mehr Kontrolle.

Der Nachteil:

mehr Verantwortung.

Reverse Proxy und HTTPS gehören zur typischen Serverarchitektur

Extern:

https://automation.example.com

intern:

Reverse Proxy
↓
n8n

Der Proxy kann:

TLS terminieren,

Routing übernehmen,

gegebenenfalls zusätzliche Zugriffskontrollen anwenden.

Gerade Webhooks benötigen eine korrekt erreichbare öffentliche Basis-URL.

Nicht jedes n8n muss öffentlich zugänglich sein

Die Editoroberfläche könnte beispielsweise nur erreichbar sein über:

VPN

oder:

internes Netz.

Webhook-Endpunkte können separat öffentlich erreichbar gemacht werden.

Das reduziert die Angriffsfläche.

Besonders der Editor ist sensibel

Wer den Editor kontrolliert, kann möglicherweise:

Workflows verändern,

Credentials verwenden,

Daten abrufen.

Darum sollte ein öffentlich erreichbarer n8n-Editor nicht wie eine belanglose Website behandelt werden.

Backups sind bei n8n entscheidend

Eine Installation enthält möglicherweise jahrelang entwickelte Workflows.

Ein Serverdefekt ohne Backup bedeutet nicht nur:

Software neu installieren.

Sondern möglicherweise:

Automatisierungslogik verlieren.

Darum müssen je nach Architektur insbesondere Datenbank und relevante persistente Konfiguration gesichert werden.

Ausführungsdaten können dagegen sehr groß werden

Ein Workflow läuft:

100.000-mal.

Jede Execution speichert viele Daten.

Dann wächst die Datenbank.

Darum sollte die Aufbewahrung alter Execution-Daten bewusst konfiguriert werden.

Es ist nicht automatisch sinnvoll, jeden Zwischenschritt für immer zu speichern.

Binärdateien sind ein eigener Skalierungsfaktor

n8n kann in Workflows auch Binärdaten verarbeiten. Für größere selbst gehostete Installationen dokumentiert n8n Möglichkeiten, Binary Data extern zu speichern; die aktuelle Dokumentation nennt für die entsprechende Enterprise-Funktion beispielsweise S3 und weist auf deren Lebenszyklus- und Speicherverwaltung hin. (n8n Docs)

Das wird interessant bei:

PDFs,

Bildern,

Videos,

großen Anhängen.

Kleine Automatisierungen brauchen keine komplizierte Infrastruktur

Ein paar Workflows.

Wenig Traffic.

Keine riesigen Dateien.

Dann:

eine n8n-Instanz
+
Datenbank

kann völlig ausreichend sein.

Man sollte nicht sofort:

Cluster,

Redis,

zehn Worker

bauen, nur weil n8n skalieren kann.

Was ist Queue Mode?

Bei wachsender Last kann die Ausführung von Workflows auf mehrere Prozesse beziehungsweise Worker verteilt werden.

n8n dokumentiert dafür einen Queue Mode und entsprechende Skalierungs- und Queue-Konfigurationen in seiner Self-Hosting-Dokumentation. Die aktuelle Dokumentationsstruktur behandelt dafür unter anderem Queue Mode, Worker-Komponenten und Skalierung als eigene Betriebsbereiche. (n8n Docs)

Konzeptionell:

n8n Main
↓
Queue
↓
├── Worker 1
├── Worker 2
└── Worker 3

Die Hauptinstanz muss nicht jede Ausführung selbst erledigen

Eine Rolle kann stärker zuständig sein für:

UI,

Workflowsteuerung,

Trigger.

Worker übernehmen:

Workflow-Ausführungen.

Dadurch lässt sich die Verarbeitung verteilen.

Warum ist das sinnvoll?

Angenommen, gleichzeitig starten:

1.000 Workflows

Eine einzige Instanz müsste alle bearbeiten.

Mit mehreren Workern können Jobs parallel verteilt werden.

Queue
↓
freie Worker

Das ermöglicht horizontale Skalierung.

Mehr Worker sind aber nicht automatisch schneller

Wenn alle Worker dieselbe externe API aufrufen und diese erlaubt:

100 Requests pro Minute

helfen:

20 Worker

nicht.

Sie produzieren nur schneller:

Rate-Limit-Fehler.

Auch beim Skalieren gilt:

Den tatsächlichen Engpass verstehen.

Datenbank kann zum Engpass werden

Mehr Worker bedeuten möglicherweise:

mehr parallele Datenbankverbindungen,

mehr Executions,

mehr Schreibvorgänge.

Darum sollte nicht nur n8n selbst betrachtet werden.

Die Infrastruktur ist ein Gesamtsystem.

Dasselbe gilt für lokale KI

Angenommen:

20 n8n-Worker.

Alle rufen gleichzeitig dieselbe GPU auf.

20 Jobs
↓
1 GPU

Nun ist nicht n8n das Problem.

Die GPU ist die begrenzte Ressource.

Dann braucht man vielleicht:

KI-Queue,

Concurrency Limit,

Batching.

Queue Mode löst Orchestrierung, nicht jede Ressourcenplanung

Das ist wichtig.

Skalierung bedeutet nicht:

mehr Worker
→ jedes Problem gelöst

Sondern:

mehr Ausführungskapazität

Die nachgelagerten Systeme müssen diese Last ebenfalls vertragen.

Für viele kleine Installationen ist Queue Mode unnötig

Wenn gleichzeitig:

zwei oder drei Workflows

laufen, bringt zusätzliche verteilte Infrastruktur wenig.

Mehr Komponenten bedeuten:

mehr Wartung,

mehr Fehlerquellen,

mehr Monitoring.

Beginne einfach.

Skaliere, wenn Messwerte zeigen, dass es nötig wird.

n8n eignet sich gut für lokale KI

n8n dokumentiert inzwischen einen eigenen Advanced-AI-Bereich und stellt Nodes für unterschiedliche Chatmodelle, Embeddings, Vektordatenbanken und AI Agents bereit. In der aktuellen Integrationsübersicht finden sich unter anderem Ollama Chat Model, Embeddings Ollama sowie verschiedene Vector Stores und AI-Agent-Nodes. (n8n Docs)

Damit kann ein Workflow beispielsweise so aussehen:

Webhook
↓
n8n
↓
lokales Modell
↓
Structured Output
↓
Datenbank

Was ist Ollama in diesem Zusammenhang?

Ollama ist eine Möglichkeit, bestimmte offene Modelle lokal bereitzustellen.

Für n8n ist das Entscheidende:

Das Modell wird über eine Schnittstelle angesprochen.

n8n
↓
Ollama
↓
lokales Modell

Aus Sicht des Workflows ist das ähnlich wie ein Cloudmodell.

Der Endpunkt liegt nur auf eigener Infrastruktur.

n8n führt aktuell eigene Ollama-Modell- und Embedding-Nodes in seiner AI-Integration auf. (n8n Docs)

Das ermöglicht hybride Workflows

Zum Beispiel:

einfache Klassifikation
↓
lokales Modell

aber:

besonders schwierige Analyse
↓
Cloudmodell

Oder:

sensible Daten
↓
nur lokal

öffentliche Recherche
↓
Cloud

Die Architektur kann je nach Aufgabe unterschiedliche Modelle verwenden.

n8n sollte nicht entscheiden, welche Daten die Cloud verlassen dürfen

Diese Regel gehört in die Workflowarchitektur.

Beispiel:

data_classification = confidential
↓
Cloudpfad gesperrt

Nicht:

Das Modell wird schon vernünftig entscheiden.

Datenschutz und Berechtigungen müssen deterministisch kontrolliert werden.

Ein lokales Modell kann wie jeder andere API-Dienst behandelt werden

Das ist architektonisch sehr attraktiv.

n8n
↓
http://ai-service/internal

Heute läuft dort Modell A.

Später Modell B.

Wenn der interne Vertrag gleich bleibt:

Workflow muss kaum verändert werden.

RAG lässt sich ebenfalls über n8n orchestrieren

Ein Dokument wird aktualisiert:

WordPress
↓
Webhook
↓
n8n
↓
Text laden
↓
Chunks
↓
Embeddings
↓
Vector Store

n8n dokumentiert sowohl Advanced-AI-Funktionen als auch zahlreiche Vector-Store- und Embedding-Nodes und besitzt einen eigenen RAG-Bereich in der Dokumentation. (n8n Docs)

Damit kann n8n die Infrastruktur aus unseren Artikeln über Embeddings, Vektordatenbanken und RAG miteinander verbinden.

n8n muss dabei nicht selbst die Vektordatenbank sein

Das ist eine wichtige Trennung.

n8n
→ orchestriert

Vector Store
→ speichert und durchsucht Vektoren

Embeddingmodell
→ erzeugt Vektoren

LLM
→ generiert Sprache

Jede Komponente übernimmt ihren eigenen Zweck.

Beispiel eines RAG-Frageworkflows

Nutzerfrage
↓
n8n
↓
Embedding erzeugen
↓
Vector Search
↓
passende Dokumente
↓
LLM
↓
Antwort

Zusätzlich:

Quellen-IDs
↓
Validierung

So entsteht eine vollständige RAG-Pipeline.

Beispiel eines Content-Workflows

Thema
↓
Recherche
↓
Quellen
↓
Briefing
↓
LLM
↓
Artikel
↓
Qualitätsprüfung
↓
interne Links
↓
WordPress

n8n hält den Prozess zusammen.

Das Sprachmodell ist nur eine Komponente darin.

WordPress passt hervorragend zu n8n

WordPress besitzt eine REST-API.

n8n kann HTTP-APIs ansprechen und bietet außerdem anwendungsspezifische Credentials beziehungsweise Integrationen für zahlreiche Dienste; die aktuelle Dokumentationsübersicht führt auch WordPress-Credentials. (n8n Docs)

Damit kann ein Workflow beispielsweise:

Entwurf erstellen,

bestehenden Beitrag lesen,

Metadaten übernehmen.

Die konkrete Operation hängt von der verwendeten WordPress-Schnittstelle und Berechtigung ab.

Ein sauberer Publishing-Workflow

Artikel erzeugt
↓
Schema prüfen
↓
SEO-Metadaten prüfen
↓
interne Links prüfen
↓
WordPress
↓
Status = draft

Dann:

Menschliche Freigabe
↓
published

Das ist robuster als:

LLM
↓
direkt live

n8n kann Human-in-the-Loop integrieren

Die aktuelle n8n-Dokumentation unterstützt in bestimmten Nodes ausdrücklich „Send and Wait for Approval“- beziehungsweise Human-in-the-Loop-Mechanismen; die Gmail-Integration kann beispielsweise eine Nachricht senden und auf eine Freigabe warten, und n8n dokumentiert außerdem Human Review für AI-Agent-Tool-Aufrufe. (n8n Docs)

Damit kann ein Prozess:

KI erstellt Vorschlag
↓
Mensch erhält Nachricht
↓
Approve / Reject
↓
Workflow läuft weiter

Das passt sehr gut zu kritischen KI-Automatisierungen.

Human-in-the-Loop sollte gezielt eingesetzt werden

Nicht:

KI macht alles
↓
Mensch muss trotzdem alles komplett prüfen

Dann entsteht kaum Nutzen.

Besser:

eindeutige Fälle
→ automatisch

unklare oder riskante Fälle
→ Mensch

n8n wird dann zur Verbindung zwischen automatischer Verarbeitung und menschlicher Entscheidung.

Was sind AI Agents in n8n?

Ein normaler Workflow sagt:

A
↓
B
↓
C

Ein Agent bekommt dagegen mehr Entscheidungsspielraum.

Zum Beispiel:

Finde die Ursache dieses Supportproblems.

Der Agent kann entscheiden:

Dokumentation suchen.

Kundenkonto prüfen.

Logdatei analysieren.

Die aktuelle n8n-Dokumentation besitzt dafür einen eigenen AI-Agent-Bereich und beschreibt auch verschiedene Tools, die Agenten verwenden können; manche normale App-Nodes sind ausdrücklich als AI Tools einsetzbar. (n8n Docs)

Das verändert die Rolle der Nodes

Normaler Workflow:

Entwickler entscheidet:
Node A → Node B

Agent:

Modell entscheidet:
Welches Tool brauche ich?

Das ist leistungsfähig.

Aber weniger vorhersehbar.

Nicht jeder n8n-Workflow braucht einen Agenten

Ein Prozess lautet:

neuer Beitrag
↓
Embedding neu berechnen

Dafür ist ein Agent überflüssig.

Der Weg ist bekannt.

Ein normaler Workflow ist:

billiger,

vorhersehbarer,

leichter testbar.

Agenten werden interessant bei offenen Aufgaben

Zum Beispiel:

Prüfe, warum die Website langsam ist.

Mögliche Schritte:

Monitoring prüfen
↓
vielleicht Logs
↓
vielleicht Datenbank
↓
vielleicht letzte Deployments

Der richtige Weg hängt von den Zwischenergebnissen ab.

Das ist agentischer.

n8n eignet sich gerade deshalb gut als Sicherheitsrahmen um Agenten

Statt dem Agenten:

beliebigen Serverzugriff

zu geben, erhält er nur definierte Tools.

Zum Beispiel:

search_documentation

read_monitoring

create_ticket_draft

Nicht:

execute_any_shell_command_as_root

Das begrenzt den Handlungsraum.

Bestimmte n8n-Nodes sind bewusst riskant

Die Security-Audit-Dokumentation weist darauf hin, dass manche offiziellen Nodes beliebigen Code oder Aktionen auf dem Host ermöglichen können und deshalb als riskant eingestuft werden. (n8n Docs)

Genau solche Fähigkeiten sollten einem Agenten nicht leichtfertig zur Verfügung stehen.

n8n als Agentenplattform braucht damit dieselben Prinzipien wie jede Agentenarchitektur

Agent
↓
begrenzte Tools
↓
strukturierte Argumente
↓
Berechtigungsprüfung
↓
gegebenenfalls Human Approval
↓
Aktion

Nicht:

Agent
↓
Vollzugriff

Das behandeln wir im nächsten Artikel noch ausführlicher.

n8n eignet sich auch hervorragend als Glue Code

„Glue Code“ bezeichnet Software, deren Hauptaufgabe darin besteht, andere Systeme miteinander zu verbinden.

Genau das macht n8n sehr häufig:

WordPress
↔
n8n
↔
Datenbank
↔
KI
↔
E-Mail

Die eigentliche Geschäftslogik entsteht aus den Verbindungen.

Der Vorteil gegenüber vielen kleinen Einzelskripten

Ohne zentrale Plattform:

script1.py
script2.php
cron3.sh
mailjob.js

verteilt auf mehreren Servern.

Nach einem Jahr weiß niemand:

Welcher Prozess läuft wann?

n8n schafft einen zentraleren Blick auf:

Workflows,

Executions,

Credentials.

Das kann Betrieb erheblich vereinfachen.

Zentralisierung besitzt aber auch einen Nachteil

Wenn sehr viele wichtige Prozesse auf derselben n8n-Instanz laufen:

n8n ausgefallen
↓
viele Automatisierungen ausgefallen

Damit wird n8n zu kritischer Infrastruktur.

Je wichtiger die Workflows werden, desto wichtiger werden:

Backups,

Monitoring,

Redundanz,

Updates.

Deshalb sollte n8n nicht wie ein Hobbytool betrieben werden, sobald das Geschäft davon abhängt

Für Experimente:

ein Container reicht.

Für zentrale Produktionsprozesse:

Betriebskonzept.

Zum Beispiel:

Reverse Proxy
↓
n8n
↓
PostgreSQL
↓
Backups
↓
Monitoring

Bei höherer Last eventuell:

Queue
↓
Worker

Die Architektur wächst mit der Bedeutung.

Test und Produktion sollten getrennt bleiben

Ein Workflow:

delete_customer

sollte nicht mit echten Kundendaten ausprobiert werden.

Besser:

Development
↓
Testdaten
↓
Production

Auch Credentials sollten getrennt sein.

CRM Test

und:

CRM Production

Pinning und Testdaten können Entwicklung erleichtern

n8n stellt Funktionen bereit, um Daten aus früheren Schritten für die Workflowentwicklung zu referenzieren und in der Oberfläche zu testen; die Dokumentation führt unter anderem Data Mapping sowie Pinning und Mocking als Werkzeuge für die Arbeit mit Testdaten auf. (n8n Docs)

Damit muss beispielsweise nicht bei jedem Test eine echte externe API erneut aufgerufen werden.

Das ist bei teuren KI-Aufrufen besonders nützlich

Statt:

Test
↓
jedes Mal LLM bezahlen

kann man für bestimmte Entwicklungsschritte mit festgehaltenen Beispieloutputs arbeiten.

Das macht Workflowentwicklung:

schneller,

billiger,

reproduzierbarer.

Trotzdem braucht der vollständige Workflow irgendwann echte End-to-End-Tests

Ein gepinnter KI-Output beweist nur:

Die nachfolgenden Nodes funktionieren mit diesem Output.

Er beweist nicht:

Das echte Modell erzeugt ihn zuverlässig.

Darum braucht es beide Ebenen:

Komponententest

und:

End-to-End-Test

n8n ist kein Ersatz für Git und professionelle Softwareentwicklung

Komplexe eigene Services:

gehören weiterhin in Code-Repositories.

Datenbankschemata:

brauchen Migrationen.

Infrastruktur:

kann als Code verwaltet werden.

n8n übernimmt Orchestrierung.

Es muss nicht jedes andere Entwicklungswerkzeug ersetzen.

Manche Workflows gehören möglicherweise besser vollständig in Code

Beispiel:

hochperformante Verarbeitung von:

50 Millionen Datensätzen.

Oder:

komplexer mathematischer Algorithmus.

Oder:

sehr niedrige Latenz im Millisekundenbereich.

Dann kann ein spezialisierter Dienst besser geeignet sein.

n8n ruft ihn anschließend vielleicht nur auf.

Wann ist n8n besonders stark?

Wenn viele unterschiedliche Systeme verbunden werden müssen.

Zum Beispiel:

Webhook
↓
CRM
↓
KI
↓
Google Sheets
↓
WordPress
↓
E-Mail

Die einzelnen Operationen sind relativ überschaubar.

Die Herausforderung liegt in ihrer Orchestrierung.

Genau dort glänzt eine Workflowplattform.

n8n ist besonders gut für Integrationsarbeit

Typische Aufgaben:

wenn X passiert
↓
hole Daten aus A
↓
wandle sie um
↓
prüfe Bedingung
↓
schreibe nach B
↓
informiere C

Das ist der Kern vieler Geschäftsprozesse.

Wann ist n8n möglicherweise zu viel?

Ein Server soll jeden Morgen:

cp file-a file-b

ausführen.

Ein einfacher Cronjob reicht.

Oder ein kleines Skript erledigt eine klar begrenzte lokale Aufgabe.

Dann bringt eine komplette Workflowplattform möglicherweise keinen zusätzlichen Nutzen.

Werkzeug nach Problem wählen

kleiner technischer Job
→ Skript

mehrere Systeme / Trigger / API-Verbindungen
→ n8n interessant

sehr komplexer eigener Algorithmus
→ eigener Service

Gesamtprozess
→ n8n orchestriert

Diese Kombination ist oft stärker als der Versuch, alles in dasselbe Werkzeug zu pressen.

Ein guter erster n8n-Workflow

Für den Einstieg muss man keine autonome KI-Fabrik bauen.

Ein hervorragendes Lernprojekt wäre:

Webhook
↓
Edit Fields
↓
IF
↓
HTTP Request
↓
E-Mail

Damit lernt man bereits:

Trigger,

Daten,

Expressions,

Bedingungen,

API,

Output.

Erst danach KI ergänzen.

Ein erster KI-Workflow

Zum Beispiel:

Webhook
↓
Nachricht
↓
LLM
↓
Structured Output
↓
Switch

Schema:

{
  "category": "support"
}

Dann:

support
↓
Support Workflow

sales
↓
Sales Workflow

Damit wird der Unterschied zwischen:

KI-Interpretation

und:

klassischer Prozesslogik

sehr klar.

Ein produktiver KI-Workflow braucht mehr

Webhook
↓
Authentifizierung
↓
Input Validation
↓
KI
↓
Structured Output
↓
Schema Validation
↓
Bedingung
↓
Aktion
↓
Logging
↓
Fehlerpfad

Das ist weniger spektakulär als eine Demo.

Aber wesentlich robuster.

Ein Content-Workflow kann später deutlich umfangreicher werden

Themenquelle
↓
Priorisierung
↓
Recherche
↓
Quellen
↓
Briefing
↓
Textmodell
↓
Faktenprüfung
↓
interne Links
↓
SEO-Daten
↓
Qualitätskontrolle
↓
WordPress-Draft
↓
Freigabe
↓
Veröffentlichung

n8n kann dabei als zentrale Orchestrierungsschicht dienen.

Der wichtigste Node ist trotzdem nicht der AI Agent

Bei realen Workflows sind oft unscheinbare Nodes entscheidend:

IF.

Switch.

HTTP Request.

Edit Fields.

Wait.

Database.

Sie bestimmen, ob ein Prozess zuverlässig arbeitet.

KI ist eine zusätzliche Fähigkeit.

Nicht das Fundament jeder Automatisierung.

Was du dir über n8n merken solltest

n8n ist eine Workflow-Automatisierungsplattform, die Anwendungen, APIs und Datenverarbeitung in grafisch aufgebauten Workflows miteinander verbindet. n8n kann als gehostete Cloudvariante oder selbst betrieben werden und unterstützt neben klassischen Integrationen inzwischen auch umfangreiche KI-Funktionen. (n8n Docs)

Das Grundprinzip lautet:

Trigger
↓
Node
↓
Node
↓
Entscheidung
↓
Node
↓
Ergebnis

Ein Node übernimmt dabei eine klar begrenzte Funktion.

Zum Beispiel:

Webhook

API Request

Daten transformieren

E-Mail senden

KI-Modell aufrufen

Daten wandern als strukturierte Items durch den Workflow und können mit Expressions beziehungsweise Datenmapping aus vorherigen Nodes in späteren Schritten verwendet werden. (n8n Docs)

Besonders universell sind:

Webhook
→ etwas von außen löst n8n aus

und:

HTTP Request
→ n8n spricht eine externe API an

Dadurch bleibt n8n auch dann verwendbar, wenn kein fertiger Integrationsnode für einen bestimmten Dienst existiert. (n8n Docs)

Für größere Workflows sind:

Subworkflows

wichtig.

Sie ermöglichen die Wiederverwendung klar abgegrenzter Fähigkeiten, statt dieselbe Logik in vielen Workflows zu kopieren. n8n führt dafür eigene Execute-Sub-workflow-Komponenten. (n8n Docs)

Für den Betrieb sind:

Executions

Logs

Fehlerpfade

Retries

Credentials

mindestens genauso wichtig wie die grafische Oberfläche. n8n führt Ausführungen zentral mit verschiedenen Zuständen und erlaubt das erneute Ausführen fehlgeschlagener Workflows. (n8n Docs)

Bei Self-Hosting kommt zusätzlich die Infrastruktur hinzu:

n8n
↓
persistente Daten
↓
Datenbank
↓
Backups
↓
Reverse Proxy
↓
Monitoring

Docker ist ein von n8n offiziell unterstützter Installationsweg. (n8n Docs)

Wächst die Last, kann die Architektur um Queue- und Worker-Komponenten erweitert werden; n8n führt diese Skalierungsmechanismen als eigene Self-Hosting-Konfiguration. (n8n Docs)

Für KI ist n8n besonders interessant, weil dieselbe Orchestrierungslogik auch Modelle und Wissenssysteme miteinander verbinden kann.

Webhook
↓
KI
↓
Structured Output
↓
Switch
↓
API

oder:

Dokument
↓
Embedding
↓
Vector Store
↓
RAG
↓
LLM

Die aktuelle n8n-Dokumentation führt dafür AI Agents, verschiedene Chatmodelle einschließlich Ollama, Embedding-Nodes und mehrere Vektordatenbank-Integrationen. (n8n Docs)

Der wichtigste Architekturgedanke bleibt jedoch:

n8n
≠
KI

n8n ist der Orchestrator.

Die KI interpretiert Sprache.

Die API liefert Daten.

Die Datenbank speichert Zustände.

Der Workflow definiert den Ablauf.

Normale Software prüft harte Regeln.

Menschen übernehmen kritische Sonderfälle.

Dadurch entsteht beispielsweise:

unstrukturierte Eingabe
↓
n8n
↓
KI interpretiert
↓
strukturierte Ausgabe
↓
n8n validiert und routet
↓
API führt definierte Aktion aus
↓
Ergebnis wird protokolliert

Genau darin liegt der eigentliche Nutzen von n8n.

Es versucht nicht, sämtliche Komponenten eines digitalen Systems zu ersetzen.

Es verbindet sie zu einem Prozess.