Hatch manages your AI coding team for you
A kanban board worked by agents as much as by people. You write the tickets, answer the questions and merge the pull requests; an agent takes the rest, one ticket at a time, all night if you let it.
Run it
git clone https://github.com/yeetsoft/hatch.git hatch
cd hatch
docker compose up -dHatch ships.
Why Hatch
- You write the ticket. Hatch runs the team. Say what you want and what done looks like; the board breaks it down, works it, and brings back a pull request.
- A board, not a chat. Work is cards with keys, columns, comments and an audit trail, so what an agent did is exactly where a person would look for it in six months.
- Deterministic where it can be, agentic where it must be. Hatch itself decides what is next, who holds what, whether a branch is current and a build is green — in code, the same way every time. A session is spent only on the part that needs judgement: one ticket, one increment, then hand it back.
- People keep the gates. You decide what is specified, what ships and what is parked. Agents work the columns in between, and ask rather than guess when a decision is not theirs.
- Decades of software management, written down. Small increments, WIP limits, dependencies that say what lands in order, questions with pressable answers, and a work log beside what each session cost.
- Yours to run. One line brings the board up on your own machine, under your own domain, with your own data. Nothing in Hatch is true of one installation.
How it works
Hatch is a web app and a Postgres database, brought up with docker compose up -d. The board's
own code decides what an agent may pick up next, holds the claim while it works, and runs the merge train
that lands approved pull requests once their build is green.
hatch go-to-work asks the board for the next increment, prepares a clean checkout, and spends
one headless Claude Code session on it — the ticket as the brief, a playbook as the instructions. Hatch
watches the session's Claude usage, so a night's work stops before your plan's budget does.
The work lands in your repository on your forge — branches, pull requests, build checks and merges —
through git and gh; Hatch names no forge and needs no webhook. The board runs
anywhere Docker runs, under your own domain, with Google sign-in when you put the wall up; there is no
account to make and no service in the middle.
Docs
- Start here What Hatch is, and how to get a board running.
- Concepts The ideas the board is built on: tickets, columns, playbooks and gates.
- Running agents The runner, one increment, the loop, and what a session is told.
- Deploying and operating Putting Hatch behind your own domain, backing it up, upgrading it.
- Reference Every command, flag, variable and API route.