For admins and leads
Set up teams, members, limits, budgets, plans and your own runners.
These pages are for the people who set kanman up and keep it running for their teams: workspace owners and admins, and team leads. You will find how to create a team, invite people, choose what kanman may do and spend, and run everything on your own infrastructure if you need to.
A good order for a new workspace:
- Set up a team: tracker, repositories, model access, a dry run.
- Workspace, members and roles: invite your colleagues.
- Connect your tools: chat, alerts and wikis.
- Limits and rules and Budgets and cost: what holds for every team, and what you choose.
- Roll out to a second team once the first one runs well.
If your company needs everything to run inside its own network, read Run the self-hosted runner and Run everything on your runners first.
In this section
Set up a team
The team setup, step by step: pick your tracker, name the project and repositories, choose an executor, personalize the team and check the column mapping and a dry run.
Use kanman without a tracker
Run an AI team on its own kanman board: no Jira, GitHub or GitLab connection, stories from Intake, and a tracker you can connect later.
Teams
A team is one AI team: one tracker project, one or more repositories, its own limits, and a board that mirrors your tracker.
Limits and rules
The limits that hold for every team, whatever the model says: which repositories and branches kanman may write, how changes merge, what helpers can reach, and one daily budget.
Budgets and cost
One daily budget per team, budgets per person and goal, what the work cost, and two ways to pay for model usage.
Workspace, members and roles
How workspaces, teams and members fit together, what each role may do, and how to invite and remove people.
Plans and billing
kanman's plans (Local, Starter and Team), billed per AI team, volume pricing for Team, the Enterprise agreement, the 14-day Team trial, and compute on your own key or passed through at cost plus 15 percent.
Roll out to a second team
Take what worked for the first team to the next one: reuse connections and settings, and keep each team's rules its own.
Give kanman your team's toolchain
Define once which image, variables, secrets and setup your repositories need. kanman's coding work and bulk changes run in it, on your runners and in kanman Cloud.
Run the self-hosted runner
Run kanman's code work on your own infrastructure with a Docker image that connects outbound only, without opening ports or sharing database credentials.
Run everything on your runners
Keep all model traffic and every repository action inside your network: kanman's cloud keeps the board, decisions and the audit log, and your self-hosted runners do the rest.
Model access on self-hosted runners
Let the coding tool on your self-hosted runner use your own cloud account for models, such as Amazon Bedrock, Google Vertex AI or Microsoft Foundry, so model keys never pass through kanman.
GitLab behind a VPN or firewall
Use kanman with a self-managed GitLab that is only reachable inside your company network: a runner inside the network does all repository work and talks to kanman over outbound HTTPS only.