Vibe Kanban: A Kanban Board That Drives Coding Agents, Now Sunsetting

The problem Vibe Kanban targets: planning and reviewing agents, not writing code

The README opens with a claim about where engineering time actually goes: engineers spend most of their time planning and reviewing coding agents, so the fastest way to ship more is to get faster at those two activities. That framing decides the product's shape. Vibe Kanban is not an agent and not a model wrapper. It is a board plus a workspace runner that sits around whichever agent you already authenticated. You create kanban issues to plan work, either privately or with your team, and when an issue is ready you create a workspace where an agent executes. The intended user is someone who already pays for or runs Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid, CCR or Qwen Code, and who currently juggles terminals, branches and diffs by hand. If you write code without agents, or you run one agent on one task at a time, the board adds a layer you will not use.

Workspaces, worktrees and the flow from issue to pull request

The mechanism the README describes is a workspace per unit of agent work. Each workspace gives an agent a branch, a terminal and a dev server, which is the concrete part of the architecture worth understanding: the isolation is per workspace, not per issue globally, and the git worktree machinery is visible in the environment variable list, where DISABLE_WORKTREE_CLEANUP turns off all git worktree cleanup, including orphan and expired workspace cleanup, for debugging. So the project creates and removes worktrees on your behalf, and that cleanup is a feature you can switch off when it misbehaves. Around the workspace sit the review surfaces: diffs with inline comments that go back to the agent without leaving the UI, a built-in browser with devtools, inspect mode and device emulation for previewing the app, and PR creation with AI-generated descriptions, after which review happens on GitHub and the merge happens there. The data flow is therefore issue, workspace, agent run, diff, inline feedback, preview, pull request. The backend is Rust and the repo is a pnpm monorepo with a local-web package, so the UI is served by a local backend process rather than being a hosted service in the default setup.

Running it: one npx command, then the environment variables that matter

The README gives a single install path. Authenticate with your coding agent first, then run npx vibe-kanban. The docs link for the supported agent list is vibekanban.com/docs/supported-coding-agents, and that link is the first thing to check because the agent list in the README is a claim about support, not a guarantee that your version and authentication method work. Configuration is environment variables, split into build-time and runtime. POSTHOG_API_KEY and POSTHOG_API_ENDPOINT are build-time; leaving them empty disables analytics. PORT behaves differently by mode: in production it is the server port, in dev it is the frontend port and the backend uses PORT+1. BACKEND_PORT and FRONTEND_PORT override that in dev only, with FRONTEND_PORT defaulting to 3000. HOST defaults to 127.0.0.1, and MCP_HOST defaults to the value of HOST, with the README noting you should use 127.0.0.1 when HOST is 0.0.0.0 on Windows. MCP_PORT defaults to BACKEND_PORT. Two variables matter for anything beyond a laptop: VK_ALLOWED_ORIGINS, a comma-separated list of origins allowed to call the backend API, and VK_SHARED_API_BASE plus VK_SHARED_RELAY_API_BASE and VK_TUNNEL for the cloud and relay paths. The README is explicit that behind nginx, Caddy or Traefik, or on a custom domain, you must set VK_ALLOWED_ORIGINS or the browser Origin header will not match and API requests fail with 403. For source builds on macOS the README lists ./local-build.sh and then cd npx-cli && node bin/cli.js. Development needs Rust stable, Node 20 or later and pnpm 8 or later, plus cargo-watch and sqlx-cli, then pnpm i and pnpm run dev, which copies a blank database from dev_assets_seed.

The sunsetting notice changes what a fair evaluation looks like

The README contains a heading that says Vibe Kanban is sunsetting, with a link to vibekanban.com/blog/shutdown. That sentence sits above the feature list and below the badges, and it is the single most important fact in the repository for anyone deciding whether to install it. It means the usual questions about roadmap, issue triage and release cadence have a known answer, and it means the release history should be read as a record of what exists rather than a signal of what is coming. The releases listed run to v0.1.44 dated 2026-04-24, with v0.1.43 a week earlier and v0.1.42 before that. Version numbering at 0.1.x is consistent with a product that never declared a stable interface. The Apache-2.0 licence means the code remains available for you to run, fork and modify, and the README documents self-hosting through a Docker deploy guide at vibekanban.com/docs/self-hosting/deploy-docker. What the licence does not give you is anyone to fix a broken agent integration when a CLI changes its flags. Treat the project as source you may have to maintain, not as a service you can depend on. This is a description of the licence terms and the stated status, not legal advice; if you plan to redistribute a modified build, read the Apache-2.0 text and the shutdown announcement yourself.

Where it breaks: worktree cleanup, agent drift and remote setup

The failure modes follow from the design. Worktree cleanup is the most visible one: the README exposes DISABLE_WORKTREE_CLEANUP specifically to disable orphan and expired workspace cleanup for debugging, which tells you that cleanup can go wrong in normal use and that the escape hatch is a debugging flag rather than a settings toggle. Running many workspaces means many branches, terminals and dev servers on one machine, and the README does not describe resource limits or scheduling, so the practical ceiling is your hardware. Agent drift is the second: the product depends on external CLIs that change on their own schedule, and a sunsetting project will not chase those changes. Remote use is the third. The README describes running on a remote server via systemctl, Docker or cloud hosting, exposing the UI through Cloudflare Tunnel or ngrok, and then configuring Remote SSH Host and Remote SSH User under Settings, Editor Integration, with SSH access from you as a prerequisite. Each of those steps is a place where the setup can fail, and the 403 from a missing VK_ALLOWED_ORIGINS is the one the README calls out directly. If your team needs a supported product with a vendor behind it, this is the wrong tool regardless of how well the board suits your workflow.

What you would use instead, and how the approach differs

The honest alternative is the workflow Vibe Kanban is built on top of: your agent CLI plus git worktrees plus a terminal, with pull requests reviewed on GitHub. That combination has no board, no per-workspace dev server managed for you, and no inline comments routed back into the agent, but every piece is maintained by someone else and the failure modes are ones you already know. A second alternative is running each agent in its own checkout or container and tracking tasks in whatever issue tracker you already use, which keeps planning and execution separate rather than merging them into one UI. The difference in approach is where the state lives. Vibe Kanban keeps issues, workspaces, branches, diffs and previews in one local application backed by a database seeded from dev_assets_seed, and exposes an MCP server on MCP_HOST and MCP_PORT so agents can talk to it. The manual alternative keeps that state spread across git, your tracker and your terminal, which costs coordination effort but has no single component to sunset. If what you actually want is the diff review loop with inline comments, that is the part with no easy substitute, and it is the part worth testing before you commit to the rest.

Maintenance cost and what to verify before you install

For a sunsetting project the maintenance question is concrete. You need Rust stable, Node 20 or later and pnpm 8 or later to build from source, and sqlx-cli plus cargo-watch for development, which means you are committing to a toolchain, not just a binary. The npx path avoids that until the published package stops working against a newer agent CLI, at which point the fallback is ./local-build.sh and cd npx-cli && node bin/cli.js, or patching the source under Apache-2.0. The database is SQLite-shaped in development, copied from dev_assets_seed, and the README does not describe a migration or backup story, so plan for the possibility that a schema change in a fork leaves you with data you cannot move. Before installing, verify the shutdown announcement, confirm your specific agent appears on the supported list, and decide whether you are comfortable running a local service that creates and deletes git worktrees in your repositories. The worktree behaviour is the one to test first, on a throwaway repository, because it is the part that touches your code.

Editorial conclusion

Vibe Kanban fits engineers who already run Claude Code, Codex, Gemini CLI or similar agents and want issue planning, per-agent git worktrees, diff review with inline comments and PR creation in one local UI. It does not fit anyone who needs a maintained dependency, since the README states the project is sunsetting. Before adopting, verify three things in this order: read the shutdown announcement at vibekanban.com/blog/shutdown, confirm your agent is on the supported list at vibekanban.com/docs/supported-coding-agents, and check whether the Apache-2.0 source and the self-hosting Docker guide are enough for you to carry the code yourself.

Official sources

1. BloopAI/vibe-kanban on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases