fix(ai): allow Ollama Cloud API key in AI settings

[VincentEmmanuel]

Summary

The Ollama provider detection in AI Settings matches any URL containing the substring ollama, which hides the API Key input for Ollama Cloud (ollama.com) and drops the key from the createOllama() client. As a result, Ollama Cloud cannot be used — requests go out unauthenticated and fail.

This PR:

• Narrows the "no API key needed" rule to local Ollama only (localhost:11434 / 127.0.0.1:11434), so the API Key field is visible for Ollama Cloud and any self-hosted Ollama behind an auth proxy.
• Forwards the API key as an Authorization: Bearer ... header to createOllama, using the headers option supported by ai-sdk-ollama v3.7.

The getModels ollama branch in the AI router already builds its headers via getProviderHeaders(apiUrl, apiKey), so once the key reaches the backend it authenticates /api/tags correctly — no router change needed.

Repro (before fix)

1. Settings → AI → Add AI, select Ollama
2. Change API URL to an Ollama Cloud endpoint (hostname contains ollama)
3. API Key input is hidden — cannot be entered or saved
4. Requests to Ollama Cloud fail auth

After fix

• API Key field is shown for any non-local Ollama URL
• Key is sent as Authorization: Bearer <key> on both model listing and completion requests

Files changed

• apps/dokploy/components/dashboard/settings/handle-ai.tsx — replace isOllama substring check with isLocalOllama (localhost-only)
• packages/server/src/utils/ai/select-ai-provider.ts — pass headers with Bearer token to createOllama

Test plan

• Local Ollama (http://localhost:11434) still works with no API key entered
• Ollama Cloud URL shows the API Key field
• Ollama Cloud with valid key lists models and runs completions
• Other providers (OpenAI, Anthropic, Gemini, etc.) unaffected

🤖 Generated with Claude Code

Greptile Summary

This PR fixes Ollama Cloud authentication by narrowing the "no API key needed" detection from any URL containing ollama or :11434 to strictly localhost/127.0.0.1 on port 11434, and forwards the API key as a Bearer header to createOllama.

• Regression: The enabled gate on the getModels query (isLocalOllama || !!apiKey) now blocks model listing for any non-localhost Ollama that has no API key (e.g. http://192.168.1.100:11434). Those instances don't need auth but will silently get no models in the dropdown.

Confidence Score: 4/5

Safe to merge for the primary Ollama Cloud use case, but introduces a regression for unauthenticated non-localhost Ollama instances.

The core fix (showing the API key field for Ollama Cloud and forwarding it as a Bearer token) is correct. However, the enabled gate for model listing now blocks model fetching for unauthenticated Ollama instances that aren't on localhost (e.g. LAN or remote Ollama without auth), which is a real UX regression from the previous behavior.

apps/dokploy/components/dashboard/settings/handle-ai.tsx — specifically the enabled condition on the getModels query

_{Reviews (1): Last reviewed commit: "fix(ai): allow Ollama Cloud API key in A..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

Model listing broken for unauthenticated non-localhost Ollama

The enabled gate isLocalOllama || !!apiKey is false for any Ollama instance that isn't localhost/127.0.0.1 and has no API key — e.g. a LAN instance at http://192.168.1.100:11434. Those users will see the API Key field (now shown), leave it blank (no auth needed), and the models query will never fire. The model dropdown stays empty and they must type the model name manually without knowing why.

A simple fix is to also skip the gate for the :11434 port pattern, mirroring the original condition's intent:

Suggested change

	enabled: !!apiUrl && (isLocalOllama || !!apiKey),
	enabled: !!apiUrl && (isLocalOllama || apiUrl.includes(":11434") || !!apiKey),

Or, alternatively, detect the pattern apiUrl.includes(":11434") && !apiKey as "unauthenticated Ollama" for gating purposes, separate from the API-key visibility decision.

[greptile-apps]

IPv6 loopback not covered

isLocalOllama doesn't match http://[::1]:11434, so a user running Ollama on the IPv6 loopback will see the API Key field (and the model listing gate will block fetching unless they type a key). This is an edge case but easy to handle:

Suggested change

	const isLocalOllama =
	apiUrl.includes("localhost:11434") ||
	apiUrl.includes("127.0.0.1:11434");
	const isLocalOllama =
	apiUrl.includes("localhost:11434") ||
	apiUrl.includes("127.0.0.1:11434") ||
	apiUrl.includes("[::1]:11434");