Harbor turns a local AI stack into named Compose services
Harbor sits above Docker Compose and gives each supported application a common command surface. The default harbor up starts Open WebUI with llama.cpp. Add SearXNG for web search, Speaches for speech, ComfyUI for images, or another inference backend by naming it in the same command. Harbor supplies the service definitions, shared network, configuration, and many cross-service connections. That is much faster than learning a dozen unrelated Compose files just to compare local tools.
The catalog is broad enough to change the nature of the product. It includes chat interfaces, inference servers, agent tools, workflow builders, search systems, observability services, and MCP bridges. A user can run Ollama today, test vLLM tomorrow, and keep Open WebUI in front. The eject command can export selected services to a standalone Compose file, which provides a sensible exit once an experiment settles into a stack worth maintaining directly.
A 19-second package install does not include models or containers
Our sandbox cloned commit 76469b1 into a fresh Debian container with 3 CPUs and 8 GB of RAM. Yarn installed 97 packages in 19 seconds and occupied 121 MB. The checkout itself was 50.1 MB, with 2,253 files and roughly 124,349 source lines. Those figures describe the Harbor repository and its JavaScript dependencies, not the container images, model weights, caches, or generated media used by a working AI setup.
The installation guide asks for Docker, Git, curl, Compose 2.23.1 or newer, and at least 10 GB of free disk for its quick path. The longer platform guides recommend 20 GB. First launch creates a local Open WebUI administrator account. A fully local llama.cpp route can start without a hosted API credential, while cloud providers and some optional services bring their own keys. Model downloads and image pulls can make the operational footprint much larger than our measured 121 MB.
What happened when we ran it
Our run completed the Yarn install in 19 seconds with 97 packages added. Harbor did not expose a build script or target, so the build step was skipped. It also had no test script or target, which left the test step skipped. We therefore confirmed that its package dependencies resolve at commit 76469b1, but did not get an automated signal that a service could start or that its integrations worked.
That gap is noticeable because the 2,253-file repository had 6 CI workflow files, a Compose file, and a tests directory. It had no repository Dockerfile. These are structural signals rather than passed checks, and we will not treat them as substitutes for the missing commands. A serious trial should start the exact backend, UI, and satellite combination you intend to use, then verify model download, health checks, authentication, and a real request through each connection.
The project says local development, not production deployment
The README gives an unusually direct scope statement: Harbor is a helper for a local LLM development environment and is not designed as a deployment solution. Its conveniences fit that job. Profiles remember model and service settings, command history records Harbor invocations, harbor doctor checks the host, and the companion app offers a guided path for people who do not want to live entirely in a shell.
Production asks different questions. Open issue 231 reports that a default stack bound Open WebUI and Ollama to 0.0.0.0, making their mapped ports reachable beyond localhost where the host network allows it. The README separately warns that harbor tunnel is unsafe without authentication. Before loading business documents or provider keys, inspect docker ps, bind services to intended interfaces, enable application authentication, and decide whether the built-in tunnel belongs anywhere near the environment.
Hardware support varies by service and operating system
Windows installation runs through WSL2, with WSL1 explicitly unsupported. On macOS 11 or newer, Docker Desktop handles the containers, but the guide says GPU passthrough is unavailable. Harbor works around that limitation for inference through host-native Docker Model Runner, MLX, and oMLX backends exposed to containers through a proxy. Some catalog images do not publish ARM64 builds, so Apple Silicon does not guarantee access to every named service.
Linux gives NVIDIA and AMD users more direct GPU paths, but each inference server still has its own model format, runtime flags, and memory demands. Harbor can share caches where integrations permit and can remember backend arguments. It cannot make a model fit into limited VRAM or make an incompatible image support a processor. Select one representative model and backend first, verify the GPU is used, then add search, speech, or agent services one at a time.
A wide catalog inherits upstream breakage
Release v0.5.5 was published on August 16, 2026, the same date as the repository's last push in the metadata we fetched. It changed file ownership across more than 20 services, upgraded Dify and DeerFlow, moved ComfyUI to another image, and repaired dozens of integrations affected by current upstream images. GitHub listed 65 combined open issues and pull requests, with newer pull requests still addressing individual services after that release.
That activity is both reassuring and cautionary. Maintainers are repairing concrete failures, but every extra backend or satellite adds an upstream image, environment format, port, and credential scheme that can drift. Harbor is worth using when that maintenance is cheaper than assembling an evaluation lab yourself. Once a chosen setup becomes important, eject its Compose definition, pin image versions where possible, and own the checks that our repository-level run could not execute.