NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes isometrisches Browserfenster OLLAMA mit Docker Brücke und Rakete

Was ist die lokale Ollama Anbindung in Symfony?

Die lokale Ollama Anbindung in Symfony verbindet eine Symfony Anwendung mit einem lokal laufenden Ollama Daemon, sodass KI Recherche direkt auf eigener Hardware läuft. Statt Anfragen an eine fremde Cloud zu schicken, spricht deine Anwendung über die Platform Component von Symfony AI ein Modell an, das auf deinem Rechner oder Server liegt, ohne API Kosten und ohne Datenabfluss.

Technisch übernimmt das Paket symfony/ai-ollama-platform die komplette Verkabelung. Du musst keinen PHP Code anfassen, sondern nur drei Konfigurationen in Einklang bringen: den richtigen Endpunkt, ein installiertes Modell und eine funktionierende Netzwerkbrücke zwischen Docker Container und Host. Genau daran scheitern die meisten Setups im ersten Anlauf.

Dieses Tutorial zeigt Schritt für Schritt, wie du ein lokales Modell wie gpt-oss:20b in einem DDEV basierten Symfony Projekt erreichbar machst und einen KI Befehl zum Laufen bringst. Das Beispiel stammt aus einem echten Sulu CMS Projekt und liefert strukturierte JSON Ausgaben zurück. In der NCA Produktion setzen wir denselben Ansatz mit Ollama und Modellen wie Qwen und Llama ein.

Inhalt

Lokale KI in Symfony mit NCA: Experten für DSGVO konforme Setups

Never Code Alone betreibt Ollama mit Modellen wie Qwen3 Coder und Llama auf eigener Hardware und bindet sie in Symfony an. Unsere Regel: Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk. Genau diese Datenverarbeitung soll in vielen Unternehmen an ein altes PHP System andocken, das dafür nie gebaut wurde.
Mit dem NCA Symfony AI Team Mate entsteht deshalb ein Symfony Projekt in Docker parallel zu eurem Legacy. Es liest eure echten Daten und verarbeitet sie mit lokalen Modellen, ohne dass etwas das Netzwerk verlässt. Für den Betrieb im Unternehmen gibt es Self Hosted KI für Unternehmen. Abgesichert wird alles über eine CI CD Pipeline mit Docker und Staging und die NCA PHP AI Coding Guidelines, der alte Code folgt über PHP Refactoring.
Lokale KI Recherche ins eigene Symfony Projekt bringen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum lokale Modelle in Symfony oft ins Leere laufen

Das Szenario ist typisch: Der KI Befehl ist verkabelt, symfony/ai-ollama-platform ist installiert, der Service existiert. Trotzdem läuft jeder Aufruf ins Leere, weil die Konfiguration auf eine fremde Cloud zeigt und der Container den lokalen Ollama gar nicht sieht. Drei Stolpersteine sind fast immer die Ursache:

  • Falscher Endpunkt: OLLAMA_HOST zeigt auf eine Remote Cloud statt auf den lokalen Daemon.
  • Fehlendes Modell: OLLAMA_MODEL benennt ein Modell, das lokal nicht installiert ist.
  • Netzwerk Isolation: Symfony läuft im Docker Container, Ollama lauscht aber nur auf 127.0.0.1, der Container sieht den Host Dienst nicht.

Die gute Nachricht: Alle drei Punkte lösen wir mit Bordmitteln, ohne eine einzige Zeile PHP anzufassen. Die komplette Ollama Anbindung ist bereits über die Model Inference Schnittstelle von Symfony AI registriert. Wir bringen nur Endpunkt, Modell und Netzwerk in Einklang.

Voraussetzungen für das lokale Setup

Bevor es losgeht, brauchst du drei Dinge. Der Rest sind reine Konfigurationsschritte, die in unter zehn Minuten erledigt sind.

  • Ein lokaler Ollama Daemon, gestartet über ollama serve.
  • Ein Symfony Projekt mit symfony/ai-ollama-platform und dem Platform Service.
  • Optional DDEV als lokales Setup auf Basis von Docker.

Schritt 1: Modell installieren und prüfen

Zuerst holst du das Modell, das die Implementierung standardmäßig erwartet. In unserem Beispiel ist das gpt-oss:20b, das quelloffene Modell von OpenAI. In der NCA Produktion nutzen wir hier je nach Aufgabe auch Qwen oder Llama.

Code: 
          
ollama pull gpt-oss:20b

Danach prüfst du, was lokal verfügbar ist. Der Aufruf gegen die Ollama API listet alle installierten Modelle auf.

Code: 
          
curl -s http://localhost:11434/api/tags | grep -o '"name":"[^"]*"'

In der Ausgabe sollte gpt-oss:20b auftauchen, neben eventuell bereits vorhandenen Modellen wie llama3.2 oder qwen2.5. Damit ist das Modell einsatzbereit.

Schritt 2: Ollama für Docker erreichbar machen

Standardmäßig bindet Ollama nur an die Loopback Adresse. Dein Symfony Prozess läuft aber im Container und erreicht den Host über host.docker.internal. Damit das klappt, muss Ollama auf allen Netzwerkschnittstellen lauschen. Läuft Ollama als systemd Service, erledigt das ein kleiner Drop in.

Code: 
          
sudo mkdir -p /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_HOST=0.0.0.0:11434"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload && sudo systemctl restart ollama

Ein Sicherheitshinweis: 0.0.0.0 macht Ollama im gesamten Netzwerk erreichbar. Tu das nur in vertrauenswürdigen Umgebungen, also nicht im öffentlichen WLAN. Wer den Dienst nach außen absichern will, stellt einen Reverse Proxy wie Caddy davor. Anschließend kontrollierst du das Ergebnis.

Code: 
          
ss -ltn | grep 11434

Korrekt ist nun ein Sternchen statt 127.0.0.1, also LISTEN auf *:11434. Ollama nimmt jetzt Verbindungen vom Container an.

Schritt 3: Die Umgebungsvariablen korrigieren

Jetzt passt du die drei relevanten Werte in der .env.local an. Sie sind meist der eigentliche Grund, warum der Aufruf vorher ins Leere lief: Der Host zeigte auf eine Cloud, das Modell war lokal nicht vorhanden und ein API Key war gesetzt, obwohl lokal keiner nötig ist. Die folgende Tabelle zeigt den Wechsel im Überblick.

Variable Vorher Nachher
OLLAMA_HOST https://ollama.com http://host.docker.internal:11434
OLLAMA_MODEL qwen3-coder-next gpt-oss:20b
OLLAMA_API_KEY 6367 … leer, lokal nicht nötig

Die fertige .env.local

Zusammengefasst sieht der relevante Ausschnitt so aus. Das ist die einzige Datei, die du im Projekt anpasst.

Code: 
          
OLLAMA_HOST=http://host.docker.internal:11434
OLLAMA_API_KEY=
OLLAMA_MODEL=gpt-oss:20b

Schritt 4: Erreichbarkeit aus dem Container testen

Bevor du Symfony bemühst, verifizierst du die Netzwerkverbindung direkt aus dem Container. So trennst du sauber zwischen Netzwerk und Anwendung.

Code: 
          
ddev exec curl -s -w "\nHTTP:%{http_code}\n" http://host.docker.internal:11434/api/tags

Steht am Ende HTTP:200 und du siehst die Modellliste, ist die Brücke geschlagen. Der Container erreicht den Ollama Daemon auf dem Host.

Schritt 5: Die Recherche starten

Jetzt der eigentliche Aufruf. Der Demo Befehl recherchiert die Hauptstadt eines Landes und gibt das Ergebnis als strukturiertes JSON zurück. Wie diese typsichere Ausgabe unter der Haube entsteht, zeigt der Eintrag zu Structured Output.

Code: 
          
ddev exec bin/console ai:demo:property-research Deutschland

Die Ausgabe lautet: [OK] Deutschland — capital: Berlin. Und weil ein Treffer kein Zufall sein soll, testest du gleich mehrere Länder in einer Schleife.

Code: 
          
for c in Japan Brasilien Australien; do
  ddev exec bin/console ai:demo:property-research "$c"
done

Das Modell liefert zuverlässig Tokyo, Brasília und Canberra zurück. Damit läuft die KI Recherche komplett lokal, ohne Cloud, ohne API Key und ohne Datenabfluss.

Was du aus diesem Setup mitnimmst

Drei Erkenntnisse, die über dieses Beispiel hinaus gelten:

  • Die Symfony AI Integration ist bereits fertig. Wer symfony/ai-ollama-platform installiert hat, braucht für lokale Modelle keinen neuen Code, nur korrekte Konfiguration.
  • Das Container Netzwerk ist der häufigste Stolperstein. Läuft ein Dienst auf dem Host, der Client aber im Container, ist host.docker.internal zusammen mit dem 0.0.0.0 Binding der zuverlässigste Weg.
  • Strukturierte Ausgaben funktionieren lokal. Die Option format json im invoke Aufruf wird von Ollama nativ unterstützt, ideal für Entitäten, DTOs und weitere Verarbeitung.

Wer diesen Mechanismus verstanden hat, steht vor der Tür zu mächtigeren Workflows: ein eigener Befehl für die FAQ Recherche oder eine Pipeline, die Content Blöcke direkt im Sulu CMS generiert. Die Infrastruktur steht, ganz ohne API Schlüssel und ohne Cloud Kosten.

At first AI is a ton of buzzwords and hype

Christopher Hertel, Initiator von Symfony AI – Speaker Deck, PHP UK 2026

NCA Erfahrung mit lokaler KI in Symfony

In Beratungsprojekten sehen wir regelmäßig dasselbe Muster: Ein Team will lokale Modelle nutzen, scheitert aber an der Grenze zwischen Container und Host. Der PHP Code ist längst korrekt, es hakt an drei Umgebungsvariablen und einem fehlenden Binding. Wer diese Kette einmal verstanden hat, überträgt sie auf jeden anderen Dienst, der im Host läuft und aus dem Container erreichbar sein muss.

Unser Ansatz: lokale Inferenz einbauen, dann mit deterministischen Werkzeugen absichern. PHPStan und Psalm prüfen die Typen der Ergebnisobjekte, PHPUnit und der Symfony KernelTestCase halten das Verhalten fest, Modellantworten mocken wir über den HttpClient MockResponse. Eingebettet in eine CI/CD Pipeline wird aus einem lokalen KI Aufruf ein verlässlicher Baustein. Wir begleiten das im Vibe Coding Consulting, im 1 zu 1 Mentoring und beim Vibe Coding Projekt retten. Die Abrechnung erfolgt transparent und minutengenau.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Ollama in Symfony

Die wichtigsten Fragen rund um die lokale Ollama Anbindung in Symfony, das Docker Netzwerk und den DSGVO konformen Betrieb im Überblick.

Was ist die lokale Ollama Anbindung in Symfony 2026?

Die lokale Ollama Anbindung verbindet eine Symfony Anwendung über das Paket symfony/ai-ollama-platform mit einem Ollama Daemon auf eigener Hardware. KI Recherche läuft dann ohne Cloud, ohne API Kosten und ohne Datenabfluss. Die Anbindung ist bereits registriert, du bringst nur Endpunkt, Modell und Netzwerk in Einklang.

Warum sieht mein Docker Container den lokalen Ollama 2026 nicht?

Weil Ollama standardmäßig nur auf 127.0.0.1 lauscht. Ein Container erreicht den Host über host.docker.internal und braucht deshalb einen Dienst, der auf allen Schnittstellen lauscht. Setzt du OLLAMA_HOST auf 0.0.0.0:11434 und startest den Daemon neu, nimmt Ollama die Verbindungen aus dem Container an.

Brauche ich für lokale Ollama Modelle in Symfony 2026 einen API Key?

Nein. Für lokale Modelle über Ollama entfällt der API Key vollständig. Die Anfrage läuft gegen deinen eigenen Endpunkt, etwa http://host.docker.internal:11434. Die Variable OLLAMA_API_KEY bleibt leer. Nur bei Cloud Anbietern wie OpenAI oder Mistral ist ein Schlüssel als Umgebungsvariable nötig.

Welches Ollama Modell eignet sich für Symfony 2026?

Das hängt von der Aufgabe ab. Im Tutorial nutzen wir gpt-oss:20b, das quelloffene Modell von OpenAI. In der NCA Produktion setzen wir je nach Anforderung auf Qwen oder Llama. Wichtig ist, dass das Modell die benötigte Fähigkeit mitbringt, etwa strukturierte JSON Ausgaben, und lokal installiert ist.

Ist die lokale Ollama Anbindung in Symfony 2026 DSGVO konform?

Ja, weil keine Daten den eigenen Server verlassen. Die Inferenz läuft vollständig auf eigener Hardware, ohne Aufruf an externe Anbieter. Das macht den Ansatz ideal für sensible Daten und Berufsgeheimnisträger. Für den sicheren Betrieb nach außen empfiehlt sich zusätzlich ein Reverse Proxy und Zugangsschutz.

Was bedeutet host.docker.internal?

host.docker.internal ist ein spezieller DNS Name, über den ein Docker Container den Host Rechner erreicht, auf dem Docker läuft. Statt localhost, das im Container auf den Container selbst zeigt, adressierst du damit Dienste, die direkt auf dem Host laufen, wie einen lokalen Ollama Daemon.

Wie mache ich Ollama für DDEV erreichbar?

Du bringst Ollama dazu, auf allen Schnittstellen zu lauschen, indem du OLLAMA_HOST auf 0.0.0.0:11434 setzt, bei systemd über einen Drop in. Danach zeigt OLLAMA_HOST in der Symfony Konfiguration auf http://host.docker.internal:11434. Aus dem Container testest du die Verbindung mit ddev exec curl gegen den Endpunkt.

Muss ich für lokale Modelle PHP Code ändern?

Nein. Wenn symfony/ai-ollama-platform installiert und der Platform Service registriert ist, brauchst du keinen neuen Code. Die komplette Anbindung läuft über die Konfiguration. Du passt nur die .env.local an: Endpunkt, Modellname und den leeren API Key. Der restliche Ablauf bleibt identisch zur Cloud Variante.

Wie teste ich die Verbindung aus dem Container?

Mit einem curl Aufruf direkt aus dem Container, etwa ddev exec curl gegen http://host.docker.internal:11434/api/tags. Kommt HTTP 200 und die Modellliste zurück, ist die Netzwerkbrücke geschlagen. Dieser Zwischenschritt trennt sauber zwischen Netzwerkproblemen und Fehlern in der Anwendung selbst.

Funktionieren strukturierte JSON Ausgaben mit lokalen Modellen?

Ja. Die Option format json im invoke Aufruf wird von Ollama nativ unterstützt, sofern das gewählte Modell strukturierte Ausgaben beherrscht. So fließt das Ergebnis typsicher in Entitäten, DTOs oder Doctrine Objekte. Details zeigt der Eintrag zu Structured Output in Symfony AI.

Ist das 0.0.0.0 Binding ein Sicherheitsrisiko?

In einem vertrauenswürdigen Netzwerk ist es unkritisch, weil es Ollama nur lokal erreichbar macht. In öffentlichen Netzen solltest du es vermeiden oder absichern. Ein Reverse Proxy wie Caddy mit TLS und Zugangsschutz stellt den Dienst kontrolliert bereit, statt ihn offen ins Netz zu hängen.

Wie hilft NCA bei lokaler KI in Symfony?

Never Code Alone bindet lokale Modelle über Ollama in bestehende Symfony und Sulu CMS Projekte ein, sichert die KI Features mit PHPStan, Psalm und PHPUnit ab und bettet sie in eine CI/CD Pipeline ein. Auf Wunsch vollständig DSGVO konform auf eigenen Servern. Die Abrechnung erfolgt transparent und minutengenau.