Vibe Kanban: a kanban board for directing coding agents in parallel

A kanban board for planning, running, and reviewing tasks through coding agents (Claude Code, Codex, Gemini CLI, Copilot, and others), which after the closure of the company bloop transitions to open, community maintenance. As of September 1, 2026 it carries 27,979 stars.

---

What Vibe Kanban is

Vibe Kanban is a desktop application (with a web component and a self-hosted option) whose stated goal in the README is to “get 10x more out of Claude Code, Codex, or any coding agent.” It isn’t an agent itself — it’s an orchestrator. The engineer creates tasks (issues) on a kanban board and, when ready to run one, creates a workspace where an agent receives a git branch (a worktree), a terminal, and a dev server. The user can watch the diff live, leave inline comments that go back to the agent, preview the app in an embedded browser, and open the pull request (PR) from the interface itself.

The team’s starting point, as one of its creators explained in the Hacker News announcement, was the feeling of being “useless” while waiting 2 to 5 minutes for an agent to finish a task. The pitch was to parallelize agents in the background and use that time for planning and reviewing, which, per their thesis, are the activities increasingly occupying engineers’ time.

The product is built with a Rust backend and a Node.js frontend (requiring Node ≥ 20, pnpm ≥ 8), packaged as a desktop app via Tauri, with its own MCP server and self-hosting capability via Docker.

Disambiguation note: the BloopAI/vibe-kanban repository shouldn’t be confused with BloopAI/bloop, from the same organization, which is a fast code search engine written in Rust — an earlier and distinct product from the company. This report documents only vibe-kanban.

Origin

The repository was created on June 14, 2025 under the BloopAI organization. The company behind it is bloop (Bloop AI Limited), founded by Louis Knight-Webb (louiskw) and Gabriel Gordon Hall (ggordonhall), among others. Per the shutdown announcement published on April 10, 2026, the team “launched in June 2025.”

The most visible public announcement was the Show HN on July 11, 2025 (thread 44533004, 195 points, 132 comments), where Louis Knight-Webb presented the project and described the motivation: the 2-5 minute wait per task led to distraction, and he wanted a way to parallelize agents and put that time to productive use.

The most important narrative fact for anyone using the project today is its ending: on April 10, 2026, bloop announced the closure of the company. The statement (signed by Louis, Gabriel, and the bloop team) explains that although “thousands of software engineers use Vibe Kanban every day,” the vast majority were free-tier users, and “we couldn’t find a business model we were excited about.” As a result, the Vibe Kanban project continues as open source, community-maintained software, and the company promised to publish a roadmap for the community edition in the following weeks. Remote features (issues, comments, projects, and cloud organizations) remained available for 30 days after the announcement, after which they transitioned to a fully local architecture; refunds were issued for invoices from the preceding 30 days, and subscriptions were canceled. The final version includes a data export feature.

This context shapes everything else: the project has real traction (nearly 28,000 stars) but its institutional maintenance has ceased, so its future depends on the community.

Philosophy and principles

Verifiable ideas running through the README, docs, and announcement:

• The bottleneck is no longer writing code, but planning and reviewing. The README opens: “In a world where engineers spend most of their time planning and reviewing coding agents, the highest-leverage way to ship more is to get faster at planning and reviewing.”
• Agent parallelism as the unit of work. The core value is launching several agents at once in isolated spaces (each with its own branch, terminal, and server), so the human reviews in batches instead of waiting sequentially.
• Review is the interface, not chat. The product puts the diff, inline comments, and preview at the center, on the premise that the human engineer maintains quality.
• Agent neutrality. It doesn’t impose a single agent: it supports and switches between more than ten, making it an abstraction layer over each provider’s existing CLIs.

There’s an explicit tension in community reception (see “Community reception”): several users questioned whether the premise that “engineers spend most of their time planning and reviewing” holds today, and others objected to the scope of the GitHub authentication permissions the initial version requested.

How it works

The flow documented in the Get Started guide has these phases:

1. Launch with npx vibe-kanban, which opens the UI in the browser.
2. Initial preferences: choose coding agent, IDE, and notifications.
3. Sign in with GitHub or Google (can be skipped, but then there’s no board, issues, or team features; local workspaces can still be created).
4. Kanban board: create and prioritize issues (title, description, priority, labels, and parent/child relationships).
5. Create a workspace: on selection, Vibe Kanban creates git worktrees for the chosen repositories (on the specified branches), launches the agent with the prompt and configuration (model, effort level, plan mode). Multiple workspaces can be attached to the same issue to run agents in parallel, or workspaces without an issue for quick queries.
6. Review: view the changes, preview the app in the embedded browser (with devtools, inspection mode, and device emulation), comment inline.
7. Merge: open a GitHub PR with an AI-generated description, or merge the branch locally.

Key technical features per the README and documentation:

• 10+ interchangeable agents: Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot, Amp, Cursor Agent CLI, OpenCode, Factory Droid, CCR (Claude Code Router), and Qwen Code.
• Its own MCP server: from the “MCP Servers” tab, you can add Vibe Kanban’s MCP so an agent creates tickets on the board (e.g. “plan an AWS to Azure migration and create a ticket for each step”).
• Version control integrations: GitHub and Azure Repos.
• VSCode extension (also Cursor and Windsurf) and remote SSH configuration to open remote projects in the local editor.
• Self-hosting the “Vibe Kanban Cloud” instance via Docker Compose.

Review view: a diff viewer with neon-highlighted lines, inline comments sent back to the agent, an embedded browser with device emulation and devtools, and a merge panel with buttons to open a PR or merge locally.

The ecosystem

Repositories under the BloopAI organization

Beyond vibe-kanban, the organization contains related repositories (star counts from the GitHub API at the time of this research):

• BloopAI/dev-manager-mcp: an MCP server to “run multiple dev servers in parallel”; 140 stars.
• BloopAI/vibe-kanban-web-companion: “edit websites in Vibe Kanban”; 44 stars.
• BloopAI/debugger-mcp: an MCP server for interactive debugging; 30 stars.
• BloopAI/experiments: predictions, run logs, trajectories, and inference/evaluation results on the SWE-bench task; no recorded stars.
• BloopAI/bloop: a fast code search engine in Rust (an earlier and distinct product from Vibe Kanban); 9,497 stars. It’s mentioned because a user in the launch thread (skeptrune) wrote “I remember the original Bloop search engine,” confirming it’s the company’s predecessor.

Community alternatives, forks, and extensions

A GitHub repository search (query vibe-kanban, sorted by stars, 314 total results) returned several derivative projects or competitors citing Vibe Kanban directly. Among the most visible:

• knowsuchagency/fulcrum: “What if Openclaw, Vibe Kanban, Vibetunnel, and Dokploy had a baby?”; 90 stars.
• automagik-dev/forge: “The Vibe Coding++™ platform — orchestrate multiple AI agents, experiment with isolated attempts, ship code you understand. Multi-agent kanban with MCP integration”; 89 stars.
• ariaghora/korlap: “a kanban board for doing vibes”; 75 stars.
• halilbarim/vibe-stack: “Docker setup for AI coding with Vibe-Kanban + Claude Code; secure secrets, browser-based VS Code, ready to deploy”; 47 stars.
• GarrickZ2/grove: “A kanban-style TUI for parallel AI coding. Manages git worktrees as tasks and runs multiple agents in isolated tmux sessions”; 46 stars.
• qwenode/vibe-kanban-promax: “a refined fork of vibe-kanban with better UI, usability fixes, local-only mode, and no login required”; 13 stars.
• p-wegner/agentic-kanban: “a cleanroom reimplementation of vibe-kanban”; 4 stars.
• yigitkonur/mcp-better-vibe-kanban: an MCP server to manage Vibe Kanban tasks and sessions from the AI editor; 5 stars.
• oculairmedia/vibesync: bidirectional sync between Huly and Vibe Kanban via MCP; 3 stars.
• mac-tron/kando: “Think. Plan. Act. Think and plan in Obsidian, execute in Vibe Kanban”; 3 stars.

Several of these projects also appeared as replies in the Hacker News thread or in their own threads (see reception section): ericblue/claude-vibekanban (PRD-driven flow), flashlan/vibe-kanban-alternative (kanban with mem0 persistent memory), ferrislucas/Circus-Chief (agents from mobile), battysh/batty (a tmux agent team with test-driven control), and silo-rs/silo (each branch with its own localhost).

These figures are what the GitHub search returned during this research and aren’t a quality, support, or compatibility audit of each derivative.

Official and semi-official status

Vibe Kanban does not hold an “official status” in the plugin-marketplace sense: it’s a standalone application, not a package others distribute. Its relevant status has two parts:

• Self-claimed primacy (per the team’s shutdown announcement): bloop states it was “the first to offer multi-agent support, diff comments, live preview, click-to-edit, remote access, and many other features taken for granted today.” These are the team’s own claims, not certification by an external body.
• De facto, and now in transition: through its adoption (“thousands of engineers use it every day,” per bloop) it became a practical reference for orchestrating agents in parallel. With the company’s closure (April 2026), it’s become community-maintained: the current README carries the notice “Vibe Kanban is sunsetting” linking to the announcement, the latest official release (v0.1.44) is from April 24, 2026, and remote services are being retired in favor of a local architecture.

In practice, this means the local app keeps working, but cloud features (shared issues, teams, organizations) become obsolete in the medium term, and the support channel shifts from the company to GitHub Discussions and a community Discord.

Quick-start guide

Installation and first run

Prerequisite: having already authenticated the coding agent you want to use (the full list and each one’s instructions are in the docs). Then:

npx vibe-kanban

On first run, the app asks for your preferred coding agent, IDE, and notification preferences (changeable later in the settings dialog). It then offers to sign in with GitHub or Google; if skipped (“More options” → “I understand, continue without signing in”), local workspaces can be created but not the board, issues, or team features. With a session, a personal organization and an initial project are created automatically.

Context warning: given bloop’s closure, sign-in and cloud features are in a transitional state. For durable use, it’s worth planning a data export (available in the latest version) and considering local mode or a community alternative (see “The ecosystem”).

Common workflows

• Plan and run a task: create an issue on the board → select it → “Create workspace,” choosing repository, base branch, agent, and configuration (model, effort, plan mode) → the agent starts with the prompt → review the diff and merge via “open GitHub PR” or a local merge.
• Run in parallel: attach multiple workspaces to the same issue (one per agent/branch) to work a large feature at once; when done, review each diff separately.
• Leave feedback without leaving the UI: in the workspace view, open the changes panel, comment inline on the diff, and send the comment to the agent so it iterates before merging.
• Have the agent plan: add Vibe Kanban’s MCP server (“MCP Servers” tab → “Add Vibe Kanban MCP”) and ask the agent to break a large task into tickets (e.g. “plan an AWS to Azure migration and create a ticket for each step”).

Essential configuration

The settings a new user touches first, per the docs and README:

• Default agent / agent profiles (Settings → Agent Profiles & Configuration): reusable configurations with plan mode, model, and permission level, applied when creating task attempts.
• Editor integration (Settings → General / Editor Integration): choose an IDE (VSCode, Cursor, Windsurf) and, for remote deployments, the Remote SSH Host and user, so “Open in VSCode” buttons generate vscode://vscode-remote/ssh-remote+user@host/path.
• Backend environment variables (README): PORT, HOST (defaults to 127.0.0.1), MCP_PORT, and, behind a reverse proxy or custom domain, VK_ALLOWED_ORIGINS (see pitfalls).
• Per-repository setup/cleanup scripts (Settings → Projects & Repositories): automate dependency installation, builds, and teardown so every workspace starts clean.
• MCP servers (Settings → Connecting MCP Servers): add servers to extend agents’ toolset within Vibe Kanban.

Common pitfalls and fixes

• 403 “Forbidden” error when self-hosting behind a custom domain or reverse proxy (nginx, Caddy, Traefik): the browser’s Origin doesn’t match the host the backend expects. Documented fix: set VK_ALLOWED_ORIGINS to the origin (or comma-separated origins) where the frontend is accessible, e.g. VK_ALLOWED_ORIGINS=https://vk.example.com.
• Overly broad GitHub permissions: in the launch thread, several users (csomar, doritosfan84) objected that the app requested unlimited access to private repos. The team replied it was needed to open PRs and read CI results; the practical recommendation users derived themselves is to use a GitHub App (fine-grained permissions) instead of an OAuth App. Given the shutdown, it’s worth minimizing the scope of access granted.
• Machine slowdown with multiple agents: Louis Knight-Webb acknowledged in the thread that “the MacBook gets slow after 4 concurrent runs, mostly from rustc.” Isolating workspaces and capping the number of concurrent agents is the natural mitigation.
• MCP on Windows with HOST=0.0.0.0: the README says to explicitly use MCP_HOST=127.0.0.1 when HOST=0.0.0.0, so the MCP server connects correctly.
• Process leaks/state (documented in releases): recent versions fixed issues like a “conversation history leak” (a Zustand-to-React-Context regression) and reaping of execution process groups on exit; updating to the latest version reduces these.

Integrations and migration

• MCP: Vibe Kanban both exposes and consumes MCP — to add third-party servers to agents, and so an agent can create tickets through Vibe Kanban’s own MCP.
• Version control: GitHub (PRs, CI) and Azure Repos; integration with the VSCode/Cursor/Windsurf extension.
• Self-hosting: Docker Compose to deploy the “Cloud” instance on any server; tunnels (Cloudflare Tunnel, ngrok) or relay-tunnel mode (VK_TUNNEL) for remote access.
• Migration / exit: given the sunset, the latest version includes data export. To continue independently, the verifiable routes are the fully local mode bloop announced, or community alternatives with an explicit local, no-login intent (for example, the qwenode/vibe-kanban-promax fork, “local-only mode, and no login required,” and cleanroom reimplementations like p-wegner/agentic-kanban).

Current metrics

Measured: September 1, 2026, GitHub and npm public APIs/registries.

Metric	Value
Stars	27,979
Forks	2,998
Subscribers (real watchers)	119
Open issues per API	533
Primary language	Rust
License	Apache License 2.0
Created	June 14, 2025
Last push	April 24, 2026
Latest release	v0.1.44, April 24, 2026
npm downloads (last week)	2,091 (2026-08-23 → 2026-08-29)
npm downloads (last month)	7,386 (2026-07-31 → 2026-08-29)

Top contributors returned by the API, by contribution count: stunningpixels (878), abcpro1 (257), LSRCT (235), actions-user (213), and anastasiya1155 (112).

Caveats: the GitHub API exposes open_issues_count, which includes open pull requests, so 533 shouldn’t be read as an issues-only count. The general response’s watchers_count field mirrors the stars; that’s why subscribers_count (119) is reported separately as real subscribers. The vibe-kanban npm registry entry (created June 20, 2025, 198 versions, latest 0.1.44) describes the package as an “NPX wrapper for vibe-kanban and vibe-kanban-mcp”; downloads have dropped notably from their peak, consistent with the company’s closure.

Community reception

The main verifiable conversation is the Show HN 44533004 (July 11, 2025, 195 points, 132 comments, submitted by louiskw). It shows real enthusiasm and concrete objections in equal measure:

Praise:

• lharries: “Used this last week and it’s excellent — the same productivity-boost feeling as when I first used Cursor,” and asked for a hosted version to collaborate with their team.
• mrlesk (author of backlog.md, a similar project): “your team has done great work with Vibe Kanban. Glad to see more tools trying to solve human-agent interaction.”
• swyx noted that Louis “gave a long talk and coded extra features live at our Discord meetup” (a YouTube video linked in the thread).
• skeptrune connected to the team’s past: “I remember the original Bloop search engine.”

Criticism and objections:

• codingdave: “It’s not just chaos, it’s an unwanted product… products like this are built on the assumption that AI has matured enough… vibe coding is still [immature].”
• csomar: “Why does it need GitHub auth? It asks for unlimited private repo access. That’s a hard NO for me”; and after the team’s reply, “then they should have used a GitHub App instead of an OAuth App, since the App allows granular selection.”
• doritosfan84: “the permissions it asks for seem crazy… why does a kanban board need to see my code or my deploy keys?”; TeMPOraL clarified that “it’s not ‘a kanban board,’ it’s a coding-agent orchestrator shaped like a kanban board.”
• On the market premise, barbazoo and bwfan123 questioned whether “engineers spend most of their time planning, reviewing, and orchestrating,” and deepdarkforest said that when parallelizing, agents “collide editing files at the same time, I lose mental context, and they rewrite tests.”

Beyond the Show HN, a Hacker News search retrieved minor threads about derivative projects citing Vibe Kanban (all with very little traction): 46939622 (claude-vibekanban, 2 points), 49367532 (vibe-kanban-alternative with mem0, 1 point), 48370360 (Circus Chief, 4 points), 47638715 (Batty, 2 points), and 47019438 (Silo, 2 points). No launch announcement with a broad discussion distinct from the main Show HN was found, so no comment counts beyond what the sources show are inferred.

Vibe Kanban vs. similar projects

Project	Verifiable overlap	Verifiable difference
mrlesk/backlog.md	A kanban board for managing coding-agent work; Vibe Kanban’s author and backlog.md’s author cited each other in the thread.	backlog.md focuses on Markdown/ticket-based planning; Vibe Kanban adds agent workspaces, a live diff, preview, and PRs in the UI.
knowsuchagency/fulcrum (90★)	Combines agent orchestration with deployment; describes itself as a mashup of Vibe Kanban with other tools.	Positions itself as a fusion of several projects (Openclaw, Vibe Kanban, Vibetunnel, Dokploy), not a pure agent kanban.
automagik-dev/forge (89★)	Multi-agent kanban with MCP integration to orchestrate agents and experiment with isolated attempts.	Frames the experience as “Vibe Coding++” with emphasis on attempt experimentation; a different stack and brand.
GarrickZ2/grove (46★)	Manages git worktrees as tasks and runs multiple agents in isolated sessions.	A tmux-based TUI (terminal) with hook-based notifications, versus Vibe Kanban’s desktop + web app.
qwenode/vibe-kanban-promax (13★)	A direct fork of vibe-kanban.	Adds local-only mode and no login, aimed at lighter use after the sunset.

The most useful comparison isn’t by popularity: Vibe Kanban stands out as the visual agent-orchestration layer with the most stars in the set, but its practical advantage (parallel agents + review + PR in one UI) is already replicated by several smaller tools; its current disadvantage is maintenance uncertainty following bloop’s closure.

How to contribute

The README documents a specific contribution process:

• Talk to the team first: “we prefer that ideas and changes are raised with the core team first via GitHub Discussions or Discord, where we can discuss implementation details and alignment with the existing roadmap. Please don’t open PRs without first discussing your proposal with the team.”
• Feature requests → GitHub Discussions; bugs → repository issues.
• Local development: prerequisites are Rust (stable), Node.js (≥ 20), and pnpm (≥ 8), plus cargo install cargo-watch and cargo install sqlx-cli. Dependencies install with pnpm i and the dev server runs with pnpm run dev (starts backend and web app, copying an empty DB from dev_assets_seed).
• Web build: cd packages/local-web && pnpm run build. Building from source on macOS with ./local-build.sh, tested with cd npx-cli && node bin/cli.js.

Given the company’s closure, this flow is now oriented toward the community edition bloop announced as the next step; it’s worth checking Discussions/Discord for the current state of contribution acceptance.

Use cases

• Engineers who run several agents sequentially and lose time waiting: the documented direct value is parallelizing workspaces (one per agent/branch) and moving from “waiting 2-5 minutes per task” to batch-reviewing several diffs. Every workspace provides an isolated branch, terminal, and server.
• Teams that want a single point for review and delivery: the issue → workspace → diff with inline comments → PR (with an AI-generated description) → merge flow covers version-control bureaucracy within the same interface, with GitHub and Azure Repos integrations.
• Web app developers testing changes: the embedded browser with devtools, inspection mode, and device emulation lets you preview and debug the app without switching windows, with click-to-component to jump to source.
• People orchestrating with MCP: its own MCP server and the ability to add third-party MCP let an agent create tickets or access more tools within Vibe Kanban, useful for automating planning.
• Users looking for a local, self-sufficient path after the sunset: with data export, the announced local mode, and the “local-only / no login” fork ecosystem (e.g. vibe-kanban-promax), those who don’t want to depend on cloud services can keep the kanban + agents pattern without an account, taking on community maintenance.

Resources

• Repository: https://github.com/BloopAI/vibe-kanban
• Documentation: https://vibekanban.com/docs (LLM index: https://vibekanban.com/docs/llms.txt)
• Shutdown announcement: https://www.vibekanban.com/blog/shutdown
• Supported agents: https://vibekanban.com/docs/supported-coding-agents
• Self-hosting (Docker): https://vibekanban.com/docs/self-hosting/deploy-docker
• Vibe Kanban MCP server: https://vibekanban.com/docs/integrations/vibe-kanban-mcp-server
• Community: GitHub Discussions (https://github.com/BloopAI/vibe-kanban/discussions) and Discord (https://discord.gg/AC4nwVtJM3)
• Package registries: npm vibe-kanban (https://www.npmjs.com/package/vibe-kanban)
• Hacker News threads: Show HN 44533004 (195 pts, 132 comments); derivatives: 46939622, 49367532, 48370360, 47638715, 47019438
• Video (referenced in the thread): Louis Knight-Webb’s talk at swyx’s meetup (YouTube linked in thread 44533004, https://www.youtube.com/watch?v=NCksand7Iwo)

---

Note: this article draws on the README and documentation for Vibe Kanban, bloop’s shutdown announcement (April 10, 2026), the GitHub API, the npm registry, and Hacker News threads consulted on September 1, 2026. Figures change over time; the project has moved to community maintenance following the company’s closure.