GitLab hinter VPN oder Firewall

Ist dein GitLab nur in deinem Firmennetz erreichbar, zum Beispiel hinter einem VPN, kann sich die kanman Cloud nicht damit verbinden. Du musst dein Netz dafür nicht öffnen. Stattdessen betreibst du einen Self-hosted Runner im Netz und schaltest Alles auf deinen Runnern ausführen ein. Der Runner erledigt dann jede Aktion im Repository mit seinem eigenen GitLab-Token: Klonen, Branches, Merge Requests, Review-Kommentare, CI-Ergebnisse. Die kanman Cloud verwaltet Board, Entscheidungen, Richtlinien und das Audit-Log und verbindet sich nie mit deinem GitLab.

Dasselbe funktioniert für GitHub Enterprise Server hinter einer Firewall.

So greift alles ineinander

• Der Runner läuft in deinem Netz, auf einem Linux-Host oder einer VM mit Docker, neben deinem GitLab.
• Er verbindet sich ausgehend über HTTPS mit kanman, fragt nach Arbeit und meldet Ergebnisse zurück. kanman verbindet sich nie in dein Netz hinein. Keine eingehenden Ports, kein VPN-Zugang für kanman, keine Firewall-Ausnahme für eingehenden Verkehr.
• Er erreicht dein GitLab mit seinem eigenen Token (GITLAB_TOKEN). Das Token verlässt den Runner nie.
• Er ruft deinen Modellanbieter mit dem Zugang auf, den du auf ihm einrichtest, zum Beispiel dein Konto bei Amazon Bedrock, Microsoft Foundry oder Google Vertex AI.

Was erreichbar sein muss

Vom Runner-Host aus ausgehendes HTTPS (Port 443) zu:

Von außen muss nichts den Runner erreichen.

Das Log des Runners nennt beim Start den kanman-Host, den er nutzt (kanmanHost), zusammen mit den Proxy- und Zertifikat-Einstellungen, die er gefunden hat.

Schritt 1: Ein GitLab-Token für den Runner anlegen

Leg ein Token an, das der Runner für alle Arbeit im Repository nutzt. Gut passt ein Projekt- oder Gruppen-Zugriffstoken für die Projekte des Teams; ein persönliches Zugriffstoken eines Dienstkontos funktioniert ebenso.

Schritt 2: Den Runner in deinem Netz starten

Leg unter Deine Einstellungen > API-Tokens ein Workspace-Token an (siehe Den Self-hosted Runner betreiben). Starte dann den Runner auf einem Host im Netz:

docker run -d --name kanman-runner \
  --restart unless-stopped \
  -e KANMAN_API_KEY=km_ihr_runner_token \
  -e RUNNER_NAME=corp-runner-1 \
  -e GITLAB_TOKEN=glpat-ihr-runner-token \
  -e GITLAB_API_URL=https://gitlab.corp.example/api/v4 \
  -e CLAUDE_CODE_USE_BEDROCK=1 \
  -e AWS_REGION=eu-central-1 \
  ghcr.io/kanman-ai/executor-host

Leg das Image in Produktion auf ein Versions-Tag fest und aktualisiere bewusst.

Interne Zertifikate

Nutzt dein GitLab ein Zertifikat, das von der eigenen Zertifizierungsstelle deines Unternehmens signiert ist, gib dem Runner dieses CA-Zertifikat. Binde die PEM-Datei ein und setz NODE_EXTRA_CA_CERTS:

  -v /etc/pki/company-ca.pem:/certs/company-ca.pem:ro \
  -e NODE_EXTRA_CA_CERTS=/certs/company-ca.pem \

Der Runner gibt das Zertifikat an alles weiter, was er startet: seine eigenen Verbindungen, git (Klonen, Fetch, Push) und das Coding-Werkzeug. Er baut aus den Systemzertifikaten und deinem eines gemeinsames Bündel und richtet git darauf aus, sodass öffentliche Hosts wie api.kanman.ai weiter vertrauenswürdig bleiben.

Hast du bereits ein vollständiges Bündel (Systemzertifikate plus deine CA), setz stattdessen SSL_CERT_FILE darauf.

HTTP-Proxy

Muss ausgehender Verkehr über einen Proxy laufen, setz die üblichen Variablen. Der Runner, git und das Coding-Werkzeug nutzen sie:

  -e HTTPS_PROXY=http://proxy.corp.example:3128 \
  -e NO_PROXY=gitlab.corp.example,.corp.example \

Trag dein GitLab (und andere interne Hosts) in NO_PROXY ein, wenn sie direkt erreicht werden. Kleingeschriebene Namen (https_proxy, no_proxy) funktionieren ebenfalls.

Schritt 3: Den Modellzugang wählen

Der Runner ruft den Modellanbieter selbst auf. Für Unternehmen empfohlen: dein eigenes Cloud-Konto, damit der Modellverkehr unter deinem Vertrag und in deiner Region bleibt.

• Amazon Bedrock, Microsoft Foundry oder Google Vertex AI für Claude Code, Azure OpenAI für Codex: Setz die Variablen des Anbieters auf dem Runner und wähle für das Team unter Team > Modelle > Modellzugang die Option Zugang deines Runners. Siehe Modellzugang auf Self-hosted Runnern.
• Ein eigener Schlüssel, in kanman hinterlegt: Der Runner erhält ihn für jeden Schritt dieses Teams.
• Ein Anthropic- oder OpenAI-Schlüssel auf dem Runner (ANTHROPIC_API_KEY, OPENAI_API_KEY).
• Das KI-Gateway deines Unternehmens im Netz: Hinterleg es unter Workspace-Einstellungen > Modellzugang mit Stattdessen ein Gateway oder einen Proxy nutzen (nur deine Runner rufen es auf, und Verbindung testen läuft auf deinem Runner), oder setz seine Variablen auf dem Runner. Siehe Das KI-Gateway deines Unternehmens nutzen und KI-Gateways in der Runner-Umgebung. Claude Code braucht den Anthropic-kompatiblen Endpunkt des Gateways, Codex seine OpenAI Responses API.

Welchen Zugang du auch wählst, er deckt jeden Schritt auf dem Runner ab: das Coding-Werkzeug ebenso wie das Entwerfen von Stories, den unabhängigen Reviewer und kanmans Antworten in der Unterhaltung. Amazon Bedrock über die IAM-Rolle des Runners braucht zum Beispiel für Entwürfe und Review keinen zusätzlichen Schlüssel.

Verschiedene Modelle für das Coding und die übrigen Schritte: Um Claude für das Coding zu behalten und Entwürfe, Review und Antworten an das KI-Gateway deines Unternehmens im Netzwerk zu schicken, setz die KANMAN_ASSISTANT_-Variablen auf dem Runner. Siehe Verschiedene Modelle für das Coding und die übrigen Schritte.

Damit das Coding-Werkzeug außer dem Modellanbieter nichts kontaktiert, setz auf dem Runner zusätzlich CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1.

Schritt 4: Alles auf deinen Runnern ausführen

1. Öffne Workspace-Einstellungen > Runs und Runner.
2. Wähle unter Wo Runs laufen Alles auf unseren und bestätige.
3. Prüf, dass dein Runner in der Liste darunter als Online erscheint.

Ab jetzt ruft die kanman Cloud für diesen Workspace weder einen Modellanbieter noch einen Code-Host auf. Was wo läuft, beschreibt Alles auf deinen Runnern ausführen.

Schritt 5: Das Team anlegen und das Repository über seinen Pfad hinzufügen

Die kanman Cloud kann die Projekte deines GitLab nicht auflisten, deshalb fügst du das Repository über seinen Pfad hinzu.

1. Starte die Team-Einrichtung.
2. Wo leben deine Stories?: Wähle das kanman-Board oder Jira (siehe Wahl des Trackers).
3. Wähle unter Projekt und Repositories GitLab als Code-Host und füll Repository hinzufügen, das dein Runner erreicht aus:
   • Host-URL: die Adresse, die du im Browser öffnest, zum Beispiel https://gitlab.corp.example
   • Projektpfad: der vollständige Pfad, zum Beispiel platform/backend/api
   • Standard-Branch: optional. Bleibt das Feld leer, liest dein Runner den Standard-Branch des Projekts.
4. Klicke auf Repository hinzufügen.

Dein Runner prüft das Repository sofort mit seinem eigenen Token. Die Zeile zeigt:

Weitere Repositories fügst du genauso hinzu, auch später unter Team > Repositories; dort wiederholt Erneut prüfen die Prüfung.

Viele Repositories auf einmal

Ein Team kann in vielen Repositories arbeiten, zum Beispiel in allen Projekten einer GitLab-Gruppe. Leg das Team mit einem davon an, öffne dann Team > Repositories und nutze Mehrere auf einmal hinzufügen:

1. Prüf die Host-URL. Sie ist mit dem Host der übrigen Repositories des Teams vorbelegt.
2. Füge die Projektpfade ein, einen pro Zeile. Projekt-URLs funktionieren auch. Soll kanman von einem anderen Branch als dem Standard-Branch des Projekts ausgehen, schreib ihn nach einem Leerzeichen dazu: platform/integrations/zendesk-sync develop.
3. Klicke auf … Repositories hinzufügen.

Dein Runner prüft die ersten drei sofort. Die übrigen zeigen Noch nicht geprüft mit Jetzt prüfen, damit eine lange Liste deinen Runner nicht beschäftigt hält. Ab 25 Repositories zeigt die Liste einen Filter.

Hat ein Team mehrere Repositories, arbeitet jede Story in genau einem davon:

• Nenn das Repository in deiner Anfrage, zum Beispiel „Zendesk: Ticket-Tags übernehmen“. kanman erkennt den Namen (hier zendesk-sync) und vermerkt auf jedem Entwurf, in welchem Repository es arbeitet.
• Nennt deine Anfrage keines, fragt der Entwurf Welches Repository ändert diese Story? Antworte mit dem Namen, dann arbeitet kanman darin.
• Eine Story ohne Repository startet nicht. Nenn es in der Story oder beantworte die Frage und schieb die Story dann erneut nach Ready.

Wartungsscans prüfen pro Scantag bis zu zehn Repositories eines Teams und machen am nächsten Tag mit den folgenden weiter, sodass jedes Repository der Reihe nach geprüft wird. Braucht es dieselbe Korrektur in vielen Repositories, plant kanman die Änderung über alle, ein Merge Request pro Repository (siehe Eine Story pro Korrektur).

Wenn die Prüfung ein Problem findet

kanman sagt dem Team, was es nicht erreicht

Sobald alle Repositories eines neuen Teams geprüft sind (und wieder, wenn du eins hinzufügst oder entfernst), sagt kanman einmal im Chat des Teams, wenn sein GitLab-Konto einige davon nicht erreicht. Die Nachricht nennt:

• die Repositories, die es nicht lesen kann, und die Gruppen, in denen sie liegen
• die Repositories, die es lesen, aber nicht pushen kann
• Repositories, deren Token GitLab abgelehnt hat
• das Konto, das kanman nutzt (aus deiner GitLab-Verbindung), und ob diese Verbindung noch getestet werden muss

Am Ende steht der nächste Schritt für Workspace-Admins: Gib kanmans Konto auf der Seite Members jeder Gruppe mindestens die Rolle Reporter, und Developer nur dort, wo kanman Änderungen pushen soll. Prüf die Repositories danach erneut unter Team > Repositories. Die Nachricht verlinkt direkt dorthin und auf Einstellungen > Verbindungen.

Die Nachricht braucht die Owner und Admins deines Workspaces, weil sie den Zugang geben können; der Owner des Teams sieht sie auch. kanman wiederholt sich nicht: Dieselben Lücken erzeugen nie eine zweite Nachricht. Ändern sich die Lücken, ersetzt eine neue Nachricht die alte, und sobald kanman alle Repositories erreicht, sagt es das in einer kurzen Antwort.

Die Ergebnisse pro Repository unter Team > Repositories zeigen dieselben Prüfungen im Detail.

Wenn dein Runner die Verbindung zu GitLab verliert

Erreicht dein Runner dein GitLab nicht mehr, etwa weil sein VPN getrennt wurde, sagt kanman es deinem Team einmal im Team-Chat: „Ich erreiche gitlab.example.com seit 14:02 von deinem Runner build-1 aus nicht, deshalb warten Code-Review, Erwähnungen und CI-Prüfungen. Sind sein VPN und sein Netzwerk an? Sobald der Host antwortet, mache ich von selbst weiter.“ Weil wartende Arbeit von selbst weitergeht, ist die Nachricht zunächst nur zu deiner Information. Erst wenn GitLab länger als 30 Minuten nicht erreichbar bleibt, wird sie zu etwas, das Inhaber und Admins braucht. Nutzen mehrere Teams denselben Runner, kommt die Nachricht einmal, nicht einmal pro Team, und bricht die Verbindung kurz nach ihrer Rückkehr erneut ab, aktualisiert kanman dieselbe Nachricht („wieder seit 14:30“), statt eine neue zu schreiben. Der Team-Chat und Persönlich zeigen außerdem einen Hinweis, gitlab.example.com vom Runner build-1 aus nicht erreichbar · seit 14:02, mit einem Link zu deinen Runnern.

Solange GitLab nicht antwortet, schickt kanman deinem Runner keine Arbeit, die nicht gelingen kann. kanman prüft alle paar Minuten, ob GitLab wieder antwortet, und macht dann von selbst weiter. kanman ergänzt dann eine Zeile unter seiner Nachricht, etwa „gitlab.example.com antwortet seit 14:35 wieder; alles, was gewartet hat, geht weiter.“, und die Nachricht braucht niemanden mehr. Auch ein Neustart des Runners lässt kanman es sofort wieder versuchen.

Wahl des Trackers

GitLab-Issues können in diesem Modus nicht der Tracker des Teams sein: Die Issues liegen auf deinem GitLab, das die kanman Cloud nicht erreicht. Wähle stattdessen:

• Das kanman-Board: Stories, Spalten, Kommentare und Verlauf liegen in kanman. Siehe kanman ohne Tracker nutzen.
• Jira (Cloud, oder Server und Data Center, erreichbar aus der kanman Cloud). Siehe Jira und GitLab verbinden.

Der Code bleibt in deinem GitLab: Der Runner öffnet die Merge Requests dort.

Was funktioniert und was nicht

Funktioniert, alles auf deinem Runner:

• Runs: Klonen, Run-Branch, das Coding-Werkzeug, Push und der Merge Request
• Die Repository-Schritte von Prüfungen und Merge: Diff, Ergebnisse der CI-Pipeline, das Review als Kommentar im Merge Request, der Zustand des Merge Requests (kanman bemerkt Merges und Schließungen in GitLab ohne Webhook) und Merges
• Das unabhängige Review mit deinem Modellzugang
• Wartungsscans, das Entwerfen von Stories aus der Unterhaltung, Team-Kontext aus Repositories
• Revert-Merge-Requests, wenn ein Merge von kanman den Main-Branch rot gemacht oder einen Incident verursacht hat
• Code-Review: kanman prüft den Merge Request einer Person, wenn jemand mit Schreibrechten @kanman review schreibt oder ihn zuweist (es sieht alle paar Minuten nach neuen Anfragen), und antwortet auf Review-Kommentare zu seinen eigenen Merge Requests

In diesem Modus nicht verfügbar:

• GitLab-Issues als Tracker des Teams (nutze das kanman-Board oder Jira)
• Repositories in der Team-Einrichtung aus einer Liste wählen (füge sie über ihren Pfad hinzu)
• Team-Kontext aus Confluence, Notion oder hochgeladenen Dateien

Verwandte Seiten

• Den Self-hosted Runner betreiben
• Alles auf deinen Runnern ausführen
• Modellzugang auf Self-hosted Runnern
• Hosting und Datenresidenz