GitLab hinter VPN oder Firewall

Ist Ihr GitLab nur in Ihrem Firmennetz erreichbar, zum Beispiel hinter einem VPN, kann sich die kanman Cloud nicht damit verbinden. Sie müssen Ihr Netz dafür nicht öffnen. Stattdessen betreiben Sie einen Self-hosted Runner im Netz und schalten Alles auf Ihren Runnern ausführen ein. Der Runner erledigt dann jede Aktion im Repository mit seinem eigenen GitLab-Token: Klonen, Branches, Merge Requests, Kommentare mit dem Nachweispaket, CI-Ergebnisse. Die kanman Cloud verwaltet Board, Entscheidungen, Richtlinien und das Audit-Log und verbindet sich nie mit Ihrem GitLab.

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

So greift alles ineinander

• Der Runner läuft in Ihrem Netz, auf einem Linux-Host oder einer VM mit Docker, neben Ihrem GitLab.
• Er verbindet sich ausgehend über HTTPS mit kanman, fragt nach Arbeit und meldet Ergebnisse zurück. kanman verbindet sich nie in Ihr Netz hinein. Keine eingehenden Ports, kein VPN-Zugang für kanman, keine Firewall-Ausnahme für eingehenden Verkehr.
• Er erreicht Ihr GitLab mit seinem eigenen Token (GITLAB_TOKEN). Das Token verlässt den Runner nie.
• Er ruft Ihren Modellanbieter mit dem Zugang auf, den Sie auf ihm einrichten, zum Beispiel Ihr 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

Legen Sie 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 Ihrem Netz starten

Legen Sie unter Deine Einstellungen > API-Tokens ein Workspace-Token an (siehe Den Self-hosted Runner betreiben). Starten Sie 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

Für Akzeptanzprüfungen braucht der Runner außerdem Docker mit Compose, zum Beispiel über den eingebundenen Docker-Socket des Hosts (-v /var/run/docker.sock:/var/run/docker.sock). Siehe Akzeptanzprüfungen auf Ihrem Runner.

Legen Sie das Image in Produktion auf ein Versions-Tag fest und aktualisieren Sie bewusst.

Interne Zertifikate

Nutzt Ihr GitLab ein Zertifikat, das von der eigenen Zertifizierungsstelle Ihres Unternehmens signiert ist, geben Sie dem Runner dieses CA-Zertifikat. Binden Sie die PEM-Datei ein und setzen Sie 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 den Coding-Agenten. Er baut aus den Systemzertifikaten und Ihrem eines gemeinsames Bündel und richtet git darauf aus, sodass öffentliche Hosts wie api.kanman.ai weiter vertrauenswürdig bleiben.

Haben Sie bereits ein vollständiges Bündel (Systemzertifikate plus Ihre CA), setzen Sie stattdessen SSL_CERT_FILE darauf.

HTTP-Proxy

Muss ausgehender Verkehr über einen Proxy laufen, setzen Sie die üblichen Variablen. Der Runner, git und der Coding-Agent nutzen sie:

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

Tragen Sie Ihr 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: Ihr eigenes Cloud-Konto, damit der Modellverkehr unter Ihrem Vertrag und in Ihrer Region bleibt.

• Amazon Bedrock, Microsoft Foundry oder Google Vertex AI für Claude Code, Azure OpenAI für Codex: Setzen Sie die Variablen des Anbieters auf dem Runner und wählen Sie für das Team Modellzugang aus der Runner-Umgebung. 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 Ihres Unternehmens im Netz: Hinterlegen Sie es unter Workspace-Einstellungen > Modellanbieter als OpenAI-kompatibles Gateway (nur Ihre Runner rufen es auf, und Verbindung testen läuft auf Ihrem Runner), oder setzen Sie seine Variablen auf dem Runner. Siehe Das KI-Gateway Ihres 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 Sie auch wählen, er deckt jeden Schritt auf dem Runner ab: den Coding-Agenten ebenso wie das Entwerfen von Stories, den unabhängigen Reviewer, Akzeptanzspezifikationen 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 Ihres Unternehmens im Netzwerk zu schicken, setzen Sie die KANMAN_ASSISTANT_-Variablen auf dem Runner. Siehe Verschiedene Modelle für das Coding und die übrigen Schritte.

Damit der Coding-Agent außer dem Modellanbieter nichts kontaktiert, setzen Sie auf dem Runner zusätzlich CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1.

Schritt 4: Alles auf unseren Runnern ausführen einschalten

1. Öffnen Sie Workspace-Einstellungen > Runner.
2. Schalten Sie Alles auf unseren Runnern ausführen ein.
3. Prüfen Sie, dass Ihr 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 Ihren Runnern ausführen.

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

Die kanman Cloud kann die Projekte Ihres GitLab nicht auflisten, deshalb fügen Sie das Repository über seinen Pfad hinzu.

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

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

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

Wenn die Prüfung ein Problem findet

Wahl des Trackers

GitLab-Issues können in diesem Modus nicht der Tracker des Teams sein: Die Issues liegen auf Ihrem GitLab, das die kanman Cloud nicht erreicht. Wählen Sie 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 Ihrem GitLab: Der Runner öffnet die Merge Requests dort.

Was funktioniert und was nicht

Funktioniert, alles auf Ihrem Runner:

• Runs: Klonen, Run-Branch, der Coding-Agent, lokale Verifikation mit Ihren GitLab-CI-Variablen, Push und der Merge Request
• Akzeptanzprüfungen auf einem frischen Checkout (mit Docker auf dem Runner)
• Die Repository-Schritte des Outcome-Gates: Diff, Ergebnisse der CI-Pipeline, Commit-Status, das Nachweispaket als Kommentar im Merge Request und Merges, wenn Ihre Merge-Richtlinie kanman mergen lässt
• Das unabhängige Review und Akzeptanzspezifikationen mit Ihrem Modellzugang
• Die Prüfung des Akzeptanz-Manifests und der Merge Request, der ein Start-Manifest hinzufügt
• Wartungsscans, das Entwerfen von Stories aus der Unterhaltung, Team-Kontext aus Repositories

In diesem Modus nicht verfügbar:

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

Verwandte Seiten

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