Board Planner

Board Planner

One board. Your team works it. So do your agents.

A Kanban board, sprints and a dashboard small teams can actually run — plus an MCP server and a REST API, so coding agents pick up the same tasks under the same rules as everybody else.

---

Most trackers bolt automation on: a bot posts a comment, a script moves a card, and the real state of the work lives somewhere the board cannot see. Board Planner starts from the other end. The board, the REST API and the MCP server are three doors into one model, with the same permission checks behind each. An agent moving a task to *In Review* passes the same status rules as a person dragging the card, and leaves the same trail in the same history.

Cloud or self-hosted

In the cloud, signing up puts a new organisation on its own subdomain of board-planner.com. It starts with a 30-day Pro trial, no card, and then becomes Free — up to 10 members, unlimited projects and tasks, the REST API, the MCP server, and workers and agents on one machine — or Pro, which adds more members, any number of machines, a monthly AI allowance on our key and Coda sync. Agents, workers and API tokens never count as members.

On your own server, docker compose up gives you one organisation of your own. The Community edition is AGPL-3.0, has no member or machine limit and runs the AI features on your own key; Pro self-hosted adds Coda sync and e-mail support.

AI on your own key is free on every plan, and nothing that ships in Free will move to Pro. Prices and the full comparison are on board-planner.com/pricing.

Handing work to a machine

Plenty of tools can now make a machine write code. Board Planner is about everything around it: who proposed the work, who approved it, what the machine was allowed to touch, what had to pass before anything landed, and where it stops and gives the work back.

Two agents, at the two ends of that arc: a PM agent that proposes and writes things down, and an execution worker that takes an approved task and does it. Neither decides anything you did not let it decide.

A PM agent that brings you the decision

The PM agent is a project manager that lives in the project. It reads the board, notices what is stuck, duplicated or missing, and brings you the decision rather than filing a pile of tickets nobody asked for. It is good at the work nobody enjoys: writing the acceptance criteria a task was created without, finding the duplicate, saying where a sprint actually stands.

In that screenshot, the badge under the reply is the action — the message and the write are one record, so you can see a reply also changed ORB-9 rather than merely talking about it. And it left the task where it was, because it was told to. Board reviews run with change_status and create_task withheld, so the autonomous path can tell you something is wrong without quietly reorganising your board overnight.

It is off by default, per project, and metered rather than trusted: every call is counted in tokens per organisation, autonomous turns as well as yours, against an allowance an instance can set, and an instance administrator can lock it off for a project in a way project settings cannot override. Without OPENROUTER_API_KEY the pages say so and the feature stays inert; AI Assist runs on the same key.

📖 PM agent · Autonomous board reviews

You hand it over the way you would hand it to a person

Assign the task, name an agent, drag it into the column you approve from. That pair is the hand-over — nothing runs on a task that names no agent, and there is no falling back to a project default. A task somebody else assigned to you is a proposal, not a job queued on your machine.

An agent is a list of steps and gates

An agent is an ordered list of blocks, and there are exactly two kinds:

A step cannot refuse and a gate cannot write, so every block that could stop the run is a gate, and you can see all of them at a glance.

Each step is its own model session. Two steps in one agent share the task and the worktree and nothing else, which is why *analyse, then implement* is different from asking one model to do both: the second step reads what the first wrote, not what it was thinking.

Merging is a step, not a switch. There is no "auto-merge" checkbox and no rule that ties it to a review setting. An agent merges because its sequence ends with a Merge block; leave it out and the run stops at the pull request.

Three agents ship with it: Default, With security review and Merges its own work. A project that never opens the editor runs Default.

The machine is not trusted, by construction

This is the part that took the longest to get right, and it is why the hand-over is safe to use on a real repository:

The whole run reports onto the task as it happens, so the task's comments are the run log — branch, edits, which gate said no, how much model quota is left. No side channel, no CI tab.

📖 The full story: Agents · Execution workers · worker/README.md

The rest of the board

It's a board first

Columns you name, in an order you choose. Each one is mapped to a role automation understands (backlog, approved, active, review, blocked, done), so renaming *Up next* to *Ready* breaks nothing. Any column with the review role is a stop sign for automation, where work waits for a person. Drag-and-drop board, list view, sprints, dependencies and subtasks, recurring tasks, and ⌘K search across every task from anywhere in the app.

It follows your system theme, and the whole app is built for both:

A task holds everything the work needs

Acceptance criteria that tick off one by one, dependencies, the pull request that closes it, custom fields you define per project, every comment and every change since it was created. Name a branch bp-8/dark-mode and the pull request finds its task on its own.

Your agents work the same board

Forty-six MCP tools over HTTP put the board in your terminal, so Claude Code reads the backlog, claims a task and moves it — through the same permissions a teammate gets. API tokens can be scoped to specific projects, and the scope is enforced centrally, so it holds for REST and MCP alike.

Enough to answer the Monday question

How you are doing, what is piling up, and whether you are finishing as fast as you are starting. Six charts, no spreadsheet.

The rest

Notifications in-app, by email, or to Slack and Discord — per user, per project, per event. Project audit trail. Webhooks, signed. GitHub and GitLab PR linking. Works on a phone.

Quick start

You need Docker with Compose 2.24 or newer — older Compose rejects the file's env_file entry even without a .env. Nothing else: no Node, no MongoDB, not even a clone.

curl -fsSLO https://raw.githubusercontent.com/rafalpodles/board-planner/main/docker-compose.yml

docker compose up -d

That runs the published image, ghcr.io/rafalpodles/board-planner, built for linux/amd64 and linux/arm64 on every release from 1.1.0 on — 1.0.x predates it and has no image. :latest is the newest release; pin one with BOARD_PLANNER_VERSION=1.2.3 in a .env next to the compose file. To upgrade, docker compose pull && docker compose up -d.

The compose file on main needs an image of 1.1.2 or later: it passes COOKIE_ALLOW_INSECURE=auto