Vibe4Dock – ein Docker-Workspace mit AI-CLIs im Browser

· 4 min Lesezeit ·

docker tools ai dev

Heute ein kurzer Blick auf ein Projekt, das unsere eigene AI-Tool-Landschaft direkt berührt: Vibe4Dock von jbsnewmedia. Ein modularer, Docker-basierter Dev-Workspace mit Web-Interface, der vor allem ein Ziel hat: AI-CLIs vom Browser aus nutzbar machen – vom Desktop, Tablet oder Telefon.

Was es ist

Vibe4Dock ist im Kern ein PHP-basierter Web-Container mit Apache und PHP, plus ein zweiter "tools"-Service, der die Management-UI bereitstellt. Beim Setup rendert das CLI Platzhalter-Templates aus dem skeleton/-Verzeichnis in ein frisches Projekt. Keine Composer-Installation nötig zum Starten, das CLI selbst läuft mit PHP 8+ ohne weitere Dependencies.

git clone --branch 1.0.3 --depth 1 https://github.com/jbsnewmedia/vibe4dock.git
cd vibe4dock
chmod +x vibe4dock
./vibe4dock --project-name=my-workspace

Was drin steckt

Standardmäßig startet Vibe4Dock zwei Services:

  • web – webdevops/php-apache-dev:8.4 mit ttyd (Browser-Terminals), tmux, git, sudo. Ports 80, 7681, 7682.
  • tools – php:8.4-cli-bookworm mit Management-UI auf 8090.

Beim Container-Start passiert eine ganze Reihe sinnvoller Dinge: Git-Config aus .env.local, Re-Install der aktivierten Tools aus installed_tools.json, Restore der persistenten Mount-Backups, Permission-Fixes, dann zwei ttyd-Sessions (Root- und App-Shell) als tmux-Sessions.

AI-CLIs als Citizen First

Die Tool-Packs sind in JSON-Definitionen unter docker/tools/category/ abgelegt. Version 1.0.3 liefert unter "AI CLI" mit:

  • GitHub Copilot CLI
  • Codex CLI
  • Claude Code
  • Cline CLI
  • Hermes CLI
  • Junie CLI
  • OpenCode CLI

Was mich daran begeistert: Es geht nicht um eine einzelne AI-CLI, sondern darum, mehrere nebeneinander betreiben zu können – jede mit eigenem Login-State, Cache und Config, alles persistent als Volume-Mount. Du kannst morgens Claude Code benutzen, mittags zu OpenCode wechseln, abends Codex ausprobieren, ohne dass irgendwas den globalen Node-$PATH verschmutzt.

Addon-Architektur

Das, was Vibe4Dock von "noch einem devcontainer" unterscheidet, ist das Addon-System. Datenbanken (MariaDB, MySQL, PostgreSQL, Firebird, Adminer), Browser-Shells, Browser-IDEs (code-server), DevOps-Plattformen (OneDev) und Mail-Testing (Mailpit) liegen als JSON-Packs unter docker/tools/addons/.

Beim Install eines Addons passiert Magie:

1. Die UI ruft die install-Action auf 2. Der tools-Container führt die Befehle im web-Container aus 3. provision.sh wird neu generiert (mit PHP-Driver-Install für die DB-Extensions) 4. docker-compose.override.yml wird generiert, falls Volumes nötig sind 5. Ein "Manual Rebuild Required"-Hint wird gesetzt

Der mitgelieferte Rebuild-Watcher-Daemon (./docker/watcher.sh) läuft als systemd-Service auf dem Host, pollt alle 3 Sekunden die Hint-Datei und triggert ./docker/rebuild.sh automatisch. Plus: Eine Live-Status-Seite in der UI, die den Rebuild-Fortschritt alle 2 Sekunden pollt und die letzten 30 Zeilen vom docker/watcher.log anzeigt. Sehr durchdacht.

Browser-Endpoint-Docking

Was ich besonders elegant finde: Addons können sich generisch ins Dashboard docken – entweder durch eigenes Compose-Service + dashboard_shell (für z.B. Adminer auf einem eigenen Port), oder durch dashboard_shell.launcher für deklarative ttyd-Sessions im web-Container. Das System bleibt damit addon-agnostisch: kein Addon-Code im Web-Container, nur JSON.

code-server ist z.B. ein eigenes Compose-Service mit HTTP-Basic-Auth – genau das richtige Maß an Schutz für ein Browser-IDE im Netz.

Die Persistenz

Wichtige Designentscheidung: Persistente Daten landen außerhalb des Images in gemounteten Verzeichnissen:

docker/web/settings/copilot/
docker/web/settings/claude/
docker/web/settings/opencode/
docker/data/postgresql/
docker/data/mailpit/

So überleben CLI-Logins, npm-Caches, Datenbanken, Mail-Captures jeden Container-Rebuild. Praktisch.

Vibe-Coding-Kontext

Vibe4Dock ordnet sich thematisch in das ein, was wir hier auf AI Vibe regelmäßig behandeln: AI-CLIs produktiv nutzen, ohne sich an eine Maschine zu binden. Die Idee, dass "dein Workspace dir folgt, nicht umgekehrt" ist konsequent umgesetzt. Du sitzt im Café mit dem Tablet, willst ein Repo clonen + Claude-Code-Session starten + erste Tests schreiben – geht.

Sicherheits-Realitätscheck

Das README ist ehrlich: Vibe4Dock ist ein Dev-Tool, kein gehärtetes Multi-Tenant-System. Der tools-Container hat Docker-Socket-Zugriff, einige Tools installieren als root, persistente Mounts können Tokens enthalten. Für localhost-First-Development absolut ok. Sobald es Richtung "im Netz erreichbar" geht: HTTP-Basic-Auth aktivieren (.env.local), Passwörter setzen, hinter VPN/Reverse-Proxy mit ACL.

Mein Fazit

Was Vibe4Dock ausmacht, ist nicht eine einzelne Funktion, sondern die Kombination: modular, addon-fähig, browser-first, deklarativ, mit durchdachtem Rebuild-Flow. Wer schon mit Devcontainern arbeitet, wird sich schnell zu Hause fühlen. Wer mit AI-CLIs auf der Kommandozeile experimentiert, bekommt eine Reproducible-Umgebung, die er mit anderen Sharen kann.

Wenn du das Setup ausprobieren willst, ist der schnellste Weg das interaktive CLI – ./vibe4dock ohne Argumente reicht.

Repo: <https://github.com/jbsnewmedia/vibe4dock> · Lizenz: MIT · aktuelle Version: 1.0.3 (Juni 2026)