Hosting und Datenresidenz
Wo kanman läuft, wo Ihre Daten gespeichert werden und wie Sie die Code-Ausführung auf Ihre eigene Infrastruktur verlagern.
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. Der Schalter ist Kanman Cloud unter Einstellungen > KI-Anbieter, Bereich Advanced; Einstellungen > Runner (/settings/runners) zeigt, wo Runs ausgeführt werden 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, Piloten, 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.
Akzeptanz-Specs laufen genauso: Jede Prüfung bekommt eine eigene Maschine in Frankfurt am Main, die danach entfernt wird.
Kommt in einem späteren Release
Repository-Tokens, die auf ein Repository beschränkt sind und mit dem Run ablaufen. Heute nutzt ein Run das Token Ihrer Git-Verbindung.
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.
Die Einrichtung beschreibt Self-hosted Runner betreiben.
Kommt in einem späteren Release
Akzeptanz-Specs und die Clean-Room-Prüfung auf Ihrem eigenen Runner. Heute laufen sie nur in der kanman Cloud.
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 |
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 der Coding-Agent und der Reviewer bei ihrer Arbeit an ihren Modellanbieter senden. 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.
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.
Kommt in einem späteren Release
Ihr eigener Schlüssel für den unabhängigen Reviewer und für das Schreiben von Akzeptanz-Specs. Heute nutzen diese beiden die Konten von kanman bei den Modellanbietern, auch bei Teams mit eigenem Schlüssel.
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.
Verwandte Seiten
Zuletzt aktualisiert: January 1, 0001
kanman öffnen