Local Worker Provider Setup

Self Hosted provider setup happens in the Local Worker UI or through deployment-managed configuration.

Open:

http://127.0.0.1:8010/providers

Provider Configuration Modes

Mode	Use it when
UI-managed	Workspace operators should configure provider cards from the worker UI. Best for first-run testing.
Provisioned	Platform teams supply provider settings through environment variables, Docker secrets, Kubernetes Secrets, Helm values, or identity bindings.
Gateway-managed executors	Executors read provider configuration from the worker gateway. This is the normal multi-executor pattern.

If a field is provisioned, the Local Worker UI may show the effective value as locked.

Supported Provider Paths

Self Hosted workers can use provider paths such as:

• Codex CLI
• Codex API
• Claude Code CLI
• Claude API
• OpenAI-compatible endpoints with tool-calling support
• Vertex AI
• AWS Bedrock
• Azure Foundry

The provider must support the tool behavior MergeLoom needs: read files, edit files, run allowed commands, inspect diffs, and return a structured final result.

CLI Providers

For CLI providers, authenticate inside the worker container or through the worker UI flow. A login on the host shell is not enough.

Typical checks:

• provider card shows authenticated or ready
• selected model/profile is valid
• worker container can run the provider command
• provider command timeout is high enough for the ticket size

API and Cloud Providers

For API-backed providers, check:

• base URL
• region or project where applicable
• model or deployment name
• API key, bearer token, service account, workload identity, or IAM role
• network reachability from the worker container or pod
• tool-calling self-test result

For production Kubernetes installs, prefer workload identity, IAM roles, or an existing Kubernetes Secret over plain Helm values for static secrets.

Advanced Cloud Provider Setup

Use these provider paths when your Self Hosted worker should call your cloud AI account directly.

Provider	Production identity pattern	Required setup
Vertex AI	GKE Workload Identity or Application Default Credentials	Project, location, publisher/model path or raw endpoint URL.
AWS Bedrock	AWS default credential chain, IAM role, or EKS IRSA	Region and Bedrock model ID.
Azure Foundry	Managed identity, AKS Workload Identity, or Entra service principal	Foundry deployment/model, Entra tenant, client identity, and token scope.

Use static keys only when your platform team approves them. In production, store static secrets in Docker/Kubernetes Secrets rather than plain Helm values or local notes.

Kubernetes Provider Secrets

For Kubernetes installs, put enrollment tokens and static provider secrets in an existing Kubernetes Secret and pass it to the Helm chart:

kubectl create secret generic mergeloom-worker-env \
  --namespace mergeloom \
  --from-literal=JCA_WORKER_ENROLLMENT_TOKEN="worker-enrollment-token" \
  --from-literal=JCA_OPENAI_API_KEY="openai-api-key" \
  --from-literal=JCA_ANTHROPIC_API_KEY="anthropic-api-key"

helm upgrade --install mergeloom-worker oci://registry-1.docker.io/mergeloom/mergeloom-worker \
  --namespace mergeloom \
  --create-namespace \
  --set worker.controlPlaneUrl="https://controller.mergeloom.ai" \
  --set worker.tenantSlug="customer-slug" \
  --set secret.existingSecretName="mergeloom-worker-env"

Common sensitive Secret keys include:

• JCA_WORKER_ENROLLMENT_TOKEN
• JCA_OPENAI_API_KEY
• JCA_ANTHROPIC_API_KEY
• JCA_VERTEX_SERVICE_ACCOUNT_JSON
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• JCA_AZURE_FOUNDRY_API_KEY
• AZURE_CLIENT_SECRET

Provider Selection Order

When a job runs, MergeLoom resolves provider and model selection from the most specific source first:

1. ticket directive such as provider=... inside a [JCA]...[/JCA] block
2. ticket directive such as model=... inside a [JCA]...[/JCA] block
3. model label such as model:sonnet where allowed
4. repository workflow provider/model defaults
5. workspace default provider and optional model from the controller
6. worker-stored provider default model/profile

If a requested provider is not ready on a worker, the job should not start on that worker.

What to Verify Before Running Jobs

• provider readiness check passes
• selected model supports tools
• worker can reach the provider endpoint
• credentials are stored in the approved place
• command timeout is realistic
• allowed commands include the repository validation tools
• Local Worker UI is reachable only through your approved private path

Related page: Configure a Self Hosted AI Coding Provider.