Configure the Ollama provider

What the provider calls

The provider uses Ollama's native non-streaming chat endpoint. Buffaly appends /api/chat to the endpoint root from the selected endpoint row.

POST <BaseUrl>/api/chat

Local machine:      http://127.0.0.1:11434/api/chat
Tailscale/local:    http://100.122.249.99:11434/api/chat
Ollama Cloud:       https://ollama.com/api/chat

If requests are going to /api/api/chat, the configured BaseUrl is wrong. Remove /api from the endpoint row.

Required deployed provider module

The installed Buffaly instance needs the Ollama provider module under the install root, and the provider module manifest must enable it.

<InstallRootPath>\lib\provider-modules\Buffaly.Provider.Ollama\Buffaly.Provider.Ollama.dll
<InstallRootPath>\lib\provider-modules\ProviderModules.json

The manifest entry should use provider ollama, display name Ollama, the Ollama catalog source type, and the Ollama completion executor type.

{
  "Enabled": true,
  "Name": "Ollama",
  "Provider": "ollama",
  "DisplayName": "Ollama",
  "AssemblyPath": "Buffaly.Provider.Ollama/Buffaly.Provider.Ollama.dll",
  "CatalogSourceTypeName": "Buffaly.Provider.Ollama.OllamaProviderCatalogSource",
  "CompletionExecutorTypeName": "Buffaly.Provider.Ollama.OllamaCompletionExecutor",
  "LoadOrder": 750
}

If the provider does not appear in the UI, check this manifest and the provider module directory before debugging model settings.

Feature settings location and shape

Runtime configuration lives in the SQL-backed Features table as the Ollama Feature row.

Endpoints describe where Ollama is hosted and how to authenticate. Models describe which model names Buffaly exposes and which endpoint each model uses. A model row references an endpoint row by EndpointName.

Configure local Ollama

Use a local endpoint when Ollama runs on the same Windows machine, a Mac Mini, or another reachable local/Tailscale host. The endpoint must be reachable from the Buffaly web/worker process.

{
  "IsEnabled": true,
  "UseSeparateDebugLog": false,
  "RequestTimeoutSeconds": 180,
  "Endpoints": [
    {
      "EndpointName": "mac-mini-local",
      "DisplayName": "Mac Mini Ollama",
      "BaseUrl": "http://100.122.249.99:11434",
      "ApiKey": "",
      "IsDefault": true
    }
  ],
  "Models": [
    {
      "ModelName": "qwen2.5-coder:14b",
      "DisplayName": "Qwen2.5 Coder 14B (Mac Mini Ollama)",
      "EndpointName": "mac-mini-local",
      "IsDefault": true,
      "MaxOutputTokens": 1024,
      "Temperature": 0,
      "TopP": null,
      "TopK": null,
      "RepeatPenalty": 1,
      "Think": ""
    }
  ]
}

For same-machine Ollama, use http://127.0.0.1:11434. For a remote Mac Mini over Tailscale, Ollama must listen on a non-loopback interface, for example:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

Verify reachability from the Buffaly host before debugging Buffaly routing:

Invoke-WebRequest http://100.122.249.99:11434/api/tags -UseBasicParsing

Configure Ollama Cloud

Use the same ollama provider. Add a cloud endpoint with BaseUrl set to https://ollama.com. The provider sends the endpoint ApiKey as Authorization: Bearer <ApiKey>.

{
  "EndpointName": "ollama-cloud",
  "DisplayName": "Ollama Cloud",
  "BaseUrl": "https://ollama.com",
  "ApiKey": "<OLLAMA_CLOUD_API_KEY>",
  "IsDefault": true
}

Prefer storing the cloud key in Buffaly UserSecrets under one or both conventional keys: OLLAMA_CLOUD_API_KEY or OLLAMA_API_KEY. If you place the key directly in Feature JSON, do not paste it into logs, wiki pages, screenshots, or commits.

$apiKey = [Environment]::GetEnvironmentVariable("OLLAMA_CLOUD_API_KEY")
$body = @{
  model = "gpt-oss:20b"
  stream = $false
  messages = @(@{ role = "user"; content = "Say hello in one short sentence." })
  options = @{ temperature = 0; num_predict = 128 }
} | ConvertTo-Json -Depth 10 -Compress

Invoke-WebRequest `
  -Uri "https://ollama.com/api/chat" `
  -Method Post `
  -Headers @{ Authorization = "Bearer $apiKey" } `
  -ContentType "application/json" `
  -Body $body `
  -UseBasicParsing

Verify the provider catalog

The UI provider dropdown is driven by the provider catalog service. If ollama does not appear, the usual cause is a missing provider module, invalid feature settings, stale cached provider registry, or a model row with a missing endpoint reference.

Invoke-WebRequest `
  -Uri "http://127.0.0.1:5016/api/buffaly.agent.host/provider-catalog-service/get-provider-catalog" `
  -Method Post `
  -ContentType "application/json" `
  -Body "{}" `
  -UseBasicParsing

The catalog should include an enabled, configured ollama provider row with DefaultTransport set to provider_native and model rows for the configured local and/or cloud model names.

Verify a Buffaly round trip

A real acceptance smoke should prove that the session is created with Provider=ollama, the selected model is the intended local or cloud model, transport is provider_native, the user message is persisted, and the assistant response is normal user-visible text.

1. Create a fresh staging/local session with provider ollama and a known model name.
2. Send a short deterministic prompt such as Reply exactly: OLLAMA_PROVIDER_OK.
3. Confirm the assistant answer is text, not a raw JSON fragment.
4. Check the provider logs for the expected /api/chat request.

Use tiny num_predict or MaxOutputTokens values only for direct endpoint marker probes. Do not leave production or staging model rows capped at very small values; real Buffaly turns need enough output budget for complete responses.

Troubleshooting