Lokalen AI Agent mit n8n + Ollama auf Windows VPS aufbauen: Bebilderte Schritt-für-Schritt-Anleitung

Diese Anleitung installiert die n8n-Workflow-Automatisierungsplattform mit npm auf Windows Server, verbindet sie mit der lokalen Ollama-API und baut einen Chat-Trigger-→-AI-Agent-→-Ollama-Chat-Model-Ablauf. Die Modellausführung bleibt über Ollama auf dem VPS, während n8n Trigger, Agent und optionale Tools verwaltet.

Die getestete Umgebung nutzte Node.js 22.23.2, npm 12.0.2, Ollama 0.32.6 und n8n 2.33.7. Erste Tests erfolgten mit functiongemma:latest, danach wurde qwen3:1.7b für ein allgemeineres mehrsprachiges Agent-Szenario ergänzt. Diese Versionen entsprechen der realen Testumgebung vom 9. August 2026.

Chat Trigger → AI Agent
                   ├── Ollama Chat Model → 127.0.0.1:11434
                   └── Calculator Tool

n8n Editor → localhost:5678

Wir starteten Windows PowerShell als Administrator. Da n8n über npm installiert wird, müssen Node.js und npm verfügbar sein. Zusätzlich prüften wir die Ollama-Version und bereits installierte Modelle.

Der Testserver meldete Node.js v22.23.2, npm 12.0.2 und Ollama 0.32.6. Die offizielle n8n-npm-Installationsdokumentation verlangt aktuell Node.js von 20.19 bis 24.x, Node.js 22 lag also im unterstützten Bereich.

node --version
npm --version
ollama --version
ollama list

Wir installierten n8n global über npm. Während der Installation können zahlreiche Peer-Dependency- und Deprecated-Warnungen erscheinen; entscheidend ist, dass der Befehl abschließt und Pakete meldet, statt mit einem fatalen Fehler abzubrechen.

Die erste Installation fügte 2162 Pakete hinzu und n8n --version lieferte 2.33.7. Bei der späteren sauberen Neuinstallation fixierten wir [email protected], damit die getestete Umgebung konsistent blieb.

npm install -g n8n

n8n --version

Beim ersten n8n-Start wurde die Datenbankverbindung mehrfach erneut versucht und schlug fehl, weil das SQLite-Paket nicht verfügbar war. Die npm-Installationsausgabe hatte bereits gezeigt, dass das Install-Script von sqlite3 blockiert war, weshalb n8n beendete, bevor Port 5678 geöffnet wurde.

Wir erlaubten nur das sqlite3-Install-Script auf Benutzerebene, entfernten die bestehende globale n8n-Installation und installierten dieselbe n8n-Version sauber neu. Nach der Neuinstallation stand sqlite3 nicht mehr auf der Blockliste, und n8n konnte mit den Datenbank-Migrationen fortfahren.

Nur das tatsächlich benötigte Paket freizugeben ist kontrollierter, als global alle Install-Scripts zu erlauben. Das npm-Verhalten kann sich je nach Version unterscheiden, daher tritt dieses Problem nicht zwingend auf jedem System auf.

npm config set allow-scripts=sqlite3 --location=user

npm config get allow-scripts

npm uninstall -g n8n

npm install -g [email protected]

n8n --version

Nach der SQLite-Korrektur führte n8n beim ersten Start seine Datenbank-Migrationen aus. Das Terminal meldete anschließend n8n 2.33.7 und „Editor is now accessible via: http://localhost:5678“.

Im Terminal erschienen außerdem Warnungen zum Python Task Runner und zu künftigen Konfigurationsänderungen. Sie verhinderten in diesem Test nicht den Start des Editors. Diese Anleitung konzentriert sich auf eine funktionale Windows-Integration; für dauerhaften Produktivbetrieb sollten Sie zusätzlich die aktuellen offiziellen Self-Hosting-Empfehlungen prüfen.

n8n

http://localhost:5678

Beim ersten Browserzugriff zeigte n8n das Formular zur Owner-Konto-Einrichtung. Nach Eingabe von E-Mail, Name und einem starken Passwort zeigte n8n einen kurzen Personalisierungs-Fragebogen.

n8n bot außerdem einen kostenlosen Aktivierungsschlüssel für ausgewählte Registered-Community-Edition-Funktionen an. Dieser Schritt ist optional. In der Testumgebung forderten wir den Key an, aktivierten ihn unter Settings → Usage and plan und bestätigten das „Registered“-Badge.

Entfernen Sie vor der Veröffentlichung von Screenshots E-Mail-Adressen, Aktivierungsschlüssel oder andere Informationen gemäß Ihrer eigenen Veröffentlichungsrichtlinie.

Bevor wir AI-Nodes in n8n verdrahteten, bestätigten wir, dass die lokale Ollama-API tatsächlich antwortete. Der Aufruf von /api/tags aus PowerShell lieferte die installierten Modelle FunctionGemma und Gemma3 als JSON. Damit stand fest, dass spätere n8n-Probleme nicht einfach daran lagen, dass Ollama komplett offline war.

Da n8n und Ollama auf demselben Windows VPS laufen, ist das Ziel der lokale Port 11434. Ollama auf einer lokalen Schnittstelle zu belassen statt es direkt öffentlich freizugeben, bietet einen sichereren Ausgangspunkt.

Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/tags" -Method Get | ConvertTo-Json -Depth 5

Wir fügten den Node „When chat message received“ als Chat-Trigger hinzu, ergänzten dann AI Agent und verbanden den main-Ausgang des Triggers mit dem Eingang von AI Agent.

Diese main-Verbindung ist entscheidend. Speichert das Workflow-JSON für Chat Trigger eine leere main-Verbindung, kann die eingehende Nachricht im Trigger-Ausgang erscheinen, während AI Agent nie automatisch startet. Wir haben dies später auf JSON-Ebene geprüft und korrigiert.

Über den Chat-Model-Eingang von AI Agent öffneten wir Language Models und fügten Ollama Chat Model hinzu. Zunächst probierten wir die n8n-Standard-Base-URL http://localhost:11434, doch die getestete Windows-Umgebung meldete einen Connection-refused-Fehler.

PowerShell hatte bereits gezeigt, dass dieselbe Ollama-API unter 127.0.0.1 antwortete, daher änderten wir die Base URL auf http://127.0.0.1:11434. Danach ließ sich die Credential speichern. Für die lokale Standard-Ollama-Instanz war kein API-Key erforderlich.

Die Modelloptionen luden zunächst nicht und zeigten „Error fetching options“. Nach Refresh List im Modellfeld erschienen functiongemma:latest und gemma3:270m. Die Serviceverbindung war also gültig; die UI-Modellliste musste lediglich aktualisiert werden.

http://127.0.0.1:11434

Als erstes Agent-Modell wählten wir functiongemma:latest. Die Ollama-API-Ausgabe zeigte, dass dieses Modell eine Tools-Fähigkeit besitzt, und wir verbanden den Calculator-Node mit dem Tool-Eingang von AI Agent.

FunctionGemma ist klein und auf Function Calling statt auf natürliche Gesprächsqualität ausgelegt. Sein Verhalten im türkischen Chat war in diesem Test eingeschränkt, weshalb wir für ein allgemeineres mehrsprachiges Agent-Szenario zu Qwen3 wechselten.

Wir luden qwen3:1.7b herunter, da die Qwen3-Familie besser für mehrsprachige Anweisungen und Agent/Tool-Szenarien geeignet ist. Der Download war bei rund 1,4 GB abgeschlossen, und das Modell erschien in ollama list.

Das 1.7B-Modell wurde gewählt, um den VPS-Ressourcenbedarf bei der Integrationsvalidierung gering zu halten. Für stärkere Antworten, zuverlässigeres Türkisch und besseres Agent-Verhalten wählen Sie ein größeres Qwen3-Modell oder ein anderes tool-fähiges Modell passend zu Ihrem RAM-/GPU-Budget.

ollama pull qwen3:1.7b

ollama list

Wird AI Agent allein per Execute-step ausgeführt, kann „No prompt specified“ erscheinen, da der Node kein chatInput von Chat Trigger erhält. Für den normalen Chat-Ablauf verwendeten wir Source for Prompt = Define below und setzten das Prompt-Feld im Expression-Modus auf {{ $json.chatInput }}.

Das eigentliche Problem bei der automatischen Ausführung zeigte sich im Workflow-JSON: Der Node „When chat message received“ hatte ein leeres main-Verbindungsarray. Auch wenn die Oberfläche verbunden aussah, endete die Ausführung am Trigger, da im JSON kein AI-Agent-Ziel vorhanden war. Nach Ergänzen von AI Agent in der main-Verbindung lief die Kette automatisch.

{{ $json.chatInput }}

"When chat message received": {
  "main": [[{
    "node": "AI Agent",
    "type": "main",
    "index": 0
  }]]
}

Nach Korrektur des Verbindungs-JSONs bewegte sich eine Chat-Nachricht automatisch von Chat Trigger zu AI Agent und weiter zu Ollama Chat Model. Das Execution-Log zeigte, dass alle drei Nodes liefen und der Workflow erfolgreich abgeschlossen wurde.

Im finalen Screenshot schloss qwen3:1.7b die Ausführung ab, lieferte für die Testnachricht jedoch eine leere Ausgabe. Das bedeutet nicht, dass die Infrastrukturverbindung fehlgeschlagen ist: Trigger, Agent und Ollama-Kette wurden ausgeführt. Es bedeutet, dass das kleine 1.7B-Modell möglicherweise nicht die Antwortqualität oder das n8n-Agent-Verhalten liefert, das Sie in der Produktion erwarten. Testen Sie denselben Workflow bei Bedarf erneut mit einem stärkeren Modell.

An diesem Punkt steht auf dem Windows VPS eine funktionierende lokale n8n + Ollama AI-Agent-Grundlage mit geprüftem Kern-Agent-Pfad und lokaler Modellverbindung.

Diese Anleitung startet n8n aus PowerShell, um die Integration zu validieren. Wird dieses PowerShell-Fenster geschlossen, stoppt auch n8n. Für den 24/7-Produktivbetrieb sollten Prozessüberwachung, Neustartverhalten, Backups und der aktuelle offizielle n8n-Self-Hosting-Ansatz separat geplant werden.

Geben Sie den n8n-Editor oder Ollama-Port 11434 nicht ohne geeignete Kontrollen direkt im Internet frei. Ist Fernzugriff erforderlich, verwenden Sie TLS, einen Reverse Proxy, starke Authentifizierung, Firewall-/IP-Beschränkungen und eine regelmäßige Update-Richtlinie. Behandeln Sie n8n-Credentials, das Owner-Konto und Workflow-Exporte als sensible Daten.