Alles auf deinen Runnern ausführen

Mit einem Self-hosted Runner findet die Codearbeit eines Runs in deinem Netz statt. Einige Schritte rund um den Run laufen standardmäßig trotzdem in der kanman Cloud: das Entwerfen von Stories aus einer Anforderung, das unabhängige Review, die Wartungsscans und Aktionen im Repository wie das Öffnen des Pull Requests oder das Lesen der CI-Ergebnisse.

Alles auf unseren (alles auf deinen Runnern ausführen) verlagert auch all diese Schritte auf deine Runner. Die kanman Cloud ruft dann für den Workspace nie einen Modellanbieter auf und liest oder schreibt nie eines deiner Repositories. Weder Quellcode noch Modellverkehr laufen über kanman.

Eigene Runner und diese Option gibt es ab dem Tarif Starter und in der 14-tägigen Testphase des Team-Tarifs. Siehe Tarife und Abrechnung.

Einschalten

1. Starte mindestens einen Self-hosted Runner und gib ihm den unten beschriebenen Modellzugang und das Token für deinen Code-Host.
2. Öffne Workspace-Einstellungen > Runs und Runner (/settings/runs).
3. Wähle unter Wo Runs laufen Alles auf unseren. kanman fragt vorher nach: Es nennt die Arbeit, die auf deine Runner wandert, und sagt, dass Arbeit wartet, solange kein Runner online ist. Bestätige mit Alles auf unseren. Inhaber und Admins können das ändern; die Änderung steht im Audit-Log (Exportformat).

Das Schaubild Wo was läuft auf derselben Seite zeigt dann Runs, Prüfungen, Modellaufrufe, Repository-Aktionen und Chat-Antworten auf der Seite deines Netzwerks. Zurück geht es mit Unsere Runner oder kanman Cloud.

Was deine Runner brauchen

Der Runner behält die Tokens für sich. Die kanman Cloud braucht in diesem Modus kein Token für deinen Code-Host und nutzt keines.

Weil die kanman Cloud in diesem Modus die Projekte deines Code-Hosts nicht auflistet, fügen die Team-Einrichtung und Team > Repositories ein Repository über seine Host-URL und seinen Pfad hinzu, und dein Runner prüft, dass er es erreicht. Für ein GitLab, das nur in deinem Netz erreichbar ist, siehe GitLab hinter VPN oder Firewall.

Verschiedene Modelle für das Coding und die übrigen Schritte

Der Runner kann kanmans eigenen Schritten ein anderes Modell geben als dem Coding-Werkzeug, zum Beispiel Claude für das Coding und das OpenAI-kompatible KI-Gateway deines Unternehmens für Entwürfe, Review und Antworten. Setz dafür die KANMAN_ASSISTANT_-Variablen auf dem Runner; siehe Verschiedene Modelle für das Coding und die übrigen Schritte.

Ein Gateway, das nur in deinem Netz erreichbar ist, kannst du auch als Anbieterschlüssel des Workspaces in kanman hinterlegen (Stattdessen ein Gateway oder einen Proxy nutzen unter Workspace-Einstellungen > Modellzugang): In diesem Modus rufen nur deine Runner es auf, interne Adressen sind erlaubt, und Verbindung testen läuft auf deinem Runner. Siehe Das KI-Gateway deines Unternehmens nutzen und KI-Gateways in der Runner-Umgebung.

Was wo läuft

Workspaces, die alles auf eigenen Runnern ausführen: Verbindungen

In diesem Modus läuft jede Verbindung unter Workspace-Einstellungen > Verbindungen über deinen Runner, auch zu Diensten in der Cloud wie Jira Cloud, Confluence Cloud oder Datadog. Die kanman Cloud ruft diese Systeme für den Workspace nie auf und hält ihre Zugänge nie.

• Wohin der Zugang gehört: Leg ihn in der Umgebung deines Runners ab, unter dem Variablennamen, den du beim Verbinden des Systems einträgst. Für Jira Cloud trägst du zum Beispiel die Adresse der Site, die E-Mail des Kontos und einen Variablennamen wie JIRA_API_TOKEN ein und gibst dem Runner diese Variable mit einem API-Token als Wert. kanman speichert nur den Namen.
• Verbindung testen läuft auf deinem Runner. Die Antwort kann ein paar Sekunden dauern; sie erscheint von selbst.
• Anmelden über kanman (die Schaltfläche Anmelden, die manche Systeme anbieten) gibt es in diesem Modus nicht, weil die Anmeldung in der kanman Cloud gespeichert würde. Nutze stattdessen einen Token des Systems. Ein System, das nur eine solche Anmeldung und keinen Token anbietet, oder das kanman noch nicht über einen Runner erreicht, sagt das in seinem Eintrag und lässt sich hier nicht verbinden. Nichts weicht auf die kanman Cloud aus.
• Ereignisse aus anderen Systemen: Webhooks erreichen deinen Runner nicht, deshalb bietet kanman in diesem Modus keine Webhook-Adresse an. Wo ein System es unterstützt, fragt dein Runner es alle paar Minuten nach neuen Ereignissen, im Rahmen des Abrufbudgets der Verbindung; sonst sagt der Eintrag des Systems, dass es in diesem Workspace keine Ereignisse schickt, und kanman liest und handelt weiter über deinen Runner.
• Die eine Ausnahme: Microsoft Teams. Microsoft stellt die Nachrichten eines Teams-Bots an eine öffentliche Adresse zu, deshalb bleibt Microsoft Teams über die kanman Cloud verbunden. Sein Eintrag sagt das. Alles andere läuft über deinen Runner.

Was genau die kanman Cloud erreicht

Die kanman Cloud speichert nur den Stand der Orchestrierung und was deine Runner zurückmelden:

• die Stories, die du schreibst oder freigibst (Titel, Beschreibung, Akzeptanzkriterien), Entscheidungen, Richtlinien und Einstellungen,
• Status und Fortschrittszeilen der Runs und die erste Zeile jeder Statusmeldung des Coding-Werkzeugs (keine Eingaben oder Ausgaben seiner Werkzeuge, kein Protokoll seiner Arbeit), die Kosten, CI-Ergebnisse, das Urteil des Reviewers mit seinen Befunden, Links zum Pull Request und zur CI,
• die Namen und Zeilenzahlen der geänderten Dateien und die Commit-Liste eines Runs (keine Dateiinhalte),
• den Text, den ein Runner für die eigenen Schritte von kanman zurückschickt: entworfene Stories, das Urteil des Reviewers, Wartungsbefunde, Strategievorschläge und Antworten,
• das Audit-Log, mit einem Eintrag für jeden Schritt, den ein Runner erledigt hat (Schritt, Runner, Ergebnis und bei Modellschritten die Tokens und die geschätzten Modellkosten). Ein Modellaufruf, den kanman in seiner Cloud macht, wird ebenfalls verzeichnet (“Modell in der kanman-Cloud aufgerufen”), damit das Log belegt, dass keiner stattfand: Frag kanman “Zeig mir die Runner-Jobs im Audit-Log” oder “Zeig mir die Modellaufrufe im Audit-Log”, um es gefiltert zu öffnen.

Für die Prompts dieser Schritte schickt kanman deinem Runner, was es ohnehin speichert (etwa eine Story und ihre Akzeptanzkriterien), und die Namen der Dateien oder Refs, die er lesen soll. Den Inhalt aus dem Repository ergänzt der Runner selbst. Code gelangt nie zu kanman, und kanman ruft für den Workspace nie einen Modellanbieter auf.

Wenn kein Runner online ist

Die Arbeit wartet. Nichts weicht auf die kanman Cloud aus.

• Öffnest du kanman, während dein Runner offline ist und Arbeit auf ihn wartet, sagt kanman das zuerst in deiner Unterhaltung: welcher Runner, seit wann (in deiner Zeitzone) und wie viele Schritte warten, zum Beispiel “Dein Runner build-box-1 ist seit 03.10.2026, 08:53 offline; 2 Schritte warten auf ihn.” Ist der Runner zurück, geht alles von selbst weiter.
• Warten Schritte auf einen freien Runner, zeigt ein kleines Badge am Ende der Statuszeile des Teams Wartet auf einen Runner. Fährst du mit der Maus darüber (oder tippst darauf oder drückst die Eingabetaste), siehst du, wie viele Schritte warten, und einen Link zu Workspace-Einstellungen > Runs und Runner. Ist kein Runner online, sagt das ein Hinweis in deiner Unterhaltung, mit demselben Link.
• Eine Anforderung, die du in der Unterhaltung schickst, zeigt, dass sie auf deinen Runner wartet. Sobald ein Runner antwortet, erscheinen die Entwürfe in derselben Nachricht.
• Ein Run, dessen Review auf den Runner wartet, wird mit Wartet auf deinen Runner geparkt; er läuft weiter, sobald der Runner antwortet, ohne einen Versuch zu verbrauchen.

Grenzen

• Antworten, die auf Nur Personen mit Zugriff in der Quelle beschränkt sind, prüfen Confluence-Seitenberechtigungen bei Confluence Cloud; SharePoint-Dateien, die für eine Gruppe freigegeben sind, brauchen für diese Prüfung eine SharePoint-Verbindung in kanman, sonst bekommen nur Personen Antworten daraus, für die die Datei direkt freigegeben ist.
• Log-Abfragen bei Incidents aus Datadog, CloudWatch und Sentry sowie Traces aus Datadog APM sind auf dem Runner noch nicht verfügbar; Kubernetes, Loki und Tempo funktionieren.
• Aktionen in Repositories auf anderen Hosts als GitHub und GitLab werden in diesem Modus noch nicht unterstützt.

Verwandte Seiten

• GitLab hinter VPN oder Firewall
• Den Self-hosted Runner betreiben
• Modellzugang auf Self-hosted Runnern
• Hosting und Datenresidenz
• Was Modellanbieter sehen