Hosting and data residency
Where kanman runs, where your data is stored, and how to keep code execution on your own infrastructure.
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 switch is Kanman Cloud under Settings > AI providers, Advanced; Settings > Runners (/settings/runners) shows where runs execute 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, pilots, 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.
Coming in a later release
Repository tokens that are scoped to one repository and expire with the run. Today a run uses the token of your git connection.
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.
See Run the self-hosted runner for setup.
Coming in a later release
Acceptance specs and the clean-room verification on your own runner. Today they run in kanman cloud only.
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 |
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 the coding agent and the reviewer send to their model provider while they work. Which provider that is depends on your executor and on whether you use your own key. See What model providers see.
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.
Coming in a later release
Your own key for the independent reviewer and for writing acceptance specs. Today these two use kanman’s model provider accounts, also for teams that bring their own key.
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.
Related pages
Last updated: January 1, 0001
Open kanman