n8n mit einem lokalen Modell verbinden

In Level 3 hast Du gelernt, wie Automatisierung funktioniert, und im ersten n8n-Flow einen Ablauf gebaut, der von selbst läuft. Sobald in so einem Ablauf ein KI-Schritt sitzt, wandert bei jedem Durchlauf ein Stück Deiner Daten zu einem Anbieter. Bei zehn Durchläufen am Tag denkt man darüber nicht nach. Bei zweitausend schon, und spätestens dann, wenn in den Daten Kundennamen stehen.

Dieses Playbook hängt an die Stelle, an der sonst der Cloud-Knoten sitzt, ein Modell auf Deinem eigenen Rechner. Der schwierige Teil daran ist nicht die KI. Es ist das Netzwerk, weil n8n und Ollama fast nie am selben Ort laufen. Genau dort hakt es bei fast allen, und deshalb bekommt das gleich zwei eigene Schritte.

1. Klär zuerst, ob sich das für Deinen Flow überhaupt lohnt

Es gibt zwei Fälle, in denen lokal im Automatisierungs-Strang klar gewinnt. Der eine ist Masse: Wenn ein Flow tausendfach am Tag läuft und jedes Mal ein paar Cent kostet, wird aus der Nebensache ein Posten. Der andere ist Vertraulichkeit: Wenn durch den Flow Daten laufen, die das Haus nicht verlassen dürfen, ist die Frage nach dem Anbieter gar nicht erst zu stellen.

Es gibt aber auch den Fall, in dem lokal die falsche Antwort ist. Wenn Dein Flow dreimal am Tag läuft und dabei eine anspruchsvolle Formulierung braucht, ist der Cloud-Knoten günstiger und besser. Drei Anfragen täglich bei einem großen Modell kosten weniger als der Strom für einen Rechner, der durchgehend bereitstehen muss.

Tipp: Zähl vor der Umstellung einmal nach, wie oft Dein Flow im letzten Monat tatsächlich gelaufen ist. Die geschätzte Zahl liegt fast immer zu hoch.

2. Stell Ollama zuerst auf reinen Ortsbetrieb

Bevor es ans Netzwerk geht, eine Einstellung, ohne die der ganze Zweck dieses Playbooks wackelt. Ollama kann Modelle in seiner eigenen Cloud ausführen, und der Aufruf dafür geht über denselben Zugang auf Deinem Rechner, localhost:11434. Von außen sieht ein Cloud-Modell also aus wie ein lokales. Wählst Du eines, verlassen Deine Anfragen und die Antworten den Rechner, ohne dass sich an Deinem Flow irgendetwas ändert.

Für ein Datenschutz-Playbook ist das kein Detail, sondern die Grundeinstellung. Setz OLLAMA_NO_CLOUD=1 und starte Ollama neu. Unter Linux mit systemd gehört die Variable in den Dienst, nicht in Deine Shell:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NO_CLOUD=1"

Danach sudo systemctl daemon-reload und sudo systemctl restart ollama. Im Container gibst Du die Variable beim Start mit, also -e OLLAMA_NO_CLOUD=1. Es gibt daneben eine Einstellungsdatei mit "disable_ollama_cloud": true, aber Vorsicht damit unter Linux: Der Dienst läuft dort als eigener Benutzer ollama und liest deshalb nicht die Datei in Deinem Heimatverzeichnis. Der Weg über den Dienst ist der eindeutige.

Und jetzt der Teil, den ich Dir nicht ersparen kann, auch wenn er unbequem ist: Verlass Dich nicht auf den Namen des Modells. Viele Cloud-Modelle tragen ein -cloud oder :cloud im Namen, aber das ist eine Konvention und keine Grenze. ollama list hilft Dir hier auch nicht weiter, es zeigt Deine installierten Modelle und nicht den Zustand der Einstellung. Ob der Ortsbetrieb wirklich greift, steht nach dem Neustart im Protokoll von Ollama, als Zeile Ollama cloud disabled: true. Sieh dort einmal nach, dann weißt Du es.

Tipp: Der Port 11434, auf dem Ollama seinen Dienst bereitstellt, ist standardmäßig nur für den Rechner selbst erreichbar. Das ist gut so, denn diese Schnittstelle hat keine Anmeldung. Wer sie erreicht, kann Modelle laden, ausführen und auch löschen. Merk Dir den Satz für Schritt 4.

3. Versteh, dass das eigentliche Problem Netzwerk heißt

n8n muss den Ollama-Dienst erreichen können. Ob das ohne Weiteres geht, hängt davon ab, ob eins der beiden, beide oder keins von beiden in einem Container läuft. Das ist die ganze Schwierigkeit, und wer sie einmal verstanden hat, hat den Rest in zehn Minuten.

Die naheliegende Abkürzung liest man in vielen Anleitungen: Ollama einfach auf allen Schnittstellen lauschen lassen, also auf 0.0.0.0. Das ist die Zeile, die aus einem privaten Dienst einen offenen macht, denn dann hängt eine Schnittstelle ohne Anmeldung an Deinem Netz. Dieses Playbook zeigt sie deshalb nicht. Für jede Konstellation steht unten der Weg, der ohne sie auskommt.

Tipp: Wenn im n8n-Knoten später "connection refused" steht, ist das praktisch nie ein Problem des Modells. Es ist immer diese Frage hier.

4. Nimm die Konstellation, die auf Dich zutrifft

Fünf Fälle, und für jeden gilt eine andere Adresse.

Beides direkt auf dem Rechner installiert, ohne Container. Der einfachste und der sicherste Fall, weil nichts nach außen muss. In den Ollama-Zugangsdaten trägst Du http://localhost:11434 ein, fertig.

Beide in getrennten Containern. Der übliche Fall, sobald Du mit Compose arbeitest, und der, den ich empfehlen würde. Beide Container kommen in dasselbe eigene Docker-Netz und reden über den Container-Namen miteinander. Ollama braucht dann überhaupt keinen veröffentlichten Port:

docker network create ollama-net
docker run -d --restart unless-stopped --network ollama-net -e OLLAMA_NO_CLOUD=1 \
  -v ollama:/root/.ollama --name ollama ollama/ollama
docker run -d --restart unless-stopped --network ollama-net --name n8n \
  -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Die Adresse in n8n ist dann http://ollama:11434, also der Container-Name. Hier ist der häufigste Fehler, localhost einzutragen: Das zeigt auf den n8n-Container selbst, dort lauscht nichts, und Du bekommst ECONNREFUSED.

Nur Ollama läuft im Container, n8n direkt. Du startest Ollama mit einem Port, der ausdrücklich nur auf dem eigenen Rechner erscheint:

docker run -d --restart unless-stopped -e OLLAMA_NO_CLOUD=1 \
  -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 \
  --name ollama ollama/ollama

Das 127.0.0.1: vor dem Port ist der ganze Unterschied. Ohne diesen Vorsatz veröffentlicht Docker den Port auf allen Schnittstellen des Rechners. Eine Voraussetzung gehört dazu: Erst ab Docker Engine 28 hält diese Beschränkung wirklich dicht, in älteren Fassungen konnten Rechner im selben Netzsegment solche Ports trotzdem erreichen. Sieh mit docker version nach, und wenn Du darunter liegst, aktualisier zuerst. Die Adresse in n8n bleibt http://localhost:11434.

Nur n8n läuft im Container, Ollama direkt auf dem Rechner. Das ist der unbequeme Fall, denn der Container erreicht 127.0.0.1 des Hosts nicht. Unter Linux gibt es dafür einen Weg, der ohne 0.0.0.0 auskommt: Du bindest Ollama an genau die Adresse, unter der der Host aus dem Container heraus sichtbar ist, das Tor des Docker-Netzes. Diese Adresse liest Du aus, statt sie zu raten:

docker network inspect bridge -f '{{(index .IPAM.Config 0).Gateway}}'

Üblicherweise kommt 172.17.0.1 heraus. Genau das trägst Du in den Dienst ein, wieder über sudo systemctl edit ollama.service:

[Service]
Environment="OLLAMA_HOST=172.17.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Diese Adresse gehört dem Docker-Netz und ist von Deinem Netz aus nicht erreichbar. Der Container braucht dann noch die Brücke zum Host:

docker run -d --restart unless-stopped --add-host host.docker.internal:host-gateway \
  --name n8n -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Die Adresse in n8n lautet dann http://host.docker.internal:11434. Wichtig ist, dass beide dasselbe Netz meinen: Läuft Dein n8n-Container in einem eigenen Netz statt im Standard-Netz, nimm dessen Tor-Adresse, nicht die von bridge.

Unter macOS und Windows gibt es diese Abkürzung nicht. Dort läuft Docker in einer eigenen kleinen Maschine, und der Host ist für den Container nur über eine Bindung an alle Schnittstellen erreichbar. Dicht bekommst Du das dann nur noch über den Firewall des Betriebssystems, also eine Regel, die eingehende Verbindungen auf 11434 aus dem übrigen Netz abweist. Das ist Handarbeit, die man vergisst. Nimm auf diesen Systemen deshalb die Konstellation mit den zwei Containern von oben. Das ist keine Ausweichlösung, sondern schlicht die bessere.

Beide im selben Container. Kommt selten vor, funktioniert aber ohne alles Weitere, http://localhost:11434 genügt.

Einen Sonderfall gibt es noch, und er sieht aus wie ein Docker-Problem, ist aber keins. Wenn die Meldung connect ECONNREFUSED ::1:11434 lautet, hat Dein System localhost auf die IPv6-Adresse aufgelöst, während Ollama auf IPv4 lauscht. Die beiden reden dann aneinander vorbei. Trag als Basis-Adresse http://127.0.0.1:11434 ein statt http://localhost:11434, damit ist es erledigt. Die zwei Doppelpunkte vor der Portnummer sind das Erkennungsmerkmal.

Tipp: Ein frischer Container bringt kein Modell mit, das Volume ist leer. Hol Dir eins und sieh nach, dass es da ist, bevor Du in n8n weitermachst:

docker exec ollama ollama pull <modellname>
docker exec ollama ollama list

Bei einer Installation ohne Container heißen die beiden Befehle einfach ollama pull und ollama list. Und achte in allen Beispielen auf -d --restart unless-stopped: Ein Container, den Du mit -it --rm startest, hängt an Deinem Terminal, verschwindet beim Beenden restlos, und nach einem Neustart des Rechners kommt Deine Automatisierung nicht wieder hoch.

5. Leg die Zugangsdaten in n8n an

In n8n legst Du unter den Zugangsdaten einen neuen Ollama-Eintrag an. Das einzige Pflichtfeld ist die Basis-Adresse aus Schritt 4. Ein Schlüssel wird für eine lokale Instanz nicht gebraucht, das Feld bleibt leer.

Danach kannst Du die Verbindung direkt in n8n testen. Wenn der Test durchgeht, ist der schwierige Teil erledigt.

Tipp: Läuft Dein Modell auf einem anderen Rechner im Netz, reicht keine der Konstellationen von oben. Dann brauchst Du zwei Dinge zusammen. Erstens eine verschlüsselte Verbindung, also https:// mit geprüftem Zertifikat oder einen Tunnel wie WireGuard. Über einfaches http:// wandern Schlüssel, Anfragen und Antworten lesbar durchs Netz, und damit ist der Zweck dieses Playbooks dahin. Zweitens eine Anmeldung davor, etwa Open WebUI, dessen Ollama-Zugang unter dem Pfad /ollama liegt. Die Basis-Adresse sieht dann aus wie https://deinserver/ollama, und den Schlüssel trägst Du im Feld daneben ein.

6. Kenn den Unterschied zwischen den drei Ollama-Knoten

Das ist die Stolperfalle, die Dich sonst einen Abend kostet. n8n hat drei Knoten für Ollama, und zwei davon sehen fast gleich aus.

Der eine heißt schlicht Ollama Model. Er kann keine Werkzeuge aufrufen. Das steht so in der Dokumentation, und die Folge daraus ist eindeutig: Mit dem AI-Agent-Knoten funktioniert er nicht. Er gehört an die Basic LLM Chain.

Der zweite heißt Ollama Chat Model. Den nimmst Du für Gespräche und für alles, was mit dem Agenten zusammenarbeiten soll.

Der dritte heißt Embeddings Ollama und erzeugt gar keinen Text, sondern Vektoren. Den brauchst Du nur, wenn Du eine Vektor-Datenbank lokal befüllst. Eine Regel gehört dazu: Befüllen und Abfragen müssen mit demselben Modell laufen. Was dann passiert, hängt davon ab, wie ähnlich sich die Modelle sind. Haben sie unterschiedlich lange Vektoren, weist die Datenbank die Anfrage meist mit einer klaren Meldung ab. Sind die Längen zufällig gleich, bekommst Du gar keinen Fehler, sondern nur noch schlechte Treffer, und das ist der ärgerlichere Fall.

Der richtige Knoten ist aber nur die halbe Bedingung. Werkzeug-Aufrufe muss auch das Modell selbst beherrschen, und das können längst nicht alle. Nimmst Du ein Modell ohne diese Fähigkeit, ist der Knoten korrekt verdrahtet, der Agent läuft, und trotzdem benutzt er nie ein Werkzeug. Ollama führt die unterstützten Modelle in einer eigenen Kategorie, und die ist beim Aussuchen die verbindliche Liste.

Tipp: Merk Dir die Faustregel in ihrer vollständigen Form: Chain nimmt Model, Agent nimmt Chat Model plus ein Modell aus Ollamas Tools-Kategorie. Fehlt der zweite Teil, suchst Du den Fehler an einer Stelle, an der er nicht sitzt.

7. Bau den ersten Flow mit der Basic LLM Chain

Fang bewusst klein an, nicht mit einem Agenten. Die Basic LLM Chain macht genau eine Sache: Sie schickt Deinen Text an das Modell und gibt die Antwort zurück. Kein Gedächtnis, keine Werkzeuge, keine Entscheidungen.

Für den typischen Automatisierungs-Schritt ist das genau richtig. Eine eingehende Nachricht einsortieren, einen Text zusammenfassen, aus einem Freitext ein Feld herausziehen. Der Agent ist erst dann nötig, wenn das Modell selbst entscheiden soll, welches Werkzeug es benutzt.

Eine Eigenart musst Du dabei kennen, weil sie still danebengeht. Die Chain selbst arbeitet Deine Datensätze ordentlich der Reihe nach ab, jeder bekommt seinen eigenen Prompt. Der angehängte Modell-Knoten ist aber ein Unterknoten, und Ausdrücke in dessen eigenen Feldern lösen immer zum ersten Datensatz auf. Wenn Du also im Modell-Knoten selbst mit einem Ausdruck arbeitest, etwa um je Datensatz ein anderes Modell zu wählen, bekommst Du fünfmal die Wahl des ersten. Der Flow läuft durch und meldet nichts. Im Prompt der Chain passiert das nicht.

Tipp: Wenn Du unsicher bist, ob Du Chain oder Agent brauchst: Wenn Du die Schritte vorher aufschreiben kannst, nimm die Chain. Der Agent ist für den Fall, in dem Du sie nicht kennst, und er kostet dafür Vorhersagbarkeit.

8. Wähl ein kleines Modell mit enger Aufgabe

Im Chat willst Du ein möglichst kluges Modell. In der Automatisierung willst Du ein möglichst vorhersagbares. Das ist ein anderer Maßstab, und er führt fast immer zu einem kleineren Modell.

Ein Flow ruft immer dieselbe Aufgabe auf. Diese eine Aufgabe schafft ein kleines Modell zuverlässig, wenn Du den Auftrag eng genug stellst. Und ein kleines Modell antwortet schneller, was bei tausend Durchläufen der eigentliche Gewinn ist. Welche Größe zu Deiner Hardware passt, steht in Welches lokale Modell zu Deiner Hardware passt.

Tipp: Widersteh der Versuchung, im Flow das größte Modell zu nehmen, das noch läuft. Bei Massenverarbeitung entscheidet der Durchsatz, nicht die letzte Nuance in der Formulierung.

Noch ein Hinweis zur Auswahl: Die Modell-Liste in der n8n-Dokumentation ist veraltet, sie zeigt Stand August 2026 noch Namen aus der Llama-2-Generation. Welche Modelle Du wirklich hast, sagt Dir ollama list auf Deinem eigenen Rechner. Nimm die Ausgabe, nicht die Doku-Liste.

9. Rechne mit anderen Wartezeiten als bei der Cloud

Ein Cloud-Anbieter beantwortet zehn gleichzeitige Anfragen gleichzeitig. Dein Rechner in der Standardeinstellung nicht: Ollama bearbeitet pro Modell eine Anfrage zur Zeit, weil OLLAMA_NUM_PARALLEL auf 1 steht. Wenn Dein Flow parallel läuft, stehen die Anfragen also Schlange. Du kannst den Wert hochsetzen, bezahlst das aber mit Arbeitsspeicher.

Das merkst Du im Test nicht, weil Du dort einzeln auslöst. Im Betrieb läuft dann eine Zeitüberschreitung in einen Fehler, den Du im Testlauf nie gesehen hast.

Beim Suchen nach der Wartezeit-Einstellung landen viele im Modell-Knoten. Dort gibt es sie nicht, das Optionsschema des Ollama-Chat-Model-Knotens kennt kein Zeitlimit für die Anfrage. n8n regelt das an drei anderen Stellen, und die haben ärgerlicherweise unterschiedliche Einheiten. N8N_AI_TIMEOUT_MAX gilt genau für die KI-Knoten, also auch für Ollama, und steht auf 3.600.000 Millisekunden, das ist eine Stunde. EXECUTIONS_TIMEOUT begrenzt jeden Workflow und steht selbst gehostet auf -1, also unbegrenzt. EXECUTIONS_TIMEOUT_MAX ist die Obergrenze, die ein Nutzer im einzelnen Workflow setzen darf, in Sekunden, standardmäßig 3600. Dazu kommen die Einstellungen des Workflows selbst.

Ein Missverständnis noch, weil es Zeit kostet: Ein Reverse Proxy vor n8n begrenzt nur, wie lange Dein Browser auf n8n warten darf. Auf den Aufruf von n8n zu Ollama hat er keinen Einfluss. Wer dort ein Limit setzen will, muss den Proxy vor Ollama stellen.

Eine letzte Einstellung sitzt bei Ollama. OLLAMA_MAX_LOADED_MODELS steht auf den meisten Plattformen auf drei bei reiner Prozessorberechnung, beziehungsweise auf dem Dreifachen der Grafikkarten-Anzahl; unter Windows mit einer Radeon-Karte ist es derzeit eins. Mehrere Modelle bleiben aber nur dann gleichzeitig geladen, wenn sie zusammen in den verfügbaren Speicher passen, sonst wird entladen und gewartet. Auf einer knapp bemessenen Maschine sieht dieses Warten wie ein n8n-Fehler aus. Arbeitet Dein Ablauf ohnehin mit genau einem Modell, setz die Variable auf 1.

Tipp: Test Deinen Flow einmal mit zwanzig Datensätzen am Stück, nicht mit einem. Erst dann siehst Du das echte Verhalten, und zwar bevor es Dir im Betrieb um die Ohren fliegt.

10. Erzwing die Struktur und halt Dir die Rückfahrkarte offen

Ein kleines Modell hält sich schlechter an Formatvorgaben als ein großes. Wenn Dein nächster Schritt im Flow ein sauberes JSON erwartet und das Modell einen einleitenden Satz davorschreibt, bricht der ganze Ablauf. Lös das nicht mit einem höflicheren Prompt, sondern mit einem Knoten, der die Struktur prüft und im Zweifel neu anfragt. Wie das sauber geht, steht in Verlässliches JSON aus AI.

Und bau den Flow so, dass Du den KI-Knoten austauschen kannst, ohne den Rest anzufassen. Wenn der lokale Weg für einen bestimmten Schritt nicht reicht, willst Du dort einen Cloud-Knoten einsetzen können und alles andere behalten.

Dabei gibt es eine Falle, die genau das Versprechen vom Anfang aushebelt. Wenn Du einen lokalen Knoten gegen einen Cloud-Knoten tauschst, wandert derselbe Datensatz weiter, den vorher das lokale Modell gesehen hat, und in n8n hängen an einem Datensatz oft mehr Felder als im Prompt sichtbar sind. Zu wissen, welcher Schritt was sieht, reicht deshalb nicht. Setz vor jeden Cloud-Zweig einen Edit-Fields-Knoten, schalt darin "Include Other Input Fields" aus und ordne ausdrücklich nur die Felder zu, die rausgehen dürfen. Dann sieh Dir im Testlauf an, was tatsächlich gesendet wurde. Für Daten, die das Haus überhaupt nicht verlassen dürfen, gibt es keinen Cloud-Zweig, auch keinen für den Notfall.

Tipp: Schreib Dir in eine Notiz im Flow, welche Daten an welchem Knoten anliegen. In drei Monaten weißt Du das nicht mehr, und dann triffst Du die Entscheidung neu, ohne die Grundlage zu kennen.

Was als nächstes

Wenn Du dieselbe Verbindung nicht nur in n8n, sondern auch für Deinen KI-Assistenten selbst nutzen willst, geht es weiter mit MCP mit lokalen Modellen. Willst Du wissen, ob sich der Betrieb eines dauerhaft laufenden Rechners für Dich rechnet, steht die Rechnung in Lokal oder Cloud, die ehrliche Rechnung.

Quellen

• n8n, Ollama Chat Model, Knotenparameter und Optionen: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/
• n8n, bekannte Probleme des Ollama-Chat-Model-Knotens, darunter die Docker-Konstellationen, die IPv6-Auflösung und die Ausdrucks-Auflösung in Unterknoten: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/common-issues/
• n8n, Ollama Model, Hinweis auf die fehlende Werkzeug-Unterstützung: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmollama/
• n8n, Agent im Vergleich zur Chain: https://docs.n8n.io/advanced-ai/examples/understand-agents/
• n8n, Ollama-Zugangsdaten inklusive Bearer-Token: https://docs.n8n.io/integrations/builtin/credentials/ollama/
• n8n, die drei Zeitlimits und ihre Einheiten: https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions/
• n8n, Edit Fields und das Weiterreichen von Feldern: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.set/
• Ollama, Cloud-Modelle über den lokalen Zugang: https://docs.ollama.com/cloud
• Ollama, Server-Konfiguration, Cloud abschalten, Bindung und Parallelität: https://docs.ollama.com/faq
• Ollama, die lokale Schnittstelle hat keine Anmeldung: https://docs.ollama.com/api/authentication
• Ollama, Modelle mit Werkzeug-Unterstützung: https://ollama.com/blog/tool-support
• Docker, Ports veröffentlichen und was sich mit Engine 28 geändert hat: https://docs.docker.com/engine/network/port-publishing/
• Docker, Container automatisch wieder starten: https://docs.docker.com/engine/containers/start-containers-automatically/
• Open WebUI, der Ollama-Zugang unter /ollama: https://docs.openwebui.com/reference/api-endpoints/