Model access on self-hosted runners

On a self-hosted runner the coding agent can use the model access you configure on the runner itself. kanman then hands the run no model credentials at all: no key of its own and no key stored in kanman. Whatever the runner’s environment provides is what the coding agent uses.

We recommend your own cloud account for this: Amazon Bedrock, Google Vertex AI or Microsoft Foundry for Claude Code, and Azure OpenAI for Codex. The credentials stay in your infrastructure, model calls run under your cloud contract and in the region you choose, and you can use the identity mechanisms you already have (IAM roles, workload identity, managed identity).

Operators are responsible for complying with their model provider’s terms when they configure the runner environment.

Turn it on for a team

The setting exists only for workspaces whose runs execute on their own runners (Settings > AI providers > Advanced, kanman Cloud switched off).

1. Open the team’s Settings > Budgets.
2. Under Model usage, choose Model access from the runner environment. In the team setup the same choice is in the executor step.
3. Set the budgets in minutes and runs (see below) and save.

kanman cannot see model cost in this mode. Instead of euros, the team’s budgets count time and runs:

Expedite and incident work still starts when a run limit is reached. The evidence pack of these runs says that model cost is not tracked. On kanman Cloud this setting is refused: runs there never use a runner’s environment.

The run page shows the time a run has used against Minutes per run instead of a cost in euros.

Review and acceptance specs

Two steps of the outcome gate also use a model: the independent reviewer and the writing of a story’s acceptance spec. In this mode kanman has no model access it could use for them from its cloud, and it never falls back to its own. Turn on Run everything on your runners to run them on your runner with this same model access. Without it, a story that needs an acceptance spec stays in Refining with the note Waiting for your runner, and a run whose changes are ready for review is parked with the same explanation on its run page. Nothing fails and no attempts are used up while it waits.

What the runner passes on

In this mode the coding agent sees the runner’s environment, except kanman’s own tokens. Set the variables of your provider on the runner container. When the runner starts, its log names the providers it found (for example bedrock), never their values.

The variables below are the ones Claude Code and Codex read. To pin model versions on Bedrock, Vertex AI or Foundry, set ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL and ANTHROPIC_DEFAULT_HAIKU_MODEL to the model IDs enabled in your account; kanman’s model choice per story then resolves to them.

Amazon Bedrock

Google Vertex AI

Microsoft Foundry

Codex with Azure OpenAI

Docker Compose example

A runner that offers Claude Code on Amazon Bedrock with the host’s IAM role:

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

The same runner on Google Vertex AI with a mounted service account key:

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

Kubernetes example

A runner on Microsoft Foundry for Claude Code and Azure OpenAI for Codex. Keys live in a 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

With workload identity (Vertex AI on GKE) or a managed identity (Foundry on AKS), leave the key out of the Secret and attach the identity to the pod’s service account instead.

Related pages

• Run the self-hosted runner
• What model providers see
• Policy settings
• Budgets and cost