Run everything on your runners

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.

Everything on ours (also called running everything on your 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.

Your own runners and this option are available from the Starter plan, and during the 14-day Team trial. See Plans and billing.

Turn it on

1. Start at least one self-hosted runner and give it the model access and the code host token described below.
2. Open Workspace settings > Runs and runners (/settings/runs).
3. Under Where runs execute, choose Everything on ours. kanman asks first: it names the work that moves to your runners and says that work waits while no runner is online. Confirm with Run everything on ours. Owners and admins can change it; the change is recorded in the audit log (export format).

The diagram Where things run on the same page then shows runs, checks, model calls, repository actions and chat replies on your network’s side. To go back, choose Our runners or kanman Cloud.

What your runners need

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.

Because kanman’s cloud does not list your code host’s projects in this mode, the team setup and Team settings > Repositories and tracker add a repository by its host URL and path, and your runner checks that it reaches it. For a GitLab that is only reachable inside your network, see GitLab behind a VPN or firewall.

Different models for coding and for the other steps

The runner can give kanman’s own steps another model than the coding agent, for example Claude for coding and your company’s OpenAI-compatible AI gateway for drafting, review and replies. Set the KANMAN_ASSISTANT_ variables on the runner; see Different models for coding and for the other steps.

A gateway that is reachable only inside your network can also be stored in kanman as the workspace’s provider key (Use a gateway or proxy instead in Workspace settings > Model access): in this mode only your runners call it, internal addresses are accepted, and Test connection runs on your runner. See Use your company’s AI gateway and AI gateways in the runner environment.

What runs where

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, the result and, for model steps, the tokens and the estimated model cost). A model call kanman makes in its cloud is recorded too (“Model called in kanman’s cloud”), so the log proves that none happened: ask kanman “Show me the runner jobs in the audit log” or “Show me the cloud model calls in the audit log” to open it filtered.

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.

• When you open kanman while your runner is offline and work waits for it, kanman says so first in your conversation: which runner, since when (in your time zone) and how many steps wait, for example “Your runner build-box-1 has been offline since Oct 3, 2026, 8:53 AM; 2 steps wait for it.” Once the runner is back, everything goes on by itself.
• When steps wait for a free runner, a small badge at the end of the team’s status line says Waiting for a runner. Hover over it (or tap it, or press Enter) to see how many steps wait and a link to Workspace settings > Runs and runners. When no runner is online, a notice in your conversation says so, with the same link.
• A requirement you send in the conversation shows that it waits for your runner. As soon as a runner answers, the drafts appear in the same message.
• 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

• Answers limited to Only people with access in the source use Confluence page permissions only when the source has a Confluence connection in kanman; SharePoint files shared with a group need a SharePoint connection in kanman for that check, otherwise only people the file is shared with directly get answers from it.
• Incident log reads from Datadog, CloudWatch and Sentry, and traces from Datadog APM, are not available on the runner yet; Kubernetes, Loki and Tempo work.
• Repository actions on hosts other than GitHub and GitLab are not supported in this mode yet.

Related pages

• GitLab behind a VPN or firewall
• Run the self-hosted runner
• Model access on self-hosted runners
• Hosting and data residency
• What model providers see