Harbor im Test: der lokale LLM-Stack per harbor up
Projektüberblick: Hören Sie auf, Ihren KI-Stack zu konfigurieren. Fangen Sie an, es zu verwenden. Ein Befehl ruft einen kompletten vorverdrahteten LLM-Stack mit Hunderten von Diensten auf, die es zu erkunden gilt.
Auf einen Blick
- Was ist das?
- Was die Python-CLI av/harbor leistet: Backends wie llama.cpp und vLLM, Frontends wie Open WebUI und Satelliten wie SearXNG mit einem Befehl vorkonfiguriert starten, plus Boost-Workflows und Grenzen.
- Für wen ist es gedacht?
- Harbor passt zu Entwicklern, die mehrere lokale LLM-Komponenten kombinieren wollen, Backends, Chat-Oberfläche, Websuche und Sprachdienste, ohne jede docker-compose-Datei von Hand zu pflegen, und die die Ergebnisse ihrer Experimente auf dem eigenen Rechner behalten. Ungeeignet ist es als Produktionsplattform, denn das README ordnet das Projekt ausdrücklich als Helfer für die lokale Entwicklungsumgebung ein, und es setzt Docker-Kenntnisse voraus, wenn etwas klemmt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
harbor up: der Ein-Befehl-Start für Open WebUI und llama.cpp
Harbor ist eine CLI mit Begleit-App aus dem Repository av/harbor, geschrieben in Python und unter der Apache-2.0 lizenziert. Das Kernversprechen steht im ersten Codeblock des README: harbor up startet einen vollständig konfigurierten lokalen LLM-Stack, standardmäßig Open WebUI als Chat-Oberfläche und llama.cpp als Backend. Mit harbor up searxng speaches kommen Websuche und Sprachausgabe hinzu, und Open WebUI kann danach laut README Web-RAG sowie TTS und STT nutzen.
Der Wert liegt in der Verdrahtung. Harbor übernimmt die Docker-Compose-Orchestrierung, die Konfiguration und die serviceübergreifende Konnektivität, man wählt Dienste aus, statt Konfigurationsdateien zu schreiben. Seit v0.5.0 ersetzt llamacpp Ollama als Standard-Backend, und die Funktion zur Portkonflikterkennung gehört ebenfalls zu dieser Version. Mit 3.197 Sternen und 224 Forks hat sich um das Projekt eine reale Nutzergruppe gebildet, die aktuelle Version v0.5.5 datiert auf den 16. August 2026.
Der Servicekatalog von Harbor: Backends, UIs und Satelliten
Der Katalog ist in drei Kategorien gegliedert. Zu den Backends zählen Ollama, llama.cpp, vLLM, TGI und SGLang, dazu hostnative Optionen wie Docker Model Runner, MLX und oMLX, die laut Baseline-Material ohne Container direkt auf macOS mit Metal laufen. Bei den UIs stehen AnythingLLM, LibreChat, Lobe Chat und Open WebUI bereit. Die Satelliten decken Websuche mit SearXNG, Workflow-Tools wie n8n und Dify 1.x, DeerFlow v2, Bildgenerierung mit ComfyUI sowie Sprachchat mit Speaches ab.
Viele dieser Dienste sind vorverbunden, und genau das unterscheidet Harbor von einer bloßen Sammlung von Compose-Dateien. Das Starten von SearXNG aktiviert die Websuche in Open WebUI, das Starten von Speaches verbindet OpenAI-kompatible Spracherkennung und -ausgabe mit derselben Oberfläche. In v0.5.5 fegt das Team laut News-Bereich zudem Dutzende Dienste auf aktuelle Upstream-Images nach, und Workspace-Dateien bleiben über mehr als 20 Dienste hinweg im Besitz des Host-Benutzers. Wer einen ganz bestimmten Dienst sucht, schaut besser in die Wiki-Seiten, das README verlinkt sie pro Eintrag.
Harbor-CLI über up hinaus: eject, qr und Modelle für MLX
Die CLI-Tour im README zeigt Befehle, die über das Starten hinausgehen. harbor llamacpp args -ngl 32 setzt Argumente für llama.cpp, harbor mlx pull mlx-community/Qwen3.5-4B-4bit holt Modelle für das hostnative MLX-Backend, und harbor hf lädt Modelle von Hugging Face, seit v0.5.3 mit schnelleren Downloads über hf_transfer. Profiles speichern ganze Konfigurationssätze und wechseln zwischen ihnen.
Zwei Befehle verdienen besondere Aufmerksamkeit. harbor eject exportiert eine Docker-Compose-Datei, die das aktuelle Setup repliziert, damit man bei Bedarf ohne Harbor weiterarbeiten kann, ein sauberes Zeichen, dass das Projekt sich nicht als Klemmverhältnis versteht. harbor qr gibt einen QR-Code aus, über den sich Dienste vom Telefon aus öffnen lassen. Dazu kommen ein lokaler Befehlsverlauf, Tab-Vervollständigung und ein Agent-Skills-CLI. Die vollständige Syntax jedes Befehls verweist das README an die CLI-Referenz im Wiki, die Liste hier zeigt die Muster, nicht jede Option.
Harbor Boost: die Workflows quickhop, deephop und diffscope
Harbor Boost ist eine Sammlung agentischer Module, die sich zu eigenen Workflows verketten lassen. Das README nennt quickhop, deephop, autocheck und diffscope als Module und führt harbor launch --workflow als Routing-Befehl ein, der Coding-Agenten durch ein Modul schickt. Ein konkretes Beispiel steht im Text: harbor launch --workflow deephop --backend ollama --model qwen3.5:4b codex. Die Module quickhop und deephop starten laut Angabe SearXNG automatisch, Workflows definieren sich über die Variable HARBOR_BOOST_WORKFLOWS oder über die Datei workflows.yaml.
Wichtig für die Erwartungshaltung: Das README beschreibt, was jedes Modul über den Namen hinaus tut, nur knapp, die Trennung zwischen Forschungs- und Prüfschritten bleibt vage. Boost startet mit harbor up boost, und die Module sind auch in der App anpassbar. Für die Bewertung heißt das, man sollte die Boost-Dokumentationsseite lesen, bevor man Workflows in den Alltag übernimmt, denn die Nützlichkeit hängt vom konkreten Agenten und Modell ab, das man dahinter setzt.
harbor doctor und die Reparaturhistorie bis v0.5.5
Ein unverzichtbarer Befehl für den Praxisbetrieb ist harbor doctor. Die Release-Historie zeigt, warum: v0.5.1 beschleunigte die Prüfung mit zeitlimitierten Compose-Checks und Early-Exit im --check-Modus, v0.5.2 behob einen hängenden Start bei nicht-interaktiver Eingabe und eine Korruption der .env-Datei, wenn mehrere Harbor-Befehle gleichzeitig laufen. Diese beiden Fälle belegen eine realistische Betriebslehre: Ein Werkzeug, das Globale Dateien schreibt, braucht genau solche Diagnosepfade.
v0.5.4 reparierte laut News-Eintrag Fehler beim ersten Start und Integrationsprobleme über mehr als 20 Dienste, gefunden durch eine neue ausführbare Integrationssuite, und v0.5.5 folgte eine große Reparaturwelle auf aktuellen Upstream-Images. Die Lesart für Nutzer: Der Servicekatalog ist groß, und einzelne Dienste können zwischen Releases brechen. Wer auf einen Dienst angewiesen ist, prüft vor jedem Update dessen Wiki-Seite und die Release-Notes, statt blind zu aktualisieren, denn die Reparaturhistorie zeigt, dass genau dort die Probleme auftreten.
Warum Harbor existiert und wo seine Grenze liegt
Der Why-Abschnitt des README ist bemerkenswert ehrlich. Wer mit Docker und Linux-Administration vertraut ist, braucht Harbor vielleicht nicht, aber wenn die eigene lokale LLM-Umgebung wächst, lande man ohnehin bei einer ähnlichen Lösung, genau so sei dieses Projekt entstanden. Festgelegt wird zugleich der Rahmen: Harbor ist keine Deployment-Lösung, sondern ein Helfer für eine lokale LLM-Entwicklungsumgebung, der Setup und Workflow zentralisiert, damit man weiß, wo Konfiguration, Logs und Daten liegen.
Die Abgrenzung zu Alternativen folgt daraus. Ein handgeschriebenes docker-compose-Setup gibt volle Kontrolle, verlangt aber Wartung bei jedem Upstream-Update, und genau diese Wartung kauft man bei Harbor ab. Ein komplett fertiges Desktop-Paket wie eine einzelne App mit integriertem Modell dagegen liefert weniger Freiheit bei der Komposition. Ein praktischer Warnhinweis steht ebenfalls im README: Beim Einsatz des eingebauten Tunnel-Dienstes sollte man den Rechner vorsichtig ans Internet koppeln. Der Tunnel öffnet lokale Dienste nach außen, und genau die sind für den Gebrauch auf dem eigenen Gerät gedacht.
Redaktionelles Fazit
Harbor passt zu Entwicklern, die mehrere lokale LLM-Komponenten kombinieren wollen, Backends, Chat-Oberfläche, Websuche und Sprachdienste, ohne jede docker-compose-Datei von Hand zu pflegen, und die die Ergebnisse ihrer Experimente auf dem eigenen Rechner behalten. Ungeeignet ist es als Produktionsplattform, denn das README ordnet das Projekt ausdrücklich als Helfer für die lokale Entwicklungsumgebung ein, und es setzt Docker-Kenntnisse voraus, wenn etwas klemmt. Vor dem Ernstfall lohnt der Lauf von harbor doctor nach der Installation, danach ein Test von harbor up searxng speaches, um zu sehen, ob Web-RAG und Sprachdienste in Open WebUI tatsächlich automatisch verdrahtet werden.
Community-Notizen