n8n mit Ollama: lokale KI-Modelle ohne Cloud anbinden

n8n verbindet sich mit Ollama über eine eigene Ollama-Credential, in der Sie lediglich eine Base URL (Standard: http://localhost:11434) und optional einen API-Key hinterlegen. Danach lassen sich lokale Sprachmodelle über den Ollama Model Node oder den Ollama Chat Model Node in Workflows einbinden, ohne dass Prompt-Daten an einen Cloud-Anbieter übertragen werden. Der Ollama Model Node eignet sich für einfache Ketten mit der Basic LLM Chain, unterstützt laut n8n-Dokumentation aber kein Tool-Calling. Für KI-Agenten mit Werkzeugzugriff ist der Ollama Chat Model Node die richtige Wahl, wobei nicht jedes lokale Modell zuverlässig Funktionsaufrufe beherrscht. Stand: Juli 2026.

Wie richten Sie die Ollama-Zugangsdaten in n8n ein?

In n8n legen Sie zunächst eine Ollama-Credential an, die aus zwei Feldern besteht: der Base URL Ihrer Ollama-Instanz und einem optionalen API-Key für Bearer-Token-Authentifizierung bei entfernten oder per Proxy abgesicherten Installationen. Die Standard-Base-URL lautet http://localhost:11434. Wenn Sie auf Ihrem Ollama-Server die Umgebungsvariable OLLAMA_HOST gesetzt haben, tragen Sie stattdessen genau diesen Wert ein, wie die offizielle n8n-Dokumentation zu Ollama-Credentials beschreibt. Bei Verbindungsfehlern mit der IPv6-Meldung "ECONNREFUSED ::1:11434" hilft es häufig, localhost durch die IPv4-Adresse 127.0.0.1 zu ersetzen.

Was ist der häufigste Stolperstein in Docker-Umgebungen?

Der klassische Fehler entsteht, weil jeder Docker-Container einen eigenen localhost-Namespace besitzt, wodurch n8n und Ollama sich in getrennten Containern nicht automatisch erreichen. Läuft nur Ollama in Docker und n8n direkt auf dem Host, genügt es, den Port mit -p 11434:11434 freizugeben und in n8n weiterhin http://localhost:11434 einzutragen. Läuft dagegen n8n im Container und Ollama auf dem Host-System, müssen Sie in der Ollama-Credential http://host.docker.internal:11434 statt localhost verwenden. Unter Linux benötigt der n8n-Container dafür zusätzlich das Flag --add-host host.docker.internal:host-gateway beziehungsweise den passenden extra_hosts-Eintrag in der Docker-Compose-Datei, da Docker Desktop diese Namensauflösung automatisch bereitstellt, reine Linux-Server-Installationen aber nicht. Laufen beide Dienste als getrennte Container im selben Docker-Netzwerk, verwenden Sie stattdessen den Container-Namen von Ollama als Host, zum Beispiel http://my-ollama:11434. Diese Unterscheidung ist in den Hinweisen zu bekannten Problemen des Ollama-Chat-Model-Node dokumentiert.

Ollama Model Node oder Ollama Chat Model Node: welchen Node brauchen Sie?

n8n bietet zwei unterschiedliche Sub-Nodes für Ollama, und die Wahl entscheidet direkt darüber, ob Ihr Workflow später Werkzeuge aufrufen kann. Der Ollama Model Node unterstützt laut Dokumentation ausdrücklich kein Tool-Calling und lässt sich deshalb nicht an den AI Agent Node anschließen, sondern gehört an die Basic LLM Chain für einfache Prompt-Antwort-Aufgaben ohne Werkzeugzugriff. Der Ollama Chat Model Node ist dagegen für Konversationsszenarien und die Anbindung an Agenten-Workflows gedacht und bietet Parameter wie Sampling Temperature, Top K und Top P zur Steuerung der Antwortvielfalt. Das konkrete Modell wählen Sie über ein Dropdown aus den lokal per ollama pull heruntergeladenen Modellen aus.

Wo liegen die Grenzen beim Tool-Calling mit lokalen Modellen?

Tool-Calling ist ehrlich gesagt die größte Schwachstelle beim lokalen Betrieb: Nicht jedes über Ollama bereitgestellte Modell unterstützt zuverlässige Funktionsaufrufe, selbst wenn sich der Ollama Chat Model Node technisch an einen Tools Agent anschließen lässt. Ältere oder kleinere Modelle neigen dazu, Werkzeugaufrufe falsch zu formatieren, Parameter zu erfinden oder Tools schlicht zu ignorieren, was bei produktiven Automatisierungen zu stillen Fehlern führen kann. Wer verlässliches Tool-Calling braucht, sollte gezielt Modelle testen, die dafür trainiert wurden, und die Ergebnisse vor dem produktiven Einsatz stichprobenartig prüfen, statt sich blind auf die Ausgabe zu verlassen. Für Unternehmen, die eine belastbare Einschätzung brauchen, welches Setup aus Cloud- und lokalen Modellen zu ihrem Anwendungsfall passt, bietet NordFlux eine Beratung zu KI-Agenten an, die genau diese Abwägung zwischen Datenhoheit, Kosten und Zuverlässigkeit einschließt.

Häufige Fragen zu n8n und Ollama

Läuft Ollama zwingend auf demselben Server wie n8n?

Nein, Ollama kann auch auf einem separaten Rechner oder Server laufen, solange n8n die Base URL dieser Instanz erreichen kann. In diesem Fall tragen Sie in der Ollama-Credential die IP-Adresse oder den Hostnamen des Ollama-Servers ein und sichern die Verbindung bei Bedarf über den optionalen API-Key ab.

Warum meldet n8n "ECONNREFUSED" obwohl Ollama läuft?

Diese Fehlermeldung tritt häufig auf, wenn n8n über IPv6 auf die Adresse ::1 statt über IPv4 auf 127.0.0.1 verbindet, Ollama aber nur auf der IPv4-Adresse lauscht. Ersetzen Sie in der Base URL localhost durch 127.0.0.1, um den Fehler zu beheben.

Funktioniert der Ollama Model Node mit dem AI Agent Node?

Nein, laut n8n-Dokumentation fehlt dem Ollama Model Node die Tool-Unterstützung, weshalb er nicht mit dem AI Agent Node zusammenarbeitet. Für Agenten-Workflows mit Werkzeugzugriff verwenden Sie stattdessen den Ollama Chat Model Node, müssen aber die Tool-Calling-Fähigkeit des gewählten Modells selbst prüfen.

Unterstützt n8n auch Proxy-Verbindungen zu Ollama?

Nur eingeschränkt: Ollama selbst unterstützt keine benutzerdefinierten HTTP-Agenten, sodass klassische HTTP- oder HTTPS-Proxy-Konfigurationen zwischen n8n und Ollama problematisch sein können. Für abgesicherte Remote-Verbindungen ist die Bearer-Token-Authentifizierung über den optionalen API-Key in der Credential der zuverlässigere Weg.