Produktionsorientierte Einrichtung von n8n, Ollama und Qdrant auf Ubuntu 24.04 LTS mit persistentem Storage, Container-Netzwerk, Embedding-Kompatibilität, GPU-Planung und Recovery.
Vor Befehlen in der Produktion Versionen, Backups, Firewall-Regeln und Rollback-Plan in der eigenen Infrastruktur prüfen.
n8n orchestriert Workflows, Ollama bedient Chat- und Embedding-Modelle, Qdrant übernimmt Vector Retrieval. Häufige Fehler entstehen durch Netzwerkadressen, Dimensionskonflikte, Ressourcenengpässe oder ungeschützte Dienste.
Ein zuverlässiger RAG-Stack besteht nicht nur aus laufenden Containern. Embeddings müssen kompatibel sein, Qdrant-Dimensionen zum Modell passen, n8n muss Dienste über das Docker-Netz erreichen und wichtige Daten benötigen persistente Volumes.
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
Dokumente werden bereinigt und in Chunks geteilt, als Embeddings in Qdrant gespeichert und bei einer Anfrage über denselben Embedding-Raum wiedergefunden. n8n übergibt den gefundenen Kontext an das Ollama-Chatmodell.
Retrieval und Generierung getrennt bewerten: Eine flüssige Antwort beweist kein korrektes Retrieval. Relevanz, Antwortqualität und Latenz separat messen.
Ollama hängt von Modellgröße, Kontext und GPU-Offload ab. Qdrant wird durch Vektoranzahl, Dimensionen, Payload-Indizes, Quantisierung, Replikation und Storage bestimmt.
Größerer Kontext erhöht den Speicherbedarf. Reale Promptgrößen und Parallelität testen; schnelles SSD/NVMe hilft bei Ingest, Snapshots und großen Collections.
Im n8n-Container zeigt localhost auf n8n selbst. Dienste im Compose-Netz werden über Servicenamen wie http://ollama:11434 und http://qdrant:6333 angesprochen.
Qdrant und Ollama möglichst privat halten. Externe Endpunkte mit Reverse Proxy, TLS, Authentifizierung und Netzrestriktionen absichern.
Die Qdrant-Vektordimension muss zur Embedding-Ausgabe passen. Bei Modellwechsel sind neue Collection und Re-Embedding oft sauberer als gemischte Vektoren.
Chunking mit echten Fragen prüfen; semantische Grenzen und Metadaten erhalten, statt nur eine fixe Zeichenzahl zu verwenden.
Ein Workflow übernimmt Laden, Bereinigen, Chunking, Embedding und Qdrant-Upsert; ein zweiter Workflow Frage-Embedding, Retrieval, Prompt-Aufbau und Ollama.
Dokumente nicht bei jeder Frage neu embedden. n8n-Ausführungen, Qdrant-Queries und Modell-Latenz gemeinsam korrelieren.
Self-hosted Qdrant benötigt explizite API Keys, eingeschränktes Binding und TLS. Standardkonfiguration nicht ungeprüft ins Internet stellen.
n8n Encryption Key zusammen mit DB-Backups schützen und Ollama nur für notwendige Services erreichbar machen.
Container-Images sind keine Datenbackups. Qdrant Storage/Snapshots, n8n-Datenbank und Encryption Key gemeinsam sichern.
Image-Versionen dokumentieren, Updates in Staging testen und Embedding-Modellwechsel als Datenmigration behandeln.
TTFT, End-to-End-Latenz, Qdrant-p95, Embedding-Zeit, Retrieval-Relevanz, Kontextgröße, GPU/CPU und Fehlerquote gemeinsam messen.
Beim Vergleich dieselben Fragen, denselben Collection-Snapshot und dieselben Modelleinstellungen verwenden; `ollama ps` für Offload und Kontext prüfen.
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
| Komponente | Aufgabe | Netz / Port | Produktionshinweis |
|---|---|---|---|
| n8n | Workflow-Orchestrierung | 5678 hinter Proxy/privat | Encryption Key und DB schützen |
| Ollama | Chat- und Embedding-Inferenz | 11434 privat | Modell, VRAM, Kontext prüfen |
| Qdrant | Vector Retrieval | 6333/6334 privat | API Key, Binding, TLS, Snapshots |
| PostgreSQL | Persistente n8n-Daten | 5432 intern | Backups und Storage Monitoring |
| Reverse Proxy | HTTPS-Einstieg | 80/443 öffentlich | TLS, Rate Limits, Timeouts |
Das Ergebnis ist eine Schätzung; Produktionsentscheidungen benötigen reale Messungen und Tests.
Ein zuverlässiger RAG-Stack besteht nicht nur aus laufenden Containern. Embeddings müssen kompatibel sein, Qdrant-Dimensionen zum Modell passen, n8n muss Dienste über das Docker-Netz erreichen und wichtige Daten benötigen persistente Volumes.
| Symptom / Problem | Mögliche Ebene | Erste Prüfung |
|---|---|---|
| n8n erreicht Ollama nicht | Container-Netzwerk / localhost | http://ollama:11434 im Compose-Netz testen. |
| Qdrant meldet Dimension Error | Embedding/Collection ungleich | Embedding-Dimension mit Collection vergleichen. |
| Falsche Quellen im RAG | Chunking/Embedding/Retrieval | Top-k mit echten Fragen manuell prüfen. |
| Ollama nutzt CPU trotz GPU | Runtime/Offload | `nvidia-smi` und `ollama ps` prüfen. |
| Daten nach Qdrant-Neustart weg | Volume fehlt/falsch | Storage-Mount und Snapshots prüfen. |
| n8n Credentials nach Migration defekt | Encryption Key stimmt nicht | Passenden Key und DB-Backup gemeinsam wiederherstellen. |
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
Updates, Docker Compose und ggf. GPU Runtime validieren.
Service-Namen und interne Erreichbarkeit prüfen.
Modell, Dimension, Distance und Chunking dokumentieren.
Quelle → Chunk → Embedding → Qdrant.
Frage → Embedding → Qdrant → Kontext → Ollama.
Ports reduzieren, TLS/API Keys und Restore-Test.
p95, Retrieval-Qualität und Ressourcen unter Last messen.
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
docker --version && docker compose versiongit clone https://github.com/n8n-io/self-hosted-ai-starter-kit.git
cd self-hosted-ai-starter-kit
cp .env.example .envdocker compose --profile cpu pull
docker compose --profile cpu up -dnvidia-smi
docker compose --profile gpu-nvidia pull
docker compose --profile gpu-nvidia up -ddocker compose ps
curl -fsS http://127.0.0.1:6333/
curl -fsS http://127.0.0.1:11434/api/tagsollama list
ollama psdocker compose logs --tail=150 n8n qdrant
docker compose logs --tail=150 ollama-cpu ollama-gpu 2>/dev/null || trueModellgröße, Datenmenge, Parallelität, GPU-Wunsch und Ziel-Latenz reichen für eine technische Vorplanung von CPU/RAM/VRAM/NVMe und Service-Trennung.
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
Architektur, Sizing, Docker-Netzwerk, Embeddings, Sicherheit, Performance, Backup und Fehlerdiagnose bis zur Produktion.
Ein zuverlässiger RAG-Stack besteht nicht nur aus laufenden Containern. Embeddings müssen kompatibel sein, Qdrant-Dimensionen zum Modell passen, n8n muss Dienste über das Docker-Netz erreichen und wichtige Daten benötigen persistente Volumes.
Ja, sofern CPU, RAM, VRAM und Storage unter realer Last ausreichend sind.
Meist nicht. Qdrant im privaten Netz halten und bei externem Zugriff TLS, Auth und Netzrestriktionen nutzen.
Meist nicht sinnvoll; anderer Embedding-Raum oder Dimension verlangt eine neue Collection.
Für n8n und Qdrant nein; für Ollama hängt es von Modell, Latenz und Parallelität ab.
Es ist ein starker PoC/Lern-Startpunkt; HA, Security, Backup und Monitoring müssen für Produktion ergänzt werden.
Qdrant fordert für persistenten Live-Storage block-level POSIX-kompatiblen Storage statt NFS/Object Storage.
Mehr Kontext erhöht den Runtime-Speicherbedarf. Reale Zuweisung mit `ollama ps` prüfen.
Mit echten Fragen Retrieval-Evidenz, Antwortkorrektheit und Latenz gemeinsam bewerten.
Modellgröße, Datenmenge, Parallelität, GPU-Wunsch und Ziel-Latenz reichen für eine technische Vorplanung von CPU/RAM/VRAM/NVMe und Service-Trennung.