One task across repositories
A change to your frontend might need an API change too. Keep both on one card, along with any shared libraries. One architect plans the work across repositories; each gets its own coding agent and working copy.
Describe what you want to change, then let the agents get to work. They plan, code, test and review it. Follow along and answer questions from your browser or phone. Nothing gets merged until you say so. Kanship runs on your own server.
A 30-second tour with music and no narration. The opening title reads: your AI engineering team, on a kanban board. Plan: add a task to the board. Build: agents for each repository plan and write the code, with a verifier and reviewer checking their work. Sandbox: each session runs in a temporary KVM microVM with root access. Host credentials stay outside it. Ask: agents send you questions that you can answer on the board or your phone. Test: a tester starts the app, runs the tests and attaches screenshots. Merge: check the changes and merge with one click. You can undo the merge from the board. The final scene lists live sessions, costs and budgets, epics, project knowledge, model choices, notifications, chat-to-task and passkeys.
BUILT WITH KANSHIP
We use Kanship for our own development. Its agents write most of our commits, including the ones behind this website and the tour above.
feat(site): add the 30-second tour and redesign the websitefeat(fleet): require KVM for agent hostsfeat: expose task attachments to running agentsfeat(brand): people read Kanship, with the Sail K logofeat(extensions): add pluggable built-in extensions and GitLab CIWHY KANSHIP
If you use several coding agents, you know the routine: copy context between chats, check who’s finished, find the diff. Kanship keeps that work together on a task card.
A change to your frontend might need an API change too. Keep both on one card, along with any shared libraries. One architect plans the work across repositories; each gets its own coding agent and working copy.
If an agent needs your input, it asks and waits. Pick an answer or write your own, from the board or your phone. Your answer stays with the task for the next agents.
Should the CSV include archived reports?
Only active reports Include archived too Answered — agent resumedEach agent gets a temporary KVM microVM with root access to install the tools it needs. Your SSH keys and git credentials stay on the host. The host handles git pushes.
agent@vm:~$ sudo apt install ffmpeg
root inside; gone with the VM
agent@vm:~$ cat ~/.ssh/id_ed25519
no such file: keys stay out
With testing enabled, a tester starts your app, runs the suite and attaches screenshots before review. If a test fails, the coding agent gets the results and tries again.
$ docker compose up -d
✓ api ✓ web
$ npm run e2e
✓ exports reports as CSV 0.8s
✓ skips archived reports 0.4s
✓ export button is accessible 0.3s
3 passed (1.5s)
Read each repository’s diff in Kanship. When you’re happy with the changes, merge into your target branch from the board. Need to undo it? You can do that there too.
- Results.Json(q.All())
+ Csv.From(q.Active())
Follow each agent’s session as it works.
Track spending per task and set a budget to stop work at your limit.
Split a large change into tasks that run in order on one branch.
One agent plans, builds and tests a small change.
Agents search your docs, notes and past tasks.
Talk through an idea with a model, then turn the chat into a task.
Find questions and failed tasks in one place, with optional phone alerts.
Sign in with a passkey or scan a login code. End sessions when you need to.
HOW IT WORKS
Move a card to Todo and the agents take it from there. You can watch their progress, answer questions or stop the task at any point.
Write what you want done, attach anything the agents should see and pick the repositories.
Concept → TodoAn architect plans the work for each repository. A verifier checks those plans before anyone starts coding.
Architect + verifierEach coding agent works in its own microVM and commits to a work branch. They share progress and ask you if they need a decision.
ImplementersIf testing is enabled, a tester runs your app and test suite. If something fails, it sends the results and screenshots back for a fix.
TesterReviewers check the diff and either approve it or send it back with feedback.
ReviewersRead the summary and diff, then merge from the board. If you’ve added a GitHub or GitLab token, approval also opens a pull or merge request.
Ready to mergeFor smaller changes, use a solo task. One agent plans, codes and tests it. For larger changes, use an epic: a series of tasks that build on each other.
MOBILE + PUSH NOTIFICATIONS
You don’t have to stay at your desk. Add Kanship to your phone or tablet’s home screen to check tasks and answer questions.
Open your Kanship address in a supported browser and install the web app. There’s no app store download.
Get an alert for questions, stopped tasks, budget limits and work ready to merge, even when the board is closed.
Tap the notification to open the task. You can answer the question or check the finished work right there.
In your Kanship instance, open the bell and choose Enable push on each device.
Mobile setup and requirementsAdd email preferences · Implementer, api
SELF-HOSTING
The installer sets up Kanship and its services with HTTPS using public Docker images. You don’t need to build from source or log in to a registry. Once it’s running, add your agent hosts from the app.
80 for HTTP, 443 for HTTPS, and 5671 for encrypted AMQP. Open them in your cloud firewall./dev/kvm. Use a physical server or a VM with nested virtualization enabled. It must reach your hostname on ports 443 and 5671.There’s no fixed CPU, memory or disk minimum. What you need depends on your builds and how many agents you run at once.
Add this server or another on the Servers page. Each agent session runs in a microVM.
Agents need internet access. Kanship runs on your server, but agents still connect to your configured AI providers and git remotes.
Every agent host needs KVM. Both coding and testing agents run in microVMs. Their machines need /dev/kvm, on a physical server or a VM with nested virtualization. A server that only runs the Kanship app doesn’t need KVM.
INSTALLATION
Start on the Linux server where you want to host the app. Then add an agent host and connect your project.
Open a terminal on your server. Pick Stable for the regular release, or Develop to try changes that aren’t in a stable release yet. The command downloads the current image, extracts its installer and runs it with sudo. Only run it on a server you manage.
docker run --rm --pull=always --entrypoint cat docker.kanship.com/api:latest \
/app/deploy/install.sh | sudo bash
docker run --rm --pull=always --entrypoint cat docker.kanship.com/api:develop \
/app/deploy/install.sh | sudo bash -s -- --channel develop
Before making changes, the installer checks the server’s architecture, Docker, ports and DNS. It then asks you to choose passkey or password sign-in. It stores configuration and secrets in /opt/kanship.
Open Servers in Kanship, choose + Add server on a pool and run its command as root on a machine with KVM. You can use the same server or a different one. The machine connects to Kanship by itself, and Kanship sets it up and keeps it updated. Tasks can start once an agent host is online.
Run the architects, verifiers, implementers and reviewers for your tasks.
Brings up your stack and runs the suite before review, one test run at a time.
.kanship/test-instructions.md to each repository with the commands that build, start and test it, or let the first tester write it. Testing is on for new projects.PRICING
Both run on your own server. With Pro, you pay for each person who signs in.
€0
No account needed
Everything in Kanship, for one project and one person.
€29 per seat a month
Including tax Billed monthly
€290 per seat a year
Including tax €24.17 a month, billed yearly
All features, with as many projects as you need.
AI usage is billed separately by your providers. After subscribing, link your installation under Settings → Global → License in Kanship.
FAQ
Costs, requirements and what happens to your code.
For one project and one person, it’s free. You get every feature and don’t need an account. Pro removes the limits and costs €29 per person a month or €290 a year, including tax. Everyone who signs in needs a seat, including you. AI usage is billed separately by your providers.
No, keep using your editor. Kanship is for the tasks you hand off to coding agents. Their changes are ordinary git commits you can work with as usual.
Claude Code and OpenCode. Pick a model for each role in global or project settings, or override it for a single task. Kanship picks the coding tool that supports that model. Bring your own provider credentials; model usage is billed separately.
Open your Kanship HTTPS address. On Android, choose Install or Add to Home Screen in a supported browser. On iPhone or iPad, open it in Safari and choose Share → Add to Home Screen. Then launch Kanship from the new icon.
For notifications, open the bell, choose Enable push and allow notifications when asked. Repeat on each device. On iPhone and iPad, notifications require the installed web app and iOS or iPadOS 16.4 or newer.
Kanship must use HTTPS, and your browser must support Web Push. Enable notifications on each browser or device where you want them. If you blocked them before, allow them in your browser’s site settings.
The server’s API container needs outbound HTTPS access to the browser vendors’ push services. Set PUSH_SUBJECT to a real mailto: contact address; Apple rejects placeholders. Kanship generates its push keys automatically. You still need a connection to your server to view and answer tasks.
Not necessarily. You host the app, database and workers, but agents send context to your AI providers and connect to your git remotes. Check your providers’ data policies before using private code.
KVM runs the temporary virtual machine used for each agent session. The agent has root access inside it and can see the task’s working copy. The host’s home directory, git credentials and agent service secrets stay outside the VM. The host pushes commits after the session ends. Each agent host needs /dev/kvm for this setup.
No. Approved work waits in Ready for Merge until you choose to merge it. You can stop a running task, and agents can pause to ask you questions. Merges are normal git merge commits, with an undo option on the board.
You need a dedicated deploy key or HTTPS credentials with git write access. API tokens are optional: they let Kanship open GitHub pull requests or GitLab merge requests after approval. The optional GitLab CI extension also needs a token. You can merge from the board without an API token. Never mount your personal SSH directory into agent containers.
Yes, if it has KVM. Install Kanship, then run a pool’s command from the Servers page on the same machine. Add a tester host there too for automated tests.
The machine must be able to connect to its own public hostname on ports 443 and 5671. If it sits behind a router, the network needs to support this, often called hairpin NAT.
The coding agent gets the results or feedback and tries again. If the test environment itself is broken, the task waits in Testing for you to fix it and retry. You’ll see tasks that need your help on the board and in notifications.
GET STARTED
Install Kanship, add an agent host, connect a repository and give your agents something to work on.