Hosting und Datenresidenz | kanman Dokumentation

kanman ist für Engineering-Teams in der EU gebaut, die wissen müssen, wohin ihr Code und ihre Daten gehen. Diese Seite erklärt, wo kanman läuft, was wo gespeichert wird und welche Teile du auf deine eigene Infrastruktur verlagern kannst.

Zwei Betriebsarten

Jeder Workspace legt fest, wo Runs ausgeführt werden: in der kanman Cloud (Standard) oder, mit dem Enterprise-Tarif, auf deinen eigenen Runnern. Die Wahl ist Wo Runs laufen unter Workspace-Einstellungen > Runs und Runner (/settings/runs): kanman Cloud, Unsere Runner oder Alles auf unseren. Das Schaubild Wo was läuft auf derselben Seite zeigt, was die kanman Cloud immer behält, welche Arbeit wo läuft und welche Runner verbunden sind.

	kanman Cloud	Self-hosted Runner
Wo Code ausgecheckt und ausgeführt wird	Isolierte Maschinen in Frankfurt am Main	Deine eigene Maschine, VM oder dein Cluster
Wer die Maschinen betreibt	kanman	Du
Netzwerkrichtung	kanman startet pro Run eine frische Maschine	Dein Runner verbindet sich ausgehend mit kanman, keine eingehenden Ports
Repository-Zugang	Das Token deiner Git-Verbindung, nur für den Run an git übergeben	Das Token deiner Git-Verbindung, nur innerhalb deines Netzes genutzt
Geeignet für	Einstieg, Testphase, Teams ohne besondere Vorgaben	Regulierte Umgebungen, private Netze, Code, der deine Infrastruktur nicht verlassen darf

Beide Betriebsarten nutzen dieselbe Richtlinie, dieselben Prüfungen vor einem Merge und dasselbe Audit-Log. Ein Wechsel ändert nichts an der Arbeitsweise deines Teams.

kanman Cloud

Im Cloud-Betrieb bekommt jeder Run eine eigene Maschine in Frankfurt am Main. Diese Maschine:

wird für einen Run erstellt und nach dessen Ende entfernt,
klont nur die Repositories, die die Richtlinie deines Teams erlaubt (allowed_repos),
erhält ein Run-Token, das nur für diesen Run gilt und mit dem Ende des Runs ungültig wird,
erhält nie Zugangsdaten für andere Workspaces oder für die Systeme von kanman selbst.

Ist die kanman GitHub App installiert, arbeitet ein Run mit kurzlebigen Repository-Tokens, die auf das eine Repository des Runs beschränkt sind und nach einer Stunde ablaufen. Ohne sie nutzt ein Run das Token deiner Git-Verbindung, das verschlüsselt gespeichert ist.

Die kanman-Anwendung (Web-App, API, deine Unterhaltungen mit kanman und Audit-Log) wird ebenfalls in der EU betrieben.

Self-hosted Runner

Der Self-hosted Runner ist derselbe Executor-Host, den die kanman Cloud nutzt, verpackt als Docker-Image, das du selbst betreibst. Er holt sich Arbeit über eine ausgehende HTTPS-Verbindung, authentifiziert mit einem Workspace-API-Token (km_...). Er braucht keine eingehenden Ports und keine Datenbank-Zugangsdaten.

Mit einem Self-hosted Runner:

werden deine Repositories nur innerhalb deines Netzes geklont, und das Coding-Werkzeug arbeitet nur dort,
gehen Fortschrittszeilen, die Diff-Zusammenfassung, Commit-Informationen und ein Protokoll der Arbeit des Coding-Werkzeugs an kanman, für die Run-Seite,

Die Einrichtung beschreibt Self-hosted Runner betreiben.

Alles auf deinen Runnern

Mit Alles auf unseren (Workspace-Einstellungen > Runs und Runner) ruft die kanman Cloud für den Workspace nie einen Modellanbieter auf und liest oder schreibt nie deine Repositories. Das Entwerfen von Stories, das unabhängige Review, die Wartungsscans und jede Aktion im Repository (Push, Pull Requests, Kommentare, Commit-Status, CI-Abfragen, Merges) laufen auf deinen Runnern, mit deren eigenem Modellzugang und eigenen Code-Host-Tokens. kanman behält Board, Richtlinien, Entscheidungen, Audit-Log und den Stand der Runs sowie das, was deine Runner zurückmelden: Story-Texte, Zusammenfassungen mit Datei- und Zeilenangaben, Dateinamen und Zeilenzahlen sowie Links. Eingaben und Ausgaben der Werkzeuge des Coding-Werkzeugs und sein Protokoll bleiben auf dem Runner. Ist kein Runner online, wartet die Arbeit; nichts weicht auf die kanman Cloud aus. Was genau kanman erreicht, steht unter Alles auf deinen Runnern ausführen.

Was kanman speichert

Daten	Zweck	Ort
Workspace, Mitglieder und Rollen	Anmeldung und Zugriffskontrolle	EU
Aus deinem Tracker gespiegelte Stories (Titel, Beschreibung, Akzeptanzkriterien)	Aufnahme, Bereitschaftsprüfung, Runs	EU
Run-Daten (Stufen, Fortschrittszeilen, Kosten, Richtlinien-Entscheidungen)	Run-Seite, Team-Bericht	EU
Audit-Log	Nachvollziehbarkeit und Audit-Export	EU
Gedächtnis und Skills des Teams	Was kanman und das Team wissen, für spätere Arbeit	EU
Chat-Nachrichten, die kanman an den Orten deines Teams erhält und postet	Antworten, Aufnahme aus dem Chat, Was kanman gesagt hat, Audit-Log	EU
Teamkontext: Quellen, der daraus gelesene Text und Verbindungs-Tokens (verschlüsselt)	Antworten mit Quellen, siehe Teamkontext und Verbindungen	EU
Incidents: Alarme, Befunde, die Log- und Fehlerzeilen, die kanman zitiert, sowie Secrets und Log-Zugangsdaten deiner Signalquellen (verschlüsselt)	Incident-Seite und Zeitleiste, Wochenbericht, siehe Incidents und Rufbereitschaft	EU

kanman behält keine Kopie deines Repositories. Code wird pro Run ausgecheckt und mit der Maschine verworfen. Diffs, Datei-Referenzen und kurze Ausschnitte erscheinen auf der Run-Seite und im Aktivitätsprotokoll, weil Reviewer sie brauchen.

Was die EU verlässt

Die EU verlassen können nur die Daten, die kanman an einen Modellanbieter sendet: vom Coding-Werkzeug und vom Reviewer bei ihrer Arbeit sowie bei den Modellaufrufen für die Aufnahme und für Antworten im Chat. Welcher Anbieter das ist, hängt von deinem Executor ab und davon, ob du einen eigenen API-Schlüssel nutzt. Details unter Was Modellanbieter sehen.

Nachrichten, die kanman in Slack oder Microsoft Teams schreibt, speichern diese Dienste, im Rahmen der Vereinbarung deines Unternehmens mit ihnen.

Wenn Modellaufrufe in einer bestimmten Region bleiben müssen, nutze deinen eigenen Vertrag mit Azure OpenAI oder Amazon Bedrock mit einer Region deiner Wahl. Damit jeder Modellaufruf des Workspaces in der EU bleibt, schalte Verarbeitung nur in der EU ein: kanman lehnt dann jeden Weg außerhalb der EU ab, bevor eine Anfrage hinausgeht.

Teams mit eigenem Schlüssel nutzen ihn auch für den unabhängigen Reviewer. Teams mit eigenem Runner können Modellaufrufe ganz in ihrem eigenen Cloud-Konto halten; siehe Modellzugang auf Self-hosted Runnern.

Verschlüsselung

Alle Verbindungen nutzen TLS.
Gespeicherte Daten sind im Ruhezustand verschlüsselt.
API-Tokens werden nur als Hash gespeichert, deine eigenen Modell-Schlüssel verschlüsselt. Beide werden nach dem Anlegen oder Speichern nie wieder angezeigt.