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 Sie auf Ihre eigene Infrastruktur verlagern können.

Zwei Betriebsarten

Jeder Workspace legt fest, wo Runs ausgeführt werden: in der kanman Cloud (Standard) oder auf Ihren 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	Ihre eigene Maschine, VM oder Ihr Cluster
Wer die Maschinen betreibt	kanman	Sie
Netzwerkrichtung	kanman startet pro Run eine frische Maschine	Ihr Runner verbindet sich ausgehend mit kanman, keine eingehenden Ports
Repository-Zugang	Das Token Ihrer Git-Verbindung, nur für den Run an git übergeben	Das Token Ihrer Git-Verbindung, nur innerhalb Ihres Netzes genutzt
Geeignet für	Einstieg, Testphase, Teams ohne besondere Vorgaben	Regulierte Umgebungen, private Netze, Code, der Ihre Infrastruktur nicht verlassen darf

Beide Betriebsarten nutzen dieselbe Richtlinie, dasselbe Outcome-Gate und dasselbe Audit-Log. Ein Wechsel ändert nichts an der Arbeitsweise Ihres 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 Ihres 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.

Akzeptanzspezifikationen laufen genauso: Jede Prüfung bekommt eine eigene Maschine in Frankfurt am Main, die danach entfernt wird.

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 Ihrer Git-Verbindung, das verschlüsselt gespeichert ist.

Die kanman-Anwendung (Web-App, API, Entscheidungseingang 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 Sie selbst betreiben. 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 Ihre Repositories nur innerhalb Ihres Netzes geklont, und der Coding-Agent arbeitet nur dort,
gehen Fortschrittszeilen, die Diff-Zusammenfassung, Commit-Informationen und ein Protokoll der Arbeit des Agenten an kanman, für die Run-Seite und das Nachweispaket,
laufen auch die Akzeptanzspezifikationen und die Clean-Room-Prüfung auf Ihrem Runner, sobald er Docker mit Compose erreicht; Ihre Anwendung und ihre Testdaten verlassen Ihr Netz dabei nicht.

Die Einrichtung beschreibt Self-hosted Runner betreiben.

Alles auf Ihren 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 Ihre Repositories. Das Entwerfen von Stories, das unabhängige Review, das Schreiben von Akzeptanzspezifikationen, die Wartungsscans und jede Aktion im Repository (Push, Pull Requests, Kommentare, Commit-Status, CI-Abfragen, Merges) laufen auf Ihren 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 Ihre Runner zurückmelden: Story-Texte, Zusammenfassungen der Nachweise mit Datei- und Zeilenangaben, Dateinamen und Zeilenzahlen sowie Links. Eingaben und Ausgaben der Werkzeuge des Coding-Agenten 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 Ihren Runnern ausführen.

Was kanman speichert

Daten	Zweck	Ort
Workspace, Mitglieder und Rollen	Anmeldung und Zugriffskontrolle	EU
Aus Ihrem Tracker gespiegelte Stories (Titel, Beschreibung, Akzeptanzkriterien, Demonstrate-Block)	Aufnahme, Bereitschaftsprüfung, Runs	EU
Run-Daten (Stufen, Fortschrittszeilen, Kosten, Richtlinien-Entscheidungen)	Run-Seite, Team-Bericht	EU
Nachweispakete und Nachweis-Artefakte	Belege für Reviewer und Prüfer	EU
Audit-Log	Nachvollziehbarkeit und Audit-Export	EU
Team-Konventionen	Team-Gedächtnis für spätere Runs	EU
Chat-Nachrichten, die kanman an den Orten Ihres 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 Ihrer Signalquellen (verschlüsselt)	Incident-Seite und Zeitleiste, Wochenbericht, siehe Incidents und Rufbereitschaft	EU

kanman behält keine Kopie Ihres Repositories. Code wird pro Run ausgecheckt und mit der Maschine verworfen. Diffs, Datei-Referenzen und kurze Ausschnitte erscheinen im Nachweispaket und auf der Run-Seite, 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-Agent und vom Reviewer bei ihrer Arbeit sowie bei den Modellaufrufen für die Aufnahme, für Akzeptanzspezifikationen und für Antworten im Chat. Welcher Anbieter das ist, hängt von Ihrem Executor ab und davon, ob Sie einen eigenen API-Schlüssel nutzen. Details unter Was Modellanbieter sehen.

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

Wenn Modellaufrufe in einer bestimmten Region bleiben müssen, nutzen Sie Ihren eigenen Vertrag mit Azure OpenAI oder Amazon Bedrock mit einer Region Ihrer Wahl. Damit jeder Modellaufruf des Workspaces in der EU bleibt, schalten Sie 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 und das Schreiben von Akzeptanzspezifikationen. 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, Ihre eigenen Modell-Schlüssel verschlüsselt. Beide werden nach dem Anlegen oder Speichern nie wieder angezeigt.