Vibe4Dock – a Docker workspace with AI CLIs in the browser

· 4 min read ·

docker tools ai dev

A short look today at a project that touches our own AI tooling landscape directly: Vibe4Dock by jbsnewmedia. A modular, Docker-based dev workspace with a web interface, built around one core goal: making AI CLIs usable from the browser – desktop, tablet, or phone.

What it is

Vibe4Dock is essentially a PHP-based web container running Apache plus a second "tools" service that ships the management UI. The setup CLI renders placeholder templates from the bundled skeleton/ directory into a fresh project. No Composer install required to start – the CLI itself runs on PHP 8+ with no extra 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

What's inside

By default, Vibe4Dock starts two services:

  • web – webdevops/php-apache-dev:8.4 with ttyd (browser terminals), tmux, git, sudo. Ports 80, 7681, 7682.
  • tools – php:8.4-cli-bookworm with the management UI on 8090.

On container startup, a sensible sequence runs: Git config from .env.local, re-install of activated tools from installed_tools.json, restore of persistent mount backups, permission fixes, then two ttyd sessions (root and app shell) as tmux sessions.

AI CLIs as first-class citizens

Tool packs live as JSON definitions under docker/tools/category/. Version 1.0.3 ships the "AI CLI" category with:

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

What I like about this: it's not about one AI CLI, but about running multiple side-by-side – each with its own login state, cache, and config, all persisted as volume mounts. You can use Claude Code in the morning, switch to OpenCode at noon, try Codex in the evening, without any of them polluting the global Node $PATH.

The addon architecture

What sets Vibe4Dock apart from "yet another devcontainer" is the addon system. Databases (MariaDB, MySQL, PostgreSQL, Firebird, Adminer), browser shells, browser IDEs (code-server), DevOps platforms (OneDev), and mail testing (Mailpit) all sit as JSON packs under docker/tools/addons/.

When you install an addon, magic happens:

1. The UI calls the install action 2. The tools container executes the commands inside the web container 3. provision.sh gets regenerated (with the matching PHP driver install for the DB extensions) 4. docker-compose.override.yml is generated if volumes are required 5. A "Manual Rebuild Required" hint gets set

The shipped rebuild watcher daemon (./docker/watcher.sh) runs as a systemd service on the host, polls the hint file every 3 seconds, and triggers ./docker/rebuild.sh automatically. Plus: a live status page in the UI that polls the rebuild progress every 2 seconds and shows the last 30 lines of docker/watcher.log. Very well thought-out.

Browser endpoint docking

What I find particularly elegant: addons can dock into the dashboard generically – either by exposing their own Compose service plus a dashboard_shell (for, say, Adminer on its own port), or through dashboard_shell.launcher for declarative ttyd sessions in the web container. The system stays addon-agnostic: no addon code in the web container, just JSON.

code-server is, for example, its own Compose service with HTTP Basic Auth – exactly the right amount of protection for a browser IDE on a network.

Persistence

Important design decision: persistent data lives outside the image in mounted directories:

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

So CLI logins, npm caches, databases, and mail captures survive every container rebuild. Practical.

Vibe-coding context

Vibe4Dock fits squarely into what we cover regularly here on AI Vibe: using AI CLIs productively without tying yourself to a single machine. The idea that "your workspace follows you, not the other way around" is consistently implemented. You're sitting in a café with a tablet, want to clone a repo, fire up a Claude Code session, and write the first tests – done.

Security reality check

The README is honest: Vibe4Dock is a dev tool, not a hardened multi-tenant platform. The tools container has Docker socket access, some tools install as root, persistent mounts can hold tokens. For localhost-first development that's fine. The moment it gets exposed to a network: enable HTTP Basic Auth (.env.local), set real passwords, put it behind a VPN/reverse proxy with ACL.

My take

What makes Vibe4Dock isn't any single feature, but the combination: modular, addon-capable, browser-first, declarative, with a thoughtful rebuild flow. If you already work with devcontainers, you'll feel right at home. If you experiment with AI CLIs on the command line, you get a reproducible environment that you can share with others.

If you want to try the setup, the fastest way is the interactive CLI – just run ./vibe4dock without arguments.

Repo: <https://github.com/jbsnewmedia/vibe4dock> · License: MIT · current version: 1.0.3 (June 2026)