Modellzugang auf Self-hosted Runnern

Auf einem Self-hosted Runner kann der Coding-Agent den Modellzugang nutzen, den Sie auf dem Runner selbst einrichten. kanman gibt dem Run dann überhaupt keine Zugangsdaten für Modelle: keinen eigenen Schlüssel und keinen in kanman gespeicherten. Was die Umgebung des Runners bereitstellt, nutzt der Coding-Agent.

Wir empfehlen dafür Ihr eigenes Cloud-Konto: Amazon Bedrock, Google Vertex AI oder Microsoft Foundry für Claude Code und Azure OpenAI für Codex. Die Zugangsdaten bleiben in Ihrer Infrastruktur, Modellaufrufe laufen unter Ihrem Cloud-Vertrag und in der Region Ihrer Wahl, und Sie nutzen die Identitätsmechanismen, die Sie schon haben (IAM-Rollen, Workload Identity, Managed Identity).

Betreiber sind dafür verantwortlich, beim Einrichten der Runner-Umgebung die Bedingungen ihres Modellanbieters einzuhalten.

Für ein Team einschalten

Die Einstellung gibt es nur für Workspaces, deren Runs auf eigenen Runnern laufen (Einstellungen > KI-Anbieter > Erweitert, kanman Cloud ausgeschaltet).

1. Öffnen Sie die Einstellungen > Budgets des Teams.
2. Wählen Sie unter Modellnutzung die Option Modellzugang aus der Runner-Umgebung. Bei der Einrichtung des Teams steht dieselbe Auswahl im Executor-Schritt.
3. Legen Sie die Budgets in Minuten und Runs fest (siehe unten) und speichern Sie.

kanman sieht in diesem Modus keine Modellkosten. Statt Euro zählen die Budgets des Teams Zeit und Runs:

Expedite- und Störungsarbeit startet auch dann, wenn ein Run-Limit erreicht ist. Das Nachweispaket dieser Runs sagt, dass Modellkosten nicht erfasst werden. In der kanman Cloud wird diese Einstellung abgelehnt: Runs dort nutzen nie die Umgebung eines Runners.

Die Run-Seite zeigt die verbrauchte Zeit eines Runs im Verhältnis zu Minuten pro Run statt Kosten in Euro.

Review und Akzeptanzspezifikationen

Zwei Schritte des Outcome-Gates nutzen ebenfalls ein Modell: der unabhängige Reviewer und das Schreiben der Akzeptanzspezifikation einer Story. In diesem Modus hat kanman keinen Modellzugang, den es dafür aus seiner Cloud nutzen könnte, und weicht nie auf einen eigenen aus. Schalten Sie Alles auf Ihren Runnern ausführen ein, damit sie mit genau diesem Modellzugang auf Ihrem Runner laufen. Ohne diese Einstellung bleibt eine Story, die eine Akzeptanzspezifikation braucht, mit dem Hinweis Wartet auf deinen Runner in Verfeinerung, und ein Run, dessen Änderungen bereit für das Review sind, wird mit derselben Erklärung auf seiner Run-Seite geparkt. Dabei schlägt nichts fehl, und es werden keine Versuche verbraucht.

Was der Runner weitergibt

In diesem Modus sieht der Coding-Agent die Umgebung des Runners, außer den Tokens von kanman selbst. Setzen Sie die Variablen Ihres Anbieters am Runner-Container. Beim Start nennt das Log des Runners die gefundenen Anbieter (zum Beispiel bedrock), nie deren Werte.

Die folgenden Variablen lesen Claude Code und Codex. Um Modellversionen auf Bedrock, Vertex AI oder Foundry festzulegen, setzen Sie ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL und ANTHROPIC_DEFAULT_HAIKU_MODEL auf die in Ihrem Konto freigeschalteten Modell-IDs; kanmans Modellwahl pro Story löst sich dann auf diese auf.

Amazon Bedrock

Google Vertex AI

Microsoft Foundry

Codex mit Azure OpenAI

Beispiel mit Docker Compose

Ein Runner, der Claude Code über Amazon Bedrock mit der IAM-Rolle des Hosts anbietet:

services:
  kanman-runner:
    image: ghcr.io/kanman-ai/executor-host
    restart: unless-stopped
    environment:
      KANMAN_API_KEY: ${KANMAN_API_KEY}
      RUNNER_NAME: runner-fra-1
      RUNNER_EXECUTORS: claude-code
      CLAUDE_CODE_USE_BEDROCK: "1"
      AWS_REGION: eu-central-1
      ANTHROPIC_DEFAULT_SONNET_MODEL: eu.anthropic.claude-sonnet-4-5-20250929-v1:0

Derselbe Runner über Google Vertex AI mit eingebundenem Dienstkonto-Schlüssel:

services:
  kanman-runner:
    image: ghcr.io/kanman-ai/executor-host
    restart: unless-stopped
    environment:
      KANMAN_API_KEY: ${KANMAN_API_KEY}
      RUNNER_EXECUTORS: claude-code
      CLAUDE_CODE_USE_VERTEX: "1"
      CLOUD_ML_REGION: europe-west1
      ANTHROPIC_VERTEX_PROJECT_ID: acme-ai-prod
      GOOGLE_APPLICATION_CREDENTIALS: /secrets/gcp-key.json
    volumes:
      - ./gcp-key.json:/secrets/gcp-key.json:ro

Beispiel mit Kubernetes

Ein Runner mit Microsoft Foundry für Claude Code und Azure OpenAI für Codex. Die Schlüssel liegen in einem Kubernetes-Secret:

apiVersion: v1
kind: Secret
metadata:
  name: kanman-runner
type: Opaque
stringData:
  KANMAN_API_KEY: km_your_runner_token
  ANTHROPIC_FOUNDRY_API_KEY: your_foundry_key
  AZURE_OPENAI_API_KEY: your_azure_openai_key
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kanman-runner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kanman-runner
  template:
    metadata:
      labels:
        app: kanman-runner
    spec:
      containers:
        - name: runner
          image: ghcr.io/kanman-ai/executor-host
          envFrom:
            - secretRef:
                name: kanman-runner
          env:
            - name: RUNNER_EXECUTORS
              value: claude-code,codex
            - name: CLAUDE_CODE_USE_FOUNDRY
              value: "1"
            - name: ANTHROPIC_FOUNDRY_RESOURCE
              value: acme-foundry
            - name: AZURE_OPENAI_BASE_URL
              value: https://acme-openai.openai.azure.com/openai/v1
            - name: AZURE_OPENAI_DEPLOYMENT
              value: gpt-5

Mit Workload Identity (Vertex AI auf GKE) oder einer Managed Identity (Foundry auf AKS) lassen Sie den Schlüssel aus dem Secret weg und hängen die Identität an das Dienstkonto des Pods.

Verwandte Seiten

• Den Self-hosted Runner betreiben
• Was Modellanbieter sehen
• Richtlinien-Einstellungen
• Budgets und Kosten