Run everything on your runners | kanman documentation

With a self-hosted runner, the coding work of a run happens in your network. A few steps around the run still happen in kanman’s cloud by default: drafting stories from a requirement, the independent review, writing acceptance specs, the maintenance scans, and repository actions such as opening the pull request or posting the evidence pack.

Run everything on our runners moves all of these onto your runners as well. kanman’s cloud then never calls a model provider and never reads or writes one of your repositories for the workspace. Neither source code nor model traffic passes through kanman.

Turn it on

Start at least one self-hosted runner and give it the model access and the code host token described below.
Open Settings > Runners (/settings/runners).
Turn on Run everything on our runners. Owners and admins can change it; the change is recorded in the audit log (export format).

Turning it on also switches the workspace to self-hosted runs, so the kanman Cloud switch under Settings > AI providers > Advanced stays off until you turn this setting off again.

Screenshot coming soon Settings, Runners tab with the switch Run everything on our runners turned on and the list of what runs where

What your runners need

Variable	Meaning
`KANMAN_API_KEY`	The workspace API token, as for every runner
Model access	The provider variables of your account, for example Amazon Bedrock, Google Vertex AI, Microsoft Foundry, Azure OpenAI, or an Anthropic or OpenAI key. See Model access on self-hosted runners. Teams that use their own key in kanman get that key for each step instead.
`GITHUB_TOKEN`	Token for GitHub or GitHub Enterprise repositories (`GITHUB_API_URL` for GitHub Enterprise)
`GITLAB_TOKEN`	Token for gitlab.com or your self-managed GitLab (`GITLAB_API_URL`, for example `https://gitlab.example.com/api/v4`)
`RUNNER_JOBS`	Optional. Comma-separated list of the step kinds this runner takes, for example to keep acceptance checks on one larger host. Default: all it can do.
`RUNNER_JOB_CONCURRENCY`	Optional. How many short steps (drafts, reviews, repository actions) the runner works on next to its runs. Default `2`.

The runner keeps the tokens to itself. kanman’s cloud does not need, and in this mode does not use, a token for your code host.

What runs where

Step	Where it runs
Coding runs, local verification, push and the pull or merge request	Your runner
Acceptance checks (spec run, fresh environment, clean checkout)	Your runner
Writing the acceptance spec and the independent reviewer	Your runner, with your model access. The runner reads the diff from your repository itself.
Drafting stories in Intake, and drafts from chat	Your runner, with your model access
Comments with the evidence pack, commit statuses, CI results, merges	Your runner, with its code host token
Acceptance manifest check and the starter pull request	Your runner
Maintenance scans, the read-only reviewers, strategy proposals	Your runner
Grouping review notes into conventions	Your runner
Team context from links and repositories, and answers from team context	Your runner
Log reads for incidents (Kubernetes and Loki)	Your runner
Board, policies, decisions, the audit log, run status, reports	kanman’s cloud

Exactly what reaches kanman’s cloud

kanman’s cloud stores only the orchestration state and what your runners send back:

the stories you write or approve (title, description, acceptance criteria, Demonstrate block), decisions, policies and settings,
run status, progress lines and the first line of each of the agent’s status messages (no tool inputs or outputs, no transcript of the agent’s work), cost and the evidence pack: test and check results, the reviewer’s verdict per criterion with file and line references, links to the pull request and to CI,
the names and line counts of changed files and the commit list of a run (no file contents),
the text a runner sends back for kanman’s own steps: drafted stories, the acceptance spec it wrote, the reviewer’s verdict, maintenance findings, strategy proposals and answers,
the audit log, including one entry for each step a runner completed (the step, the runner and the result).

To build the prompts for these steps, kanman sends your runner what it already stores (for example a story and its acceptance criteria) and the names of the files or refs to read. The runner adds the repository content itself. Code never travels to kanman, and kanman never calls a model provider for the workspace.

When no runner is online

Work waits. Nothing falls back to kanman’s cloud.

The team page shows Waiting for a runner with the number of waiting steps and a link to Settings > Runners.
A requirement sent to Intake shows that it waits for your runner. As soon as a runner answers, the draft opens on its own.
A run whose review waits for the runner is parked with Waiting for your runner; it continues when the runner answers, without using up an attempt.

Limits

Issue sync with GitHub Issues or GitLab Issues pauses in this mode, because the issues live on your code host. Use Jira or kanman’s own board as the tracker.
Team context from Confluence, Notion and uploaded files needs credentials or files that only kanman holds, so a runner cannot index them; links and repositories work.
Incident log reads from Datadog, CloudWatch and Sentry are not available on the runner yet; Kubernetes and Loki work.
Repository actions on hosts other than GitHub and GitLab are not supported in this mode yet.