Zum Hauptinhalt springen
Standardmäßig hört Ollama auf Port 127.0.0.1:11434 – nur der eigene Rechner kann darauf zugreifen. Durch Festlegen von OLLAMA_HOST=0.0.0.0 wird es auf allen Netzwerkschnittstellen aktiv; allerdings verfügt Ollama über keine integrierte Authentifizierung: Jeder, der Zugang zum Port 11434 hat, kann die API ohne Anmeldedaten nutzen. Besser ist es, Ollama auf dem lokalen Rechner zu belassen und den Tokios-Connector daneben zu starten: Dieser verbindet sich mit https://api.tokios.com, sodass Werkzeuge, Teammitglieder oder Agenten von überall aus den authentifizierten Endpunkt 1 nutzen können.
Einfach für Einsteiger. Ollama ist die schnellste Methode, um ein lokales Modell zu betreiben – nach Eingabe von ollama run <model> ist der Dienst bereit. Es eignet sich hervorragend als erstes Backend für Tokios.

​
Was Nutzer zuerst ausprobieren – und worauf sie achten müssen

Alle genannten Werkzeuge sind durchaus brauchbare Allzweck-Tools. Keines wurde speziell dafür entwickelt, eine lokale Inferenz-API öffentlich zugänglich zu machen; daher weisen sie jeweils Einschränkungen auf, die sich gerade in diesem Szenario bemerkbar machen.
Dadurch hört Ollama auf allen Netzwerkschnittstellen zu, nicht nur auf dem Loopback-Interface. Da Ollama keine Authentifizierung mitbringt, kann jeder, der den Port erreicht, die API nutzen – Modelle auflisten, Inferenzen ausführen oder weitere Modelle herunterladen – ohne Anmeldedaten. Sicherheitsforscher (SentinelLABS/Censys, 2026) stellten fest, dass rund 175,000 Ollama-Instanzen auf diese Weise öffentlich zugänglich waren.
Die Weiterleitung von Port 11434 auf den eigenen Rechner birgt zwei Probleme. Falls der Internetanbieter CGNAT nutzt, besitzt man ohnehin keine stabile öffentliche IP-Adresse. Selbst wenn ein Port geöffnet wird, indexieren Suchdienste wie Shodan und Censys die betreffenden Dienste innerhalb weniger Stunden – und wie zuvor: Ohne zusätzliche Authentifizierung ist der Port ungeschützt.
Tailscale ermöglicht einen reibungslosen persönlichen Zugriff: Ihre eigenen Geräte treten einer privaten Mesh-Netzwerkstruktur (einem sogenannten „Tailnet“) bei und können sich gegenseitig sicher erreichen. Für andere Anwendungsfälle stellt sich jedoch ein Problem: Kollegen oder SaaS-Kunden, die Ihr Modell nutzen möchten, müssen ebenfalls dem Tailnet beitreten – was nicht zu einem Modell mit öffentlichem API-Schlüssel passt. Zwar kann Tailscale Funnel Dienste öffentlich verfügbar machen, doch dies ist auf eine begrenzte Anzahl von Ports beschränkt und die Bandbreite lässt sich nicht anpassen.
Cloudflare Tunnel leitet den Datenverkehr über die Cloudflare-Edge weiter, wobei keine eingehenden Ports erforderlich sind – das ist genau die gewünschte Lösung. Standardmäßig puffert Cloudflare Antworten statt sie direkt zu streamen, sofern die Antwort keinen text/event-stream Content-Type-Header enthält. Zudem unterliegen proxierte Anfragen den Zeitlimits von Cloudflare (im kostenlosen Tarif etwa 100 Sekunden; bei manchen Tarifen sogar kürzer). Dadurch können lange Antwortprozesse mitten im Stream abgebrochen werden.
Die Einrichtung von ngrok ist äußerst einfach und eignet sich hervorragend für Demonstrationen. Der kostenlose Tarif begrenzt die Nutzung auf 1 GB Datenmenge sowie 20,000 Anfragen pro Monat. Zudem zeigen kostenlose Tunnel vor dem Zugriff auf Ihren Dienst eine Warnseite an – das ist für Demo-Links durchaus akzeptabel, für tägliche API-Aufrufe durch Kollegen oder Agenten jedoch weniger geeignet.
Keines dieser Werkzeuge ist schlecht – sie lösen jeweils andere Probleme: Mesh-Netzwerke für Geräte, Edge-Proxying sowie schnelle Demo-Links. Tokios hingegen wurde speziell dafür entwickelt, einen lokalen Modell-Endpunkt in einen authentifizierten API-Zugang zu verwandeln, den man von überall aus nutzen kann.

​
Der ausschließlich ausgehende Ansatz

1

Starten Sie Ollama wie gewohnt lokal.

Lassen Sie Ollama auf 127.0.0.1 laufen – setzen Sie OLLAMA_HOST nicht. Laden Sie anschließend Ihr Modell herunter und führen Sie es aus.
Stellen Sie sicher, dass Ollama am Standard-Endpunkt http://127.0.0.1:11434 weiterhin lauscht.
2

Verknüpfen Sie anschließend den Tokios Connector.

Melden Sie sich unter tokios.com/console an, öffnen Sie den Reiter Setup und klicken Sie auf Start pairing. Tokios gibt Ihnen einen einmalig gültigen Pairing-Code wie TKS-XXXX-XXXX aus, der etwa 15 Minuten lang gültig ist.Führen Sie auf dem Rechner, auf dem Ollama läuft, die Installations-Anweisung für Ihr Betriebssystem aus.
Windows
macOS
Linux
Ist tokios-connector bereits installiert? Geben Sie den Code stattdessen direkt ein.
Back in the console, approve the device on the Setup or Connectors tab. The connector’s token is delivered over the tunnel once approved — you never see it on screen or paste it into a file.
3

Richten Sie den Connector so ein, dass er die /v1-API von Ollama nutzt.

Ollama stellt eine OpenAI-kompatible Schnittstelle unter /v1 bereit, mit der Tokios kommuniziert – nicht mit Ollamas nativen /api-Endpunkten. Für die einfache Nutzung mit einem einzigen Modell wählt der Einrichtungs-Assistent automatisch http://127.0.0.1:11434/v1 als Upstream-Modell. Bei mehreren Modellen in einer tokios-connector.json-Konfiguration müssen Sie die Upstream-Modell-ID BaseUrl manuell festlegen.
Weitere Informationen zum Dateiformat für mehrere Modelle finden Sie unter Connector-Konfiguration.
4

Erstellen Sie eine neue Deployment.

In der Registerkarte Models legen Sie das Ollama-Modell an und wählen einen öffentlichen Namen – etwa llama3-tunnel. Dieser öffentliche Name, nicht die lokale Upstream-Modell-ID von Ollama, wird von Clients im Feld model übermittelt.
5

Generieren Sie einen API-Schlüssel.

Wechseln Sie in die Registerkarte Keys und klicken Sie auf Create key. Sie können den Schlüssel optional auf bestimmte Deployments beschränken, indem Sie Modellnamenmuster angibt (kommagetrennt; mit * gelten alle). Kopieren Sie nun den sk-tok-…-Schlüssel – er wird nur einmal angezeigt.

​
Nutzen Sie ihn anschließend von beliebigen Orten aus.

Sobald Sie einen Deployment-Namen sowie einen API-Schlüssel besitzen, kann jeder OpenAI- oder Anthropic-kompatible Client Ihr Ollama-Modell erreichen – unabhängig davon, ob er sich auf einem anderen Rechner, dem Laptop eines Teammitglieds oder einem gehosteten Agenten befindet.
Das Feld model enthält stets den von Ihnen registrierten Namen der Deployment-Instanz (siehe llama3-tunnel oben); niemals die lokale Upstream-Modell-ID von Ollama. Weitere Informationen zur dauerhaften Einstellung der Umgebungsvariablen finden Sie unter Verwendung von Claude Code.

​
Tokios im Vergleich zu Ollama Cloud

Ollama stellt zudem Ollama Cloud bereit – gehostete Modelle, auf die Sie über ollama run <model>:cloud oder einen Ollama API-Schlüssel zugreifen können. Dabei werden die Modellgewichte auf der Infrastruktur von Ollama ausgeführt und über Ihren lokalen ollama-Daemon weitergeleitet, solange Sie angemeldet sind. Diese Variante ist zwar praktisch, doch sie stellt das Gegenteil von einer Selbsthosting-Lösung dar: Ihre Anfragen gelangen zu Ollama-Servern, und ein :cloud-Tag enthält keine lokalen Gewichte, die Sie steuern könnten. Aus genau diesem Grund sind einige Spitzenmodelle – etwa Kimi, MiniMax sowie die größten Varianten der Nemotron-Reihe – ausschließlich über :cloud verfügbar. Tokios dient dem anderen Szenario: Das Modell läuft auf Ihrer Hardware, während Tokios lediglich einen authentifizierten Endpunkt davor bereitstellt. Sie behalten die volle Kontrolle über die Modellgewichte, den Datenspeicherort sowie die API-Schlüssel. Beides ist möglich: Sie können kleine Modelle lokal über Tokios nutzen und bei Bedarf auf ein :cloud-Modell zugreifen – doch nur die lokale Variante sichert Ihre Daten auf Ihrer eigenen Hardware.

​
Häufig gestellte Fragen

Standardmäßig hört Ollama auf Port 11434, wobei die Bindung auf 127.0.0.1 erfolgt (ausschließlich localhost). Mithilfe der Umgebungsvariable OLLAMA_HOST lässt sich sowohl der Port als auch die Bindeadresse ändern – beispielsweise sorgt OLLAMA_HOST=0.0.0.0:11435 dafür, dass Ollama auf allen Schnittstellen am Port 11435 erreichbar ist. Prüfen Sie den Betriebsstatus mittels curl http://localhost:11434.
Setzen Sie die Umgebungsvariable OLLAMA_HOST=0.0.0.0 (oder OLLAMA_HOST=0.0.0.0:11434) und starten Sie Ollama neu. Unter Linux mit systemd fügen Sie Environment="OLLAMA_HOST=0.0.0.0:11434" unter [Service] in ollama.service hinzu und führen anschließend systemctl daemon-reload && systemctl restart ollama aus. Auf macOS nutzen Sie launchctl setenv OLLAMA_HOST "0.0.0.0:11434". Unter Windows legen Sie OLLAMA_HOST in den Benutzereinstellungen fest und starten Ollama erneut.
Nein. Ollama verfügt über keine integrierte Authentifizierung – es wurde für den lokalen Einsatz konzipiert, nicht für die Steuerung von Zugriffsrechten in Multi-Tenant-Umgebungen. Die Entwickler empfehlen, bei Bedarf ein Reverse-Proxy-System wie nginx oder Caddy vorzuschalten. Tokios hingegen erstellt bereichsbezogene sk-tok-… API-Schlüssel ohne solche Proxy-Lösungen: Man verknüpft einen Connector, registriert eine Deployment-Einstellung und generiert anschließend einen Schlüssel – Anfragen werden dann gegen https://api.tokios.com authentifiziert, nicht gegen den eigentlichen Ollama-Port.
Ollama stellt sowohl native als auch OpenAI-kompatible Endpunkte bereit. Für die native API lautet die Adresse: curl http://localhost:11434/api/generate -d '{"model": "llama3", "prompt": "Hello"}'. Für die OpenAI-kompatible Schnittstelle gilt: curl http://localhost:11434/v1/chat/completions -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello"}]}'. Von einem entfernten Rechner aus muss localhost durch die IP-Adresse des Servers ersetzt werden (dafür ist OLLAMA_HOST=0.0.0.0 erforderlich).
Ja. Standardmäßig akzeptiert Ollama Cross-Origin-Anfragen von 127.0.0.1 sowie 0.0.0.0. Durch Setzen von OLLAMA_ORIGINS lassen sich weitere Ursprungsadressen hinzufügen; für Browser-Erweiterungen ist OLLAMA_ORIGINS=chrome-extension://*,moz-extension://* zu verwenden. Dies gilt ausschließlich für browserbasierte Clients; API-Clients, die curl oder SDKs nutzen, unterliegen nicht den CORS-Regeln.
Ja. Setzen Sie "stream": true, und Tokios liefert Server-Sent Events (SSE) im OpenAI- oder Anthropic-Format – je nach gewählter API-Schnittstelle.
Ja. Erstellen Sie für jedes Teammitglied ein eigenes sk-tok-… Schlüsselpaar im Bereich Keys und begrenzen Sie dessen Gültigkeit auf die jeweils benötigten Deployment-Einstellungen. Durch Deaktivierung eines Schlüssels wird die Authentifizierung sofort blockiert – somit lässt sich der Zugriff ohne Änderungen an Ollama oder dem Connector entziehen.
Ja. Registrieren Sie weitere Deployment-Einstellungen im Bereich Models oder nutzen Sie eine tokios-connector.json Konfigurationsdatei, um mehrere Upstream-Modell-IDs sowie Routen für einen einzigen Connector festzulegen. Nähere Informationen finden Sie unter Connector-Konfiguration.
Nein. Tokios nutzt die OpenAI Chat Completions-Schnittstelle, weshalb es mit Ollamas /v1 OpenAI-kompatibler API kommuniziert und nicht mit den nativen /api/generate bzw. /api/chat Endpunkten.

​
Ihr Upstream-Modell verlässt niemals Ihren Rechner – Ihr Endpunkt ist überall nutzbar.

Ollama funktioniert weiterhin exakt wie bisher auf Ihrem lokalen Rechner, ohne eingehende Ports oder exponierte API. Der Connector initiiert lediglich ausgehende Verbindungen. Alles Weitere – Authentifizierung, Routing sowie Datenübertragung – geschieht über einen einzigen Endpunkt, den Sie von jedem beliebigen Rechner, Teammitglied oder Agenten aus aufrufen können, dem Sie einen API-Schlüssel zuweisen.

Schnellstart

Verknüpfen Sie einen Connector und registrieren Sie Ihr erstes Modell in nur wenigen Schritten.

API-Schlüssel

Erstellen, definieren und wechseln Sie sk-tok-…-Schlüssel für Teammitglieder sowie Agenten.

Steuerung durch einen Coding-Agenten

Richten Sie Claude Code, Codex, Cline oder Cursor so ein, dass sie Ihr Ollama-Modell via Tokios nutzen können.