Self-hosted service
kdlbs/kandev avatar
kdlbs/kandev

Kandev: A Self-Hosted Kanban Control Plane for AI Coding Agents

AI Kanban & Development Environment. Orchestrate multiple agents, review changes, open PRs. Multi-provider, self-hostable, no telemetry.

788 stars116 forksGoAGPL-3.0

At a glance

What is it?
Kandev is an open-source, AGPL-3.0 Go application that orchestrates multiple AI coding agents across a kanban board, with review gates, parallel execution, and no telemetry. It suits power users who want to control agent workflows without cloud lock-in, but requires real infrastructure to run well.
Who is it for?
Adopt Kandev if you are a developer or small team that already uses agent CLIs like Claude Code or Codex, needs a review gate before merging, and wants to keep everything on your own infrastructure without telemetry. Do not adopt it if you want a managed SaaS or if your team lacks the patience to configure agent packages and runtimes; the README makes clear this is for power users.
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 3 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 14, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What Kandev Solves and Who It Is For

Kandev tackles a specific pain point: running AI coding agents in a terminal TUI works for a single session, but does not scale when you need to review and iterate on multiple changes. The README says it plainly: "Terminal agent TUIs are great for running agents, but reviewing and iterating on changes there doesn't scale." Kandev is a control plane that organizes agent work on a kanban board, runs several agents in parallel, and gives you an integrated workspace to review their output. The target user is a power user who wants deeper control over agent workflows, prompts, runtimes, and review gates. It is not aimed at casual users or non-developers. The vision statement emphasizes human control: define tasks, build workflows with gates, review every change, and decide what ships. This is a tool for developers who trust agents to write code but not to merge it.

The Architecture: Kanban, Worktrees, and Multi-Repo Tasks

The repository layout and README reveal a client-server architecture, but the details are thin. What is clear is the data flow: you create tasks on a kanban board, assign agents from any supported provider, and Kandev executes them in parallel. A key mechanism is workspace isolation via git worktrees, which prevents concurrent agents from conflicting with each other. For multi-repository tasks, Kandev creates one worktree per repo, with per-repo branches and per-repo PRs, and groups the changes in the review dialog. This is a practical design: agents can work on a shared codebase without stepping on each other. The integrated workspace includes a terminal, a code editor with LSP, a git changes panel, an embedded vscode, and chat, all in one IDE-like view. The architecture document is linked but not included in the material, so I cannot confirm the internal communication between the server and agents. What is visible is that Kandev acts as an orchestrator, not a sandbox: it runs agents as local processes, in Docker containers, on remote servers via SSH, or in cloud executors like sprites.dev.

Getting It Running: What the README Shows

The README does not include a quickstart command, which is a gap for an installation article. What it does provide is a list of supported agent packages and commands, which is the real setup burden. For example, Claude Code uses `@agentclientprotocol/claude-agent-acp`, Codex uses `@agentclientprotocol/codex-acp`, and GitHub Copilot uses `@github/copilot`. Some agents require separate installs: Cursor requires Cursor Pro, Devin requires installing the Devin CLI, and Kimi requires installing the Kimi CLI from Moonshot AI. The README points to a run-as-a-service doc and a debug-logs doc, but those are not in the material. The workflow portability feature exports and imports workflows as YAML, so you can share a workflow across workspaces. The configuration surface includes executor profiles, secrets, custom prompts, utility agents, and resource metrics, all from Settings. Without a concrete install command, I cannot tell you how to start the server. The homepage is kandev.ai, but the README does not give a `go install` or a Docker command. If you want to try it, you will need to clone the repository and look for build instructions in the docs.

The Review-First Workflow and Gates

Kandev's core value proposition is the review gate. The vision statement says "Humans stay in control" and "Review every change, decide what ships." The workflow feature lets you mix agents per step: for example, Claude Code Opus designs a plan, GitHub Copilot Sonnet implements it, and Codex GPT 5.4 reviews the changes. This is a concrete mechanism: you define a pipeline with gates, and each step runs a different agent. The integrated workspace is where the review happens: you see the file tree, the terminal, the git changes, and a browser preview. The task-agent MCP lets agents create subtasks, target sibling repos, attach extra branches for multiple PRs, message other tasks, and read conversations. This is more than a kanban board; it is a coordination layer for agent teams. The review-first approach is a deliberate trade-off: it adds friction compared to letting agents push directly, but it addresses the trust problem that many teams have with AI-generated code. The README does not specify how review gates are enforced, so I cannot say whether they are mandatory or advisory.

A Genuine Limitation: Setup Complexity and Resource Saturation

The README itself admits a limitation: "Running multiple agents on a large codebase can quickly saturate a local machine." That is why the project pushes remote agents and a single control plane. But that means you need infrastructure: either Docker, SSH servers, or a cloud executor like sprites.dev. For a solo developer on a laptop, running several agents locally will hit CPU and memory limits fast. The setup complexity is another real barrier. Each agent has its own package and installation requirement, and some require paid plans like Cursor Pro. The README targets "power users," which is a polite way of saying that less experienced developers will struggle. There is also no mention of Windows support, so assume Linux or macOS. The AGPL-3.0 license is another constraint: if you modify Kandev and offer it as a network service, you must release your changes under the same license. That is a legal consideration, not a technical one, but it matters for companies that want to embed Kandev in a proprietary product.

Alternatives: Terminal TUIs vs. Cloud Orchestrators

The most direct alternative is what Kandev is trying to replace: running agent CLIs directly in a terminal TUI. Claude Code, Codex, and others have native interactive modes, and Kandev even offers a CLI passthrough to drop back into those raw TUIs. The difference is that a terminal TUI gives you no parallel orchestration, no kanban board, and no integrated review workspace. You run one agent at a time and review changes in a separate git client. Another alternative is a cloud-based agent platform, but the README explicitly distances Kandev from being tied to any cloud. The multi-provider support is the key differentiator: you can mix agents from different vendors in one workflow, which no single vendor's tool offers. There is also the plugin marketplace, including a Bitbucket plugin, which extends integration beyond the built-in GitHub, GitLab, Jira, Linear, Sentry, and Azure DevOps connectors. If you need a managed service with no setup, Kandev is not that; if you want a self-hosted control plane, it is a real option.

Maintenance, License, and Upgrade Cost

The project is active, with recent releases v0.91.0, v0.92.0, and v0.92.1 in August 2026. The release cadence suggests ongoing maintenance, but the README warns that Office mode, an autonomy layer with roles, permissions, and budgets, is still feature-flagged and not yet documented as supported. That means the project is evolving, and you should expect breaking changes between minor versions. The license is AGPL-3.0, which is strong copyleft. If you run Kandev as a network service and modify it, you must offer the source to users. That is a real cost for internal tooling if you plan to customize the server. The upgrade cost is not documented, but with a Go binary and YAML workflow exports, you can likely migrate workflows across versions. There is a roadmap doc and a contributing guide, but neither is in the material. The no-telemetry claim is a plus for privacy, but it also means the maintainers do not see how the software is used in the wild, which can slow bug detection. Verify the debug-logs doc if you need to troubleshoot.

Editorial conclusion

Adopt Kandev if you are a developer or small team that already uses agent CLIs like Claude Code or Codex, needs a review gate before merging, and wants to keep everything on your own infrastructure without telemetry. Do not adopt it if you want a managed SaaS or if your team lacks the patience to configure agent packages and runtimes; the README makes clear this is for power users. Before committing, verify that your chosen agents have ACP packages or CLI passthrough listed in the supported table, and test a single task end-to-end with your git provider. Kandev is a serious tool for a specific workflow, but it is not a plug-and-play product.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community notes

Community notes