Ein unternehmensinterner KI-Stack auf dem Prüfstand: Mac Mini + OpenCode + Headscale

In den vorigen Posts dieser Serie haben wir einen Mac Mini M4 mit Ollama hinter einem Headscale-VPN als lokalen LLM-Endpunkt und OpenCode als CLI-Coding-Agent mit verschiedenen Anbietern betrachtet.

In diesem Post fügen wir die Teile zusammen - nicht als Blaupause, sondern als Proof-of-Concept-Evaluierung: Wir haben diese Kombination bei Infralovers aufgebaut und in der Praxis getestet, um herauszufinden, wo die Grenzen liegen und für welche Use Cases sie wirklich taugt. Kurze Antwort vorab: Als Einstieg und für kleine Teams funktioniert es gut - sobald das Team wächst oder Agentic Coding zum täglichen Kern-Workflow wird, stößt man ziemlich schnell an die Grenzen.

Eine zentrale Erkenntnis vorab: Wir lassen nicht alles lokal laufen. OpenCode ist mit zwei Anbietern konfiguriert - dem lokalen Ollama-Endpunkt für den täglichen Einsatz und Anthropics API für Aufgaben, die tieferes Reasoning erfordern. Dieser hybride Ansatz ist der Kern des Setups.

Das Test-Setup

Das haben wir konkret aufgebaut und getestet:

• Mac Mini M4 (32GB) in unserem Büro mit Ollama und mehreren Modellen
• Headscale (self-hosted) als unser VPN-Koordinationsserver
• Tailscale-Clients auf jedem Entwicklerrechner
• OpenCode auf jedem Entwickler-Laptop, konfiguriert für den gemeinsamen Ollama-Endpunkt

Der Mac Mini dient uns als Test-Gerät für genau diese Frage: Was ist mit einem kleinen, günstigen Apple-Silicon-Rechner möglich - und lohnt sich der Invest überhaupt?

Jeder Entwickler kann sein eigenes Client-Tool wählen. OpenCode, VS Code mit Continue, JetBrains mit KI-Plugins oder sogar curl - es spielt keine Rolle. Der Ollama-Endpunkt spricht das OpenAI-API-Format, also kann alles, was mit OpenAI sprechen kann, auch mit unserem Mac Mini sprechen.

Schritt für Schritt: OpenCode mit dem Firmen-Endpunkt verbinden

1. Mac Mini im Tailnet sicherstellen

Der Mac Mini führt Ollama mit OLLAMA_HOST=0.0.0.0 aus und ist mit unserem Headscale-VPN verbunden. Seine Tailscale-IP ist stabil (z.B. 100.64.0.10), sodass er immer erreichbar ist. Alternativ lässt sich Tailscale DNS nutzen, um einen Hostnamen wie mac-mini.your-tailnet.ts.net, statt einer fixen IP, anzusprechen.

2. OpenCode konfigurieren

Auf jedem Entwicklerrechner erstellen wir eine Datei namens ~/.config/opencode/opencode.json mit folgendem Inhalt:

 1{
 2  "$schema": "https://opencode.ai/config.json",
 3  "provider": {
 4    "company-ollama": {
 5      "npm": "@ai-sdk/openai-compatible",
 6      "name": "Infralovers LLM",
 7      "options": {
 8        "baseURL": "http://100.64.0.10:11434/v1"
 9      },
10      "models": {
11        "qwen3-coder:30b": {
12          "name": "Qwen3 Coder 30B (Firma)"
13        },
14        "llama3.1:8b": {
15          "name": "Llama 3.1 8B (Firma)"
16        }
17      }
18    },
19    "anthropic": {
20      "name": "Anthropic",
21      "models": {
22        "claude-sonnet-4-5-20250929": {
23          "name": "Claude 4.5 Sonnet"
24        }
25      }
26    }
27  }
28}

Wichtig: Wir definieren zwei Anbieter in derselben Konfiguration. Den Firmen-Ollama-Endpunkt für die tägliche Arbeit und Anthropics API für Fälle, in denen wir Frontier-Modell-Reasoning brauchen. Entwickler wechseln mit /models in OpenCode zwischen ihnen.

3. Verbindung prüfen

Alles, was wir brauchen, um loszulegen, ist eine erfolgreiche Verbindung über deinen Tailscale-Client. Führe tailscale status aus, um die Konnektivität zu überprüfen, und dann können wir OpenCode starten und das Firmenmodell wählen:

 1# Sicherstellen, dass man mit dem Tailnet verbunden ist
 2tailscale status
 3
 4# Den Ollama-Endpunkt testen
 5curl http://100.64.0.10:11434/v1/models | jq
 6
 7# OpenCode starten und Firmenmodell wählen
 8opencode
 9> /models company-ollama/qwen3-coder:30b
10> Hallo, kannst du mein Projekt sehen?

Das war die Ausgangsbasis. Kein komplexes Setup, keine API-Keys für den lokalen Endpunkt, keine Abrechnungskonfiguration. VPN verbinden, loscoden - und schauen, wo es funktioniert und wo die Grenzen auftauchen.

Die Hybrid-Strategie

Wir nutzen lokale Modelle nicht für alles - und haben im Test schnell gemerkt, dass das auch nicht sinnvoll wäre. Als grobe Orientierung haben wir unterschieden, wo lokale Inferenz funktioniert und wo sie an ihre Grenzen stößt. Das ist eine Arbeitshypothese, keine gemessene Aufteilung:

Lokaler Endpunkt (Routineaufgaben - tendenziell der Großteil)

• Code-Vervollständigung und -Generierung: Boilerplate schreiben, Tests generieren, unkomplizierte Features implementieren
• Refactoring: Umbenennen, Umstrukturieren, Funktionen extrahieren
• Dokumentation: Docstrings generieren, README-Abschnitte, Inline-Kommentare
• Debugging: Fehlerprotokolle lesen, Fixes für gängige Probleme vorschlagen
• Code-Review-Unterstützung: Auf offensichtliche Probleme prüfen, Style-Konsistenz

Cloud-API (wenn lokale Modelle an Grenzen stoßen)

• Architekturentscheidungen: Systeme designen, Trade-offs evaluieren
• Komplexes Debugging: Multi-File-Probleme, subtile Logikfehler
• Sicherheits-Review: Authentifizierungsflüsse analysieren, auf Schwachstellen prüfen
• Neuartige Problemlösung: Aufgaben, die breites Wissen oder kreative Ansätze erfordern
• Long-Context-Aufgaben: Große Codebasen analysieren, die lokale Modell-Kontextlimits überschreiten

Wie sich das in der Praxis verteilt, hängt stark vom Entwickler, der Aufgabe und den genutzten Modellen ab. Wir haben noch keine belastbaren Messungen - das ist der Stand unserer laufenden Evaluation. Was wir aber schon konkret beobachtet haben: Wenn 3+ Entwickler gleichzeitig dasselbe 14B-Modell nutzen, steigen die Antwortzeiten merklich. Mit 32GB RAM ist der Spielraum für parallele Inferenz mit größeren Modellen begrenzt.

Welche anderen Tools sich verbinden können

Das Schöne an einem OpenAI-kompatiblen Endpunkt ist, dass er nicht auf OpenCode beschränkt ist. Hier sind ein paar Beispiele, was wir noch verbinden können:

Continue (VS Code / JetBrains)

Continue ist ein Open-Source KI-Code-Assistent als IDE-Erweiterung. Wir können auch diesen auf den Ollama-Endpunkt zeigen lassen:

1{
2  "models": [{
3    "title": "Firmen-LLM",
4    "provider": "ollama",
5    "model": "qwen3-coder:30b",
6    "apiBase": "http://100.64.0.10:11434"
7  }]
8}

n8n Workflow-Automatisierung

n8n kann den Ollama-Endpunkt für KI-gestützte Workflows nutzen: automatisiertes Code-Review, Dokumentationsgenerierung, Ticket-Zusammenfassung und mehr. Der AI-Agent-Node verbindet sich mit jedem OpenAI-kompatiblen Endpunkt.

Eigene Skripte

Jedes Skript, das das OpenAI Python- oder JavaScript-SDK nutzt, funktioniert durch Ändern der Base-URL:

 1from openai import OpenAI
 2
 3client = OpenAI(
 4    base_url="http://100.64.0.10:11434/v1",
 5    api_key="not-needed"  # Ollama braucht keinen Key
 6)
 7
 8response = client.chat.completions.create(
 9    model="qwen3-coder:30b",
10    messages=[{"role": "user", "content": "Prüfe diesen Code: ..."}]
11)

MCP-Server

Mit MCP-Unterstützung in sowohl OpenCode als auch anderen Tools kann man die Fähigkeiten der KI mit benutzerdefinierten Tools erweitern - Datenbankzugriff, interne APIs, Dokumentationssuche - alles über den privaten Endpunkt geroutet.

Gelerntes aus der Praxis

Nach mehreren Monaten mit diesem Setup haben wir Folgendes gelernt:

Was gut funktioniert

• Der hybride Ansatz ist entscheidend: Alles lokal machen zu wollen ist frustrierend. Akzeptieren, dass lokale Modelle Routineaufgaben gut erledigen und Cloud-APIs für den Rest eine Option sind, gibt die bessere Developer Experience - aber wie die Grenze gezogen wird, hängt vom Use Case ab.
• Headscale ist felsenfest: Einmal konfiguriert, funktioniert es einfach. Wir hatten kein einziges VPN-bezogenes Problem.
• Entwickler-Adoption geht schnell: Weil die Tools (OpenCode, Continue) vertraut sind und der Endpunkt hinter dem VPN "einfach funktioniert", gibt es keine Lernkurve außer der Modellauswahl.

Worauf man achten sollte

• Kontextfenster-Limits: Ollama hat Standardkontextlängen, die für viele Codierungsaufgaben zu klein sein können. Es ist möglich, diese zu erhöhen, aber dadurch wird mehr Speicherplatz benötigt.
• Modell-Updates erfordern Aufmerksamkeit: Wenn Ollama aktualisierte Modellgewichte veröffentlicht, muss jemand sie herunterladen. Wir führen einen einfachen Cron-Job aus: ollama pull qwen3-coder:14b wöchentlich.
• Nicht alle Modelle unterstützen Tool-Calling: Für OpenCodes agentische Features (Dateibearbeitung, Befehlsausführung) muss das Modell Tool-Calling unterstützen. Qwen3-Coder und DeepSeek-Coder handhaben das gut. Einige kleinere Modelle nicht.

Wann lokal nicht reicht

Lokale Inferenz hat reale Grenzen. Wir greifen zur Cloud-API wenn:

• Eine Aufgabe Reasoning über große Codemengen erfordert
• Das Problem wirklich neuartig ist und breites Wissen erfordert
• Genauigkeit wichtiger ist als Geschwindigkeit (Sicherheits-Reviews, Produktionsdeployments)
• Ein lokales Modell nach 2-3 Versuchen offensichtlich falsche Antworten gibt

Die Stärke dieses Setups ist nicht, dass lokal die Cloud ersetzt. Es ist, dass lokal das Volumen bewältigt und die Cloud die Komplexität.

Fazit der Evaluation

Dieser Stack braucht keinen Serverraum, kein dediziertes Ops-Team und kein sechsstelliges Budget - der Einstieg als Proof of Concept ist niedrigschwellig. Was wir gelernt haben:

• Datenschutz: Code verlässt für Routineaufgaben nie das Netzwerk
• Kosteneffizienz: Einmalige Hardware-Investition ersetzt laufende API-Rechnungen
• Flexibilität: Jedes Tool, jedes Modell, jeder Anbieter - die eigene Wahl
• Teamweiter Zugang: Das VPN macht den Endpunkt für alle überall verfügbar

Gleichzeitig gilt: Wenn das Team wächst oder Agentic Coding - also längere autonome Abläufe, parallele Agenten, große Kontextaufgaben - zum zentralen Bestandteil des Workflows wird, ist ein einzelner Mac Mini schnell überfordert. Dann stellt sich die Frage nach leistungsfähigerer lokaler Hardware oder Cloud-APIs als primärer Inferenzschicht.

Dieses Setup funktioniert für uns bei Infralovers - aber natürlich evaluieren wir auch frontier Ansätze für uns selbst und unsere Kunden. Claude Code, Codex CLI, Bob, und andere. Nicht weil lokal nicht gut genug wäre, sondern weil jedes Team individuelle Anforderungen und Präferenzen hat. Was beim einen gut funktioniert, kann beim anderen aus verschiedenen Gründen nicht in Frage kommen - eine bereits bestehende Vendor-Beziehung, Compliance-Vorgaben, oder schlicht andere Prioritäten. Diese Vielfalt ist normal, und genau deshalb lohnt es sich, mehrere Optionen zu kennen.