Hosting and data residency | kanman documentation

kanman is built for engineering teams in the EU that need to know where their code and data go. This page explains where kanman runs, what is stored where, and which parts you can move onto your own infrastructure.

Two ways to run

Every workspace chooses where runs execute: in kanman cloud (the default) or on your own runners. The choice is Where runs execute under Workspace settings > Runs and runners (/settings/runs): kanman Cloud, Our runners or Everything on ours. The diagram Where things run on the same page shows what kanman Cloud always keeps, which work executes where, and which runners are connected.

	kanman cloud	Self-hosted runner
Where code is checked out and executed	Isolated machines in Frankfurt, Germany	Your own machine, VM or cluster
Who operates the machines	kanman	You
Network direction	kanman starts a fresh machine per run	Your runner connects out to kanman; no inbound ports
Repository credentials	The token of your git connection, handed to git for the run only	The token of your git connection, used only inside your network
Good for	Getting started, the trial, teams without special requirements	Regulated environments, private networks, code that must not leave your infrastructure

Both modes use the same policy, the same outcome gate and the same audit log. Switching between them does not change how your team works.

kanman cloud

In cloud mode, each run gets its own machine in Frankfurt, Germany. The machine:

is created for one run and removed when the run ends,
clones only the repositories your team’s policy allows (allowed_repos),
receives a run token that only works for this run and stops working when the run ends,
never receives credentials for other workspaces or for kanman’s own systems.

Acceptance specs run in the same way: each check gets its own machine in Frankfurt, which is removed afterwards.

With the kanman GitHub App installed, a run works with short-lived repository tokens that are limited to the run’s one repository and expire after an hour. Without it, a run uses the token of your git connection, which is stored encrypted.

The kanman application (the web app, the API, the decision inbox and the audit log) is also hosted in the EU.

Self-hosted runner

The self-hosted runner is the same executor host that kanman cloud uses, packaged as a Docker image you run yourself. It pulls work over an outbound HTTPS connection, authenticated with a workspace API token (km_...). It needs no inbound ports and no database credentials.

With a self-hosted runner:

your repositories are cloned and the coding agent works only inside your network,
progress lines, the diff summary, commit information and a transcript of the agent’s work are sent to kanman for the run page and the evidence pack,
the acceptance specs and the clean-room verification run on your runner too, once it can reach Docker with Compose; your application and its test data stay in your network.

See Run the self-hosted runner for setup.

Everything on your runners

With Everything on ours (Workspace settings > Runs and runners), kanman’s cloud never calls a model provider and never reads or writes your repositories for the workspace. Drafting stories, the independent review, writing acceptance specs, maintenance scans and every repository action (pushes, pull requests, comments, commit statuses, CI reads, merges) run on your runners, with their own model access and code host tokens. kanman keeps the board, policies, decisions, the audit log and the run state, plus what your runners send back: story text, evidence summaries with file and line references, file names and line counts, and links. Tool inputs and outputs of the coding agent and its transcript stay on the runner. When no runner is online, work waits; nothing falls back to kanman’s cloud. See Run everything on your runners for exactly what reaches kanman.

What kanman stores

Data	Purpose	Where
Workspace, members and roles	Sign-in and access control	EU
Stories mirrored from your tracker (title, body, acceptance criteria, Demonstrate block)	Intake, readiness checks, runs	EU
Run records (stages, progress lines, cost, policy decisions)	Run page, team report	EU
Evidence packs and proof artifacts	Evidence for reviewers and auditors	EU
Audit log	Accountability and audit export	EU
Team conventions	Team memory for later runs	EU
Chat messages kanman receives and posts in your team’s places	Answers, intake from chat, What kanman said, audit log	EU
Team context: sources, the text read from them, and connection tokens (encrypted)	Answers with sources, see Team context and connectors	EU
Incidents: alerts, findings, the log and error lines kanman quotes, and the secrets and log access credentials of your signal sources (encrypted)	Incident page and timeline, weekly report, see Incidents and on-call	EU

kanman does not keep a copy of your repository. Code is checked out per run and discarded with the machine. Diffs, file references and short excerpts appear in the evidence pack and on the run page, because reviewers need them.

What leaves the EU

The only data that can leave the EU is what kanman sends to a model provider: the coding agent and the reviewer while they work, and the model calls for intake, acceptance specs and answers in chat. Which provider that is depends on your executor and on whether you use your own key. See What model providers see.

Messages kanman posts in Slack or Microsoft Teams are stored by those services, under your company’s agreement with them.

If you need model calls to stay in a specific region, use your own Azure OpenAI or Amazon Bedrock contract with a region of your choice. To make sure every model call of the workspace stays in the EU, switch on EU-only processing: kanman then refuses any route outside the EU before a request leaves.

Teams with their own key also run the independent reviewer and the writing of acceptance specs on that key. Teams on a self-hosted runner can keep model calls entirely in their own cloud account; see Model access on self-hosted runners.

Encryption

All connections use TLS.
Stored data is encrypted at rest.
API tokens are stored only as a hash, and your own model keys are stored encrypted. Neither is shown again after you create or save it.