Wiring Ollama for Local-Only Mode: What's Actually Available

Ollama support is real, reviewed code — a complete fourth vendor option in OpenTechnologyApp's routing config, not a stub. One important caveat up front: as of this writing, it lives on an open pull request (feat/ollama-vendor, OpenTechnologyApp PR #273) that hasn't merged into the deployed app yet. This guide describes what that code does, so you know exactly what to expect once it ships — and what it doesn't change, which matters even more.

What's built

• A fourth vendor value. The router's vendor type gains 'ollama' alongside Anthropic, OpenAI, and Hugging Face — selectable for the primary, simple, and fallback roles, and for the single-provider chatbot config.
• A base-URL field, not an API key. Ollama needs no credential — there's nothing to authenticate against on localhost. Instead, Settings gains one new column storing the Ollama server's address, defaulting to http://localhost:11434. The Admin Panel shows this field only when at least one vendor role is actually set to Ollama.
• The model field takes any local model name. The placeholder is nextjs-dev — the name used by the Modelfile convention this blog's hybrid-AI post walks through (ollama create nextjs-dev -f ~/.ollama/modelfiles/nextjs-dev.Modelfile). Any model you've pulled or created locally works the same way.

The one hard limit, stated in the product itself

Whenever any vendor role is set to Ollama, the Admin Panel shows an amber warning directly under the base-URL field:

⚠ Ollama only works in local dev or self-hosted deployments. Vercel Functions cannot reach a laptop's localhost.

This is the single fact to get right before recommending Ollama to anyone: a Vercel-hosted production deployment cannot reach localhost on your machine, full stop. Ollama only makes sense when the app itself is running somewhere that can actually reach the Ollama server — your own laptop during development, or a self-hosted deployment on the same machine or network as the Ollama instance.

Who this is actually for

• Local development. Point the app at your own machine's Ollama instance while developing — zero per-token cost, nothing leaves your machine.
• Self-hosted deployments. If you're running OpenTechnologyApp on your own server rather than Vercel, and that server can reach an Ollama instance (on itself or on your network), the same setup works in what would otherwise be "production" for you.
• Not for a Vercel-hosted org's production traffic. If your organization's OpenTechnologyApp instance is the hosted, Vercel-deployed one, don't set any routing tier to Ollama for real traffic — it will fail to reach the vendor entirely, since there's no localhost for a serverless function to resolve to.

Current status: real code, not yet merged

Everything above describes the actual implementation on OpenTechnologyApp's feat/ollama-vendor branch, corresponding to PR #273 — as of this writing, an open pull request, not yet merged to main or deployed. That's a meaningfully different state from the earlier version of this guide, which described Ollama as a stubbed comment with no real implementation behind it — this is real, working code awaiting review and merge, not a placeholder. Check the PR's status before telling someone the feature is live in their deployed app today; once it merges, this note should be removed.