Cursor ngrok Ollama: Local-LLM-Bridge trotz Base-URL-Zwang 2026

Micha, Sovereign-AI-Consultant bei Pexon Consulting | 9 Min. Lesezeit | 30.08.2026

TL;DR

Cursor ngrok Ollama ist der Workaround, wenn Cursor localhost ablehnt: Ollama lokal starten, Port 11434 per ngrok als HTTPS exponieren, Base URL auf https://…/v1 setzen. Die Inferenz bleibt auf Ihrer GPU. Prompt-Aufbau läuft weiter über Cursor-Server. Für Team-Private-AI reicht der Tunnel nicht; dann braucht es VPN oder internes Inference.

Das Problem: Cursor spricht kein localhost mehr

Viele Guides (auch ältere) zeigen noch http://localhost:11434/v1 in Cursor. Das scheitert 2026 systematisch. Cursor-Mitarbeiter schreiben im Community-Forum klar: Override OpenAI Base URL braucht einen öffentlich erreichbaren HTTPS-Endpoint, weil Prompt-Building, Kontext und Agent über Cursor-Server laufen.

Kurz: Ihr Laptop ist für Cursors Backend unsichtbar. Ohne Tunnel kommt die Anfrage nie bei Ollama an.

Das ist kein Bug, den Sie „wegkonfigurieren“. Es ist Architektur. Wer trotzdem lokale Modelle will, braucht eine Brücke. Genau dafür ist Cursor ngrok Ollama der pragmatische Pfad für Entwickler-Setups.

Die strategische Einordnung (Privacy Mode vs. echte Offline-Inferenz, GPU-Server, Hybrid mit LiteLLM) liegt im Parent-Guide Cursor IDE mit lokalen KI-Modellen. Dieser Artikel löst nur den einen Blocker: die Base-URL-Brücke.

Warum ngrok und nicht „einfach LAN“?

Wir sehen denselben Irrtum in Workshops: „Ollama läuft im Firmennetz auf 10.x.x.x, dann reicht die interne URL.“ Reicht nicht. Cursor akzeptiert auch keine reine LAN-IP, solange der Endpoint nicht öffentlich per HTTPS erreichbar ist (bzw. über einen Tunnel, den Cursors Backend erreichen kann).

Unsere Empfehlung: ngrok nur für den Einstieg. Für produktive Teams lieber Cloudflare Tunnel oder Tailscale Funnel, und mittelfristig ein internes Inference mit Auth statt Public-Tunnel. Mehr zu Datensouveränität und Betriebsmodellen steht in der Private-AI-Datensouveränität.

Setup in 6 Schritten: Cursor ngrok Ollama

Stand August 2026: Ollama v0.33.2 (Release 27.08.2026), GitHub ~179.800 Stars (Abruf 30.08.2026). Modell-Beispiel: gemma3:12b (Google Gemma 3, 12B, gut auf einer Consumer-GPU).

1. Ollama installieren und Modell pullen

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Modell laden (exakter Tag zählt später in Cursor)
ollama pull gemma3:12b

# Kurz testen
ollama run gemma3:12b "Schreibe eine Python-Funktion fibonacci(n)"

2. CORS freigeben und Server starten

Ohne OLLAMA_ORIGINS=* scheitern Browser- und Client-Calls oft mit 403.

# macOS / Linux (eine Shell-Session)
export OLLAMA_ORIGINS="*"
# Falls Ollama schon als App läuft: zuerst beenden, sonst "bind error" auf 11434
ollama serve
# hört auf http://127.0.0.1:11434

Windows (PowerShell): $env:OLLAMA_ORIGINS="*" und danach ollama serve.

3. ngrok installieren und authentifizieren

Konto auf ngrok.com anlegen, Authtoken kopieren:

# Beispiel macOS
brew install ngrok
ngrok config add-authtoken DEIN_TOKEN

4. Tunnel auf Port 11434

ngrok http 11434 --host-header="localhost:11434"

Im Terminal erscheint eine Forwarding-URL, z. B. https://abc123.ngrok-free.app. Das ist Ihre öffentliche HTTPS-Brücke. Die Inferenz bleibt lokal; ngrok leitet nur HTTP weiter.

Free-Tier: Die URL wechselt nach jedem Neustart. Dann müssen Sie Cursor jedes Mal anpassen. Für Dauerbetrieb lohnt eine statische Domain oder Cloudflare Tunnel.

5. Cursor: Override Base URL

1. Cursor → Settings → Models
2. Custom Model hinzufügen: exakt gemma3:12b (wie in ollama list)
3. OpenAI API Key aktivieren, Dummy-Wert ollama reicht
4. Override OpenAI Base URL: https://abc123.ngrok-free.app/v1
5. Alle Cloud-Modelle abwählen, nur das lokale Modell aktiv lassen

Das /v1 ist Pflicht. Ollama spricht OpenAI-kompatibel unter diesem Pfad. Ohne Suffix scheitert der Handshake.

6. Verify-Workaround (gpt-4o-Falle)

Beim ersten Verify testet Cursor oft intern gegen gpt-4o. Das Modell existiert lokal nicht → 404 / „Invalid API Key“.

Workaround, der in der Praxis funktioniert: alle anderen Modelle deaktivieren, nur gemma3:12b anlassen, erneut Verify. Danach Modell oben rechts wählen und Chat/Agent testen.

# Optional: Tunnel-Health von außen prüfen
curl -sS "https://abc123.ngrok-free.app/v1/models" 
  -H "Authorization: Bearer ollama" 
  -H "ngrok-skip-browser-warning: 1"

Wenn hier gemma3:12b in der JSON-Liste steht, liegt der Fehler in Cursor-Settings, nicht in Ollama.

Was Cursor ngrok Ollama nicht löst

Ehrliche Grenze: Mit dem Tunnel ist Ihr Ollama-Port kurzzeitig aus dem Internet erreichbar. Das ist der Preis dafür, dass Cursors Backend den Endpoint sehen muss. Für einen Laptop-POC akzeptabel. Für Quellcode unter DORA, BaFin oder Rüstung: nein.

Zusätzlich bleibt ein Architektur-Fakt: Selbst mit lokalem Modell laufen Prompt-Aufbau und Agent-Orchestrierung über Cursor. „Kein Byte verlässt den Rechner“ ist damit nur halb wahr. Die Gewichte und die Token-Generierung sind lokal; der Kontextpfad ist es nicht vollständig.

Deshalb raten wir Teams ab, bei ngrok stehen zu bleiben. Der nächste Schritt ist internes Inference (GPU-Server, Auth, Monitoring) und ein Editor-Setup ohne Public Tunnel.

Modellwahl: Gemma 3 und Alternativen

gemma3:12b ist ein solider Allrounder auf einer GPU mit ~12-16 GB VRAM. Für reines Coding oft besser: Code-spezialisierte Tags (z. B. Qwen-Coder-Varianten), die Sie analog pullen und unter dem exakten Tag in Cursor eintragen.

Wir raten von Sub-7B-Modellen für produktives Coding ab. Die Akzeptanzrate der Vorschläge bricht ein, und Entwickler schalten die Funktion nach wenigen Tagen wieder aus.

Typische Fehler und Fixes

1. Bind error auf 11434: Ollama-App läuft schon. Quit in der Taskbar, dann ollama serve mit OLLAMA_ORIGINS=*.
2. 403 über ngrok: Host-Header falsch. Flag --host-header="localhost:11434" setzen; ggf. Traffic Policy, die Host auf 127.0.0.1:11434 umschreibt.
3. Model not found: Tag in Cursor weicht von ollama list ab (gemma3:12b ≠ gemma3).
4. Verify failt trotz korrekter URL: Cloud-Modelle noch aktiv → abwählen, nur Lokalmodell.
5. Nach ngrok-Neustart tot: Free-URL geändert → Base URL in Cursor aktualisieren.

Häufig gestellte Fragen

Was kostet Cursor ngrok Ollama für einen einzelnen Entwickler?

Cursor-Abo (Pro/Teams je nach Plan) plus optional ngrok Paid für stabile Domain. Ollama und gemma3:12b sind kostenlos. Die echte Kostenstelle ist die GPU: Consumer-Karten ab ca. 800-1.600 EUR, sonst Cloud-GPU-Miete.

Cursor ngrok Ollama vs. reines Cloud-Cursor: wann lohnt der Tunnel?

Wenn Token-Kosten oder Datenkontrolle den Ausschlag geben und Sie Chat/Agent lokal fahren wollen. Tab-Autocomplete bleibt ohnehin cloudbasiert. Für regulierte Codebasen ist der Public-Tunnel nur ein Zwischenstopp Richtung internes Inference.

Brauche ich zwingend ngrok, oder geht Cloudflare Tunnel auch?

Cloudflare Tunnel und Tailscale Funnel erfüllen denselben Zweck: öffentliches HTTPS zum lokalen Port. Cursor-Staff nennt ngrok und Cloudflare explizit. Für Dauerbetrieb bevorzugen wir Cloudflare/Tailscale wegen stabilerer URLs.

Ist die Inferenz wirklich lokal, wenn ngrok öffentlich ist?

Ja, die Tokens werden auf Ihrer Maschine erzeugt. ngrok transportiert nur Requests. Gleichzeitig kann jeder, der die URL errät oder mitliest, Ihren Endpoint treffen. Deshalb: kurze POC-Fenster, Token schützen, schnell auf internes Netz umstellen.

Wie komme ich vom Laptop-Tunnel zum Team-Setup?

Ein zentraler GPU-Server mit Auth (Nginx/SSO), Modellkatalog und Monitoring. Cursor zeigt dann auf die interne HTTPS-URL hinter dem Firmennetz. Den Architekturpfad vom Laptop zum Team-Inference beschreiben wir im Parent-Guide zu lokalen Modellen in Cursor (siehe oben).

Nächster Schritt

Wenn der Tunnel läuft und Sie Private AI ohne Public Endpoint brauchen: Wir dimensionieren GPU, härten den Endpoint und ziehen das Setup in Ihr Netz.

Verwandte Themen