n8n + Ollama Qwen3 AI Agent auf Ubuntu 24.04: Vollständiger bebilderter Leitfaden mit Memory, Calculator und HTTP Tools

Dieser Leitfaden dokumentiert die reale n8n-Automatisierungsschicht auf einem Ubuntu-24.04.4-LTS-VPS, das über Ollama laufende Modell qwen3:4b und den vollständigen n8n-AI-Agent-Workflow. n8n, Ollama und Open WebUI laufen in Docker im gemeinsamen Bridge-Netzwerk eka-ai.

Benutzer senden Nachrichten über Chat Trigger. Der AI Agent ruft qwen3:4b über das Ollama Chat Model auf, behält Kontext über Simple Memory und kann Calculator oder HTTP Request Tool verwenden. Die Host-Ports 5678 und 11434 sind nur an Loopback gebunden; Nginx veröffentlicht den Dienst über HTTPS.

Internet :443
  ↓
Nginx + Let's Encrypt
  ↓
127.0.0.1:5678 → n8n
  ↓ eka-ai
ollama:11434 → qwen3:4b
  ↓
AI Agent + Memory + Calculator + HTTP Tool

Der reale Testserver lief mit Ubuntu 24.04.4 LTS, Kernel 6.8.0-137-generic, rund 31 GiB RAM und einem 99-GB-Root-Dateisystem. Docker Engine 29.7.2 und Docker Compose v5.4.0 waren aktiv.

Ollama lauschte bereits auf 127.0.0.1:11434 und qwen3:4b war in /api/tags sichtbar. Diese Vorprüfung erleichtert die Trennung späterer Credential- und Netzwerkfehler.

cat /etc/os-release | grep -E 'PRETTY_NAME|VERSION_ID|VERSION_CODENAME'
uname -r
free -h
df -h /

docker --version
docker compose version
systemctl is-active docker

docker ps --filter name='^/ollama$'
curl -sS http://127.0.0.1:11434/api/tags

Da n8n und Ollama in getrennten Containern laufen, zeigt localhost im n8n-Container nicht auf Ollama. Beide Dienste wurden an eka-ai angeschlossen; n8n verwendet http://ollama:11434.

Vor TLS wurde geprüft, dass n8n.ekasunucu.com auf den VPS auflöst. Prüfungen über 1.1.1.1 und 8.8.8.8 helfen, DNS-Propagation von Nginx- oder Certbot-Problemen zu unterscheiden.

docker network inspect eka-ai --format 'Netz={{.Name}} Driver={{.Driver}} Scope={{.Scope}}'

dig +short A n8n.ekasunucu.com @1.1.1.1
dig +short A n8n.ekasunucu.com @8.8.8.8

n8n-Daten wurden in einem Named Volume statt im vergänglichen Container-Dateisystem gespeichert. Dadurch bleiben Benutzer, Workflows und Credentials bei einer Neuerstellung des Containers erhalten.

N8N_ENCRYPTION_KEY muss stabil bleiben, da damit gespeicherte Credentials geschützt werden. Hinter Nginx sollten öffentliche Editor-URL, Host, Protokoll, Proxy-Hops und Zeitzone explizit gesetzt werden.

docker volume inspect n8n_data >/dev/null 2>&1 || docker volume create n8n_data

openssl rand -hex 32

N8N_ENCRYPTION_KEY=LANGER_ZUFAELLIGER_SCHLUESSEL
N8N_HOST=n8n.ekasunucu.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.ekasunucu.com
WEBHOOK_URL=https://n8n.ekasunucu.com/
N8N_PROXY_HOPS=1
N8N_SECURE_COOKIE=true
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
GENERIC_TIMEZONE=Europe/Istanbul
TZ=Europe/Istanbul
NODE_ENV=production

Wir luden das offizielle n8n-Docker-Image und verbanden den Container mit eka-ai. Port 5678 wurde an 127.0.0.1 statt 0.0.0.0 gebunden, damit der Editor nicht direkt über Docker öffentlich ist.

Das Volume n8n_data wurde unter /home/node/.n8n eingebunden und eine Restart-Policy für Neustarts aktiviert.

docker pull docker.n8n.io/n8nio/n8n:latest

docker run -d --name n8n --restart=always --network eka-ai --env-file /root/n8n.env -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n:latest

Der lokale Endpoint /healthz lieferte HTTP 200 mit {"status":"ok"}. Die reale Testinstanz meldete n8n 2.33.7.

Datenbankmigrationen beim ersten Start sind normal. Im Log fehlte Python 3 für den internen Python-Task-Runner; der JavaScript-basierte AI-Workflow funktionierte dennoch.

curl -sS http://127.0.0.1:5678/healthz

docker exec n8n n8n --version

docker logs --tail 120 n8n

Ein Ollama-Test auf dem Host reicht nicht. Wir riefen aus dem n8n-Container http://ollama:11434/api/tags auf. HTTP 200 wurde geliefert und qwen3:4b war vorhanden.

Danach wurde ein echter /api/chat-Aufruf aus n8n gesendet. Die Antwort N8N-OLLAMA-BAGLANTISI-BASARILI bestätigte Docker-DNS, Ollama-API und Modellinferenz.

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

docker exec n8n node -e "fetch('http://ollama:11434/api/chat',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({model:'qwen3:4b',messages:[{role:'user',content:'Schreibe nur N8N-OLLAMA-BAGLANTISI-BASARILI'}],stream:false})}).then(r=>r.json()).then(d=>console.log(d.message?.content))"

Da n8n nur auf Loopback lauscht, übernimmt Nginx die öffentliche Webschicht. Host- und X-Forwarded-Header sowie WebSocket-Upgrades wurden weitergereicht; Proxy-Buffering wurde deaktiviert und Timeouts erhöht.

Der erste HTTP-Domaintest ergab 404. Nach Vhost- und Certbot-Konfiguration wurde das Let’s-Encrypt-Zertifikat erfolgreich installiert; Origin-HTTPS und öffentliche Domain lieferten HTTP 200.

cat > /etc/nginx/sites-available/n8n.ekasunucu.com <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name n8n.ekasunucu.com;
    client_max_body_size 100m;
    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}
EOF

nginx -t && systemctl reload nginx

/snap/bin/certbot --nginx -d n8n.ekasunucu.com --email [email protected] --agree-tos --no-eff-email --non-interactive --redirect

Im finalen Portcheck lauschte n8n auf 127.0.0.1:5678, Ollama auf 127.0.0.1:11434 und Open WebUI auf 127.0.0.1:3000. Öffentlich waren nur Nginx 80 und 443.

Portainer, Ollama, Open WebUI und n8n liefen gleichzeitig. Der Certbot-Renewal-Dry-Run war erfolgreich und systemctl --failed meldete keine fehlgeschlagenen Units.

ss -lntp | grep -E ':5678[[:space:]]|:11434[[:space:]]|:3000[[:space:]]|:443[[:space:]]|:80[[:space:]]'

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

/snap/bin/certbot renew --dry-run
systemctl --failed --no-pager

Beim Öffnen der HTTPS-Domain erschien das Formular für das Owner-Konto. Wir erstellten den Instanzbesitzer mit E-Mail, Vorname, Nachname und starkem Passwort.

Anschließend zeigte n8n optionale Personalisierungsfragen. Sie sind für die Workflow-Engine nicht erforderlich.

Die Instanz kann ohne diesen optionalen Schritt als Community Edition laufen. Im Test forderten wir unter Usage and plan den kostenlosen Registrierungs-Key an, erhielten ihn per E-Mail und aktivierten ihn; die Oberfläche zeigte danach Registered.

Dies öffnete die damals von n8n angebotenen ausgewählten kostenlosen Registrierungsfunktionen. Lizenzbedingungen und Funktionsumfang können sich ändern; maßgeblich sind aktuelle Oberfläche und offizielle Lizenzinformationen.

Auf der Workflows-Seite erstellten wir einen neuen Workflow. Chat Trigger ist der Benutzereingang und AI Agent der Root-Node für Modell- und Tool-Aufrufe.

Der Basisgraph bestand aus Chat Trigger, AI Agent, Ollama Chat Model und Simple Memory. Später kamen Calculator und HTTP Request Tool am Tool-Eingang hinzu.

Im Export verbindet sich Chat Trigger mit dem Main-Eingang des AI Agent, Ollama Qwen3 4B über ai_languageModel und Simple Memory über ai_memory. Der System-Prompt erzwingt türkische Antworten und den echten Modellnamen qwen3:4b.

Workflow-Exports sollten nicht als sichere Verteilungsmethode für Credentials verstanden werden. Erstellen Sie das Ollama-Credential auf der Zielinstanz.

Chat Trigger → AI Agent
Ollama Qwen3 4B ──ai_languageModel──▶ AI Agent
Simple Memory ──ai_memory────────────▶ AI Agent

Beim ersten importierten Lauf war Chat Trigger erfolgreich, AI Agent und Ollama-Subnode schlugen jedoch fehl. Ein nutzbares Ollama-Credential war nicht ausgewählt.

Wir erstellten ein Ollama-Credential mit Base URL http://ollama:11434. localhost:11434 wäre zwischen getrennten Containern falsch, da localhost zurück auf n8n zeigt.

Ollama Credential Base URL:
http://ollama:11434

Nach dem Speichern des Credentials liefen Chat Trigger, AI Agent, Ollama Qwen3 4B und Simple Memory erfolgreich; n8n zeigte Workflow executed successfully.

Die erste Antwort erfand einen Modellnamen. Nach einer präziseren System-Anweisung nannte der Agent korrekt Ollama als Runtime und qwen3:4b als Modell.

Ein LLM verfügt nicht automatisch über zuverlässige Introspektion der Laufzeitkonfiguration. Im ersten Test erfand es einen Namen wie SenEKA-Local-1.0. Das war ein Prompt-Grounding-Problem, kein Ollama-Verbindungsfehler.

Wir legten explizit fest: Runtime Ollama, Modell qwen3:4b und keine erfundenen Modellnamen. Technische Identitätsangaben sollten an die reale Workflow-Konfiguration gebunden werden.

Du bist ein vollständig lokaler KI-Agent auf EKA Sunucu.
Deine Runtime ist Ollama und dein Sprachmodell ist qwen3:4b.
Wenn nach dem Modell gefragt wird, antworte qwen3:4b.
Erfinde keine andere Modellidentität.

Calculator wurde mit dem Tool-Eingang des AI Agent verbunden und der System-Prompt fordert seine Nutzung für Berechnungen.

Bei “3478 × 129, benutze den Rechner” wurde Calculator tatsächlich aufgerufen. Das Tool lief in etwa 1 ms und der Agent lieferte korrekt 448662.

Test: 3478 × 129, benutze den Rechner.
Erwartet: 448662

Unser erster HTTP-Tool-Versuch verwendete den alten Node-Typ @n8n/n8n-nodes-langchain.toolHttpRequest. Die Ausführung scheiterte mit “has a supplyData method but no execute method”.

Das war kein Netzwerk- oder JSONPlaceholder-Fehler. Der Node-Typ war mit der laufenden n8n-Version inkompatibel und wurde durch die aktuelle HTTP-Request-Tool-Implementierung ersetzt.

Fehler: The node '@n8n/n8n-nodes-langchain.toolHttpRequest' has a 'supplyData' method but no 'execute' method.

Der alte Node wurde durch das aktuelle HTTP Request Tool am AI Agent ersetzt. Für einen reproduzierbaren Test wurde GET https://jsonplaceholder.typicode.com/todos/1 verwendet.

Beim Auftrag, OrnekAPIVeriGetir zu verwenden und die Daten auf Türkisch zu erklären, lief das HTTP-Tool erfolgreich. Der Agent fasste userId 1, id 1, title “delectus aut autem” und completed false zusammen.

GET https://jsonplaceholder.typicode.com/todos/1

Test: OrnekAPIVeriGetir verwenden und die API-Daten auf Türkisch erklären.

Am Ende ist n8n über HTTPS erreichbar, während 5678 und 11434 privat bleiben. Netzwerk n8n→Ollama, qwen3:4b-Inferenz, Memory, Calculator und HTTP-API-Tool-Aufrufe wurden real getestet.

Für Produktion sollten Image-Versionen bewusst verwaltet, n8n_data und Ollama-Daten gesichert, N8N_ENCRYPTION_KEY geschützt und Credential-Zugriffe begrenzt werden. Als nächster Schritt eignet sich Qdrant-basiertes RAG.

docker ps
docker stats n8n ollama --no-stream
curl -sS https://n8n.ekasunucu.com/ -o /dev/null -w '%{http_code}\n'
/snap/bin/certbot renew --dry-run
systemctl --failed --no-pager