Kandev: AI Kanban Board and Multi-Agent Orchestration with a Built-In Code Review Workspace
AI Kanban & Development Environment. Orchestrate multiple agents, review changes, open PRs. Multi-provider, self-hostable, no telemetry.
At a glance
- What is it?
- Kandev is an AGPL-3.0 Go binary that provides a kanban board for managing AI agent tasks in parallel, an integrated workspace with a code editor, terminal, git changes panel, and browser preview, and support for 20+ agent providers from Claude Code to GitHub Copilot. It runs locally or self-hosted, with no telemetry and no cloud lock-in.
- Who is it for?
- Kandev is a practical choice for developers who run multiple AI agents simultaneously and spend significant time reviewing their output in a terminal that was not built for code review. It is particularly well suited for teams that want a shared workflow definition and a consistent review process regardless of which agent each team member prefers.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What problem Kandev solves and who it is for
Terminal-based AI agents are effective at generating code, but reviewing the output in a terminal does not scale when multiple agents are running in parallel on different tasks. Switching between terminal sessions to check progress, navigating to changed files, and reviewing git diffs across several concurrent tasks creates context-switching overhead that reduces the value of running agents in parallel.
Kandev solves this by combining task management with an integrated review workspace. The README describes the core use case: organize work across kanban and pipeline views, execute multiple tasks in parallel with different agents, and review their output in one place where the file editor, file tree, terminal, git changes panel, browser preview, and embedded VS Code are all available at once.
The README describes the target user as a power user who wants deeper control over how AI agents work: customize workflows, agent profiles, runtimes, prompts, and review gates to match your process. Teams that have standardized on a review-before-merge process for agent-generated code, and want that process formalized in a shared workflow definition rather than enforced informally, are the primary audience.
Distribution: a single Go binary serving both the API and the web frontend
Kandev is distributed as a single native Go binary per supported platform. The compiled web frontend is embedded in that binary. The binary serves both the web UI and the API, so the server does not need Node.js, a separate web server, or a build step at runtime.
This distribution model has a concrete consequence for deployment: there is no npm or pip install step to start the server. You download the binary, run it, and the web interface is available. The binary is available through Homebrew on macOS, Scoop on Windows, as a direct release archive, and as a Docker image.
For Docker deployment, the image is at ghcr.io/kdlbs/kandev. The Dockerfile is a single-stage build that copies prebuilt platform binaries from the release archive into a Debian bookworm-slim base with nginx, Node.js (for agent CLI installs), Azure CLI, and ffmpeg. Starting with Docker:
docker run -p 38429:38429 -v kandev-data:/data ghcr.io/kdlbs/kandev:latestThe npm/npx package adds a Node.js platform selector, but Node.js is only required for the npx launch path, not by the application server itself.
Supported agents and runtime flexibility
The README lists more than 20 supported AI agents: Claude Code, Codex, GitHub Copilot, Gemini CLI, Amp, Auggie, OpenCode, Cursor, Devin, Qwen, Factory Droid, iFlow, Kilocode, Pi, Kimi, AWS Kiro, Qoder, Trae, Oh My Pi, Grok, Hermes, and Antigravity.
Each agent runs in a configurable runtime. The options are local processes, isolated Docker containers, remote servers via SSH, or cloud executors like sprites.dev. Runtime profiles, secrets, custom prompts, utility agents, and resource metrics are configurable from the Settings panel.
Git worktrees provide workspace isolation for parallel tasks. When multiple agents are running on different tasks in the same repository, each task gets its own worktree, preventing concurrent agents from modifying the same branch simultaneously. Multi-repository tasks span a single task across multiple repositories, with one worktree per repository, per-repository branches, and per-repository PRs visible in a single Changes panel.
The supported agent list is a feature, but it is also a maintenance surface. Each agent integration requires tracking changes in the agent's CLI and authentication model. The README notes that the agent table includes the package or command needed for each agent, which implies that some agents require separate installations outside Kandev.
Agentic workflows, automations, and sub-tasks
Beyond parallel task management, Kandev supports multi-step pipelines that route different steps to different agents. The README gives an example: Claude Code Opus for planning, GitHub Copilot Sonnet for implementation, and Codex GPT 5.4 for code review. Workflow definitions are portable YAML that can be exported, imported, and shared across team members or Kandev installations.
Automations trigger agent tasks on schedules or webhooks, with configurable run destinations, context, and concurrency. This enables recurring tasks such as scheduled code reviews or automated responses to repository events.
Agents can create sub-tasks: tasks that resume from a parent task's session. The README describes this as useful for splitting a task that has grown too large, or for producing several pull requests from the same starting point. Sub-tasks appear as children of the parent task in the kanban view.
The task-agent MCP gives agents running inside Kandev the ability to create sub-tasks, target sibling repositories, attach extra branches for multiple PRs, message other tasks, read conversation history, and inspect related tasks. External MCP access lets tools outside Kandev manage tasks over streamable HTTP or SSE.
The AGPL-3.0 license and what it means for commercial use
Kandev is released under AGPL-3.0. The AGPL adds a network use provision on top of the standard GPL: if you run a modified version of Kandev as a network service, you must make the modified source code available to the users of that service. For teams using Kandev internally without modifications, AGPL is equivalent to GPL in practice.
For organizations that want to build a commercial product on top of Kandev, or that want to modify it and offer it as a service without releasing modifications, AGPL is a hard constraint. The project is open source and self-hostable, but the license does not permit proprietary forks.
Kandev has GitHub releases with recent versions including v0.96.0, v0.95.1, and v0.95.0, all released in September 2026. The last push was on 2026-09-25. The changelog at CHANGELOG.md documents changes between versions. The release cadence indicates active development.
Limitations: complexity, Office mode not yet released, and plugin ecosystem
Kandev is a multi-component system. The backend is Go, the frontend is React compiled into the binary, and the deployment options include Docker with nginx, gh for GitHub integration, Azure CLI for Azure DevOps, and Node.js for agent CLI installs. Setting it up correctly requires understanding which of these optional dependencies matter for your specific agent and integration combination.
Office mode, described in the README as a feature-flagged autonomy layer for persistent agent teams with roles, permissions, dashboards, inbox and approvals, routines, memory, and cost tracking, is listed as in progress. The README explicitly states it will be documented as a supported feature after it is live, and that the current description is a directional statement rather than available functionality.
The plugin marketplace is available but the ecosystem is small. The README lists MCP Explorer and a Bitbucket plugin as example plugins. The Bitbucket integration is available through a separate repository at kdlbs/kandev-plugin-bitbucket rather than built in. Teams that need Bitbucket support must install it separately.
Kandev compared to OpenHands
OpenHands (formerly OpenDevin) is a Python-based AI coding agent platform that focuses on giving a single agent a complete development environment: a browser, a code editor, and a shell. It operates as a single-agent system per session, with the agent handling most decisions autonomously.
Kandev approaches the same problem from a different angle. Its focus is on the human review step and on running many agents in parallel under human supervision. It emphasizes configurable review gates, shared workflow definitions, and an integrated code review workspace rather than giving the agent maximum autonomy. Where OpenHands is designed for users who want the agent to operate independently on a task, Kandev is designed for users who want to manage many agent tasks and review their output before any code is merged.
The two tools address different points in the same workflow. Teams that already use an agent like Claude Code or Codex and want a better way to manage multiple concurrent tasks and review the results will find Kandev more relevant than OpenHands. Teams that want a single integrated agent environment to run one task at a time will find OpenHands a closer fit.
Editorial conclusion
Kandev is a practical choice for developers who run multiple AI agents simultaneously and spend significant time reviewing their output in a terminal that was not built for code review. It is particularly well suited for teams that want a shared workflow definition and a consistent review process regardless of which agent each team member prefers. The AGPL-3.0 license is a real constraint for commercial use: any network-deployed service that modifies Kandev must release those modifications. Before adopting it, verify that the agent you use is in the supported list and that its runtime configuration matches the version of Kandev you are deploying.
Frequently asked questions
How does Kandev isolate parallel agent tasks from each other?
Kandev uses git worktrees to give each task its own isolated working copy of the repository. This prevents concurrent agents from writing to the same branch simultaneously. Multi-repository tasks get one worktree per repository.
What MCP capabilities does Kandev expose to agents running inside it?
The task-agent MCP lets agents create sub-tasks, target sibling repositories, attach extra branches for multiple PRs, message other tasks, read conversation history, and inspect related tasks. External MCP access allows tools outside Kandev to manage tasks over streamable HTTP or SSE.
Is Kandev available as a self-hosted option without using a cloud service?
Yes. Kandev runs as a local process or in a self-hosted Docker container with no external cloud dependency. The README describes options including local process, Docker, remote servers via SSH, and cloud executors. The mobile remote-access guide covers connecting through Tailscale, Cloudflare Tunnel, or a private VPN.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kdlbs-kandev)