# How to connect your own Ollama models to an AI app builder

> Run app generation on models you already host with Ollama. Includes the exact CORS commands for macOS, Linux and Windows that most guides leave out.

Source: https://northerngo.com/resources/connect-ollama-local-models/
Language: en
Updated: 2026-08-16

---
**Ollama is connected from the account menu under **Local AI (Ollama)**, which requires the Pro plan. Switch on the toggle, enter the model name exactly as `ollama list` reports it, and start Ollama with `OLLAMA_ORIGINS="*" ollama serve` so the browser is allowed to reach `localhost:11434`. Generation then runs on your own hardware, and the generated app is unchanged.**

### Why route generation through your own Ollama

If you already run models locally with Ollama, you have hardware and model choices that a browser-based runtime cannot match — larger quantisations, models you have pulled or fine-tuned yourself, and no download limits imposed by the browser cache. Pointing an app builder at that setup means generation happens entirely on infrastructure you control.

There is a second reason that matters more in practice: cost predictability. Cloud generations are metered — five a month on Free, 25 on Premium, 50 on Pro. Ollama generations are not metered at all, because they never touch a server that could count them. If you iterate heavily, that difference is the whole point.

The honest counterpoint is that a 7B model on your laptop is not a frontier cloud model. Expect to correct it more often. What you are buying is privacy, unlimited iteration and control over the model, not better output.

### What you need before you start

- **The Pro plan.** The Ollama setting lives in the account menu under a section marked Premium / Pro, and it is Pro-gated specifically. On Free and Premium the item is visible but shows a lock, and clicking it says the feature is exclusive to Pro users. There is no way around this from the app side.
- **Ollama installed and running on the same machine as the browser.** The editor talks to `http://localhost:11434`. A model on another machine on your network is not reachable through this setting.
- **A desktop.** The browser has to reach localhost, so a phone or tablet cannot use this path.

If you want local generation without Pro, the [in-browser WebGPU route](/resources/webgpu-react-local-ai/) is the alternative — Qwen 3.5 4B runs on the free plan, unlimited, with no terminal involved.

### Step 1: Install Ollama and pull a model

Download Ollama from its official site and pull a model from your terminal:

```bash
ollama run gemma2
```

For code generation specifically, coder-tuned models generally outperform general-purpose models of the same size, so it is worth trying a couple before settling. The model field in the editor suggests `gemma2`, `llama3.1` and `qwen2.5` as starting points, and `gemma2` is the default if you leave the field alone.

Whatever you pull, note down what `ollama list` calls it. That exact string is what the editor sends, and a near-miss like `llama3` for `llama3.1` fails as a connection error rather than as a helpful "no such model".

### Step 2: Start Ollama with CORS enabled

This is the step almost every guide omits, and the reason most people give up. A browser will refuse to talk to your local Ollama unless it sends permissive CORS headers, so Ollama has to be started with an origins variable rather than launched normally.

macOS and Linux:

```bash
OLLAMA_ORIGINS="*" ollama serve
```

Windows, in PowerShell:

```powershell
$env:OLLAMA_ORIGINS="*"; ollama serve
```

Note that this must be the running instance. If Ollama is already running as a background service without that variable, stop it first — otherwise the new process will not take over the port and the browser will keep being refused. On macOS that means quitting the menu bar app, not just closing a window. On Windows, exit Ollama from the system tray.

The symptom of getting this wrong is specific and worth recognising: the editor reaches the port, the request is rejected before Ollama ever sees it, and you get a generic connection failure. Nothing appears in Ollama's own log, because the request never arrived.

### Step 3: Enable it in the editor

Open the account menu and choose **Local AI (Ollama)** under the Premium / Pro section. The dialog has two controls:

1. **Enable local connection** — the toggle that routes generation to `localhost:11434`.
2. **Ollama model name** — the exact model string from `ollama list`.

Press **Save settings**. Both values are stored in your browser, so the setting survives a reload and stays on until you switch it off. That is worth remembering: if you come back a week later, forget you left it on, and generate with Ollama not running, the failure looks mysterious.

### Step 4: Build, and know which engine you actually got

With the toggle on, generation requests go to your machine. The status message says "Contacting local Ollama…" while it works, which is the quickest way to confirm which engine ran.

One ordering rule to know: if in-browser WebGPU local mode is also active, WebGPU wins. The engine is chosen in the order WebGPU, then Ollama, then cloud. If you enabled Ollama but a WebGPU model is loaded, you are generating on the WebGPU model and the Ollama setting is simply unused.

The Architect follow-up question can run on your Ollama model. There is no LLM Critic rewrite on the Ollama path — a syntax check blocks JavaScript that will not parse; it does not repair logic and it does not call the cloud.

Nothing about the generated app changes. It still uses the same built-in Supabase database, the same authentication and the same publishing pipeline, and the SDK is injected the same way.

### The context window is what will actually bite you

This is the failure people hit on their second or third session, and it is not obvious.

The editor sizes Ollama's context window to the prompt. It reads a stored value that defaults to 8192 tokens and raises it automatically when the prompt needs more — reserving roughly 6400 tokens of headroom for a full build and 2560 for a surgical edit, so the model has somewhere to write its answer. The ceiling is 32768 tokens.

When your app's source plus the prompt exceeds that ceiling, generation stops before it starts and tells you the app is too large for the local model's memory window, with the estimated token count. This is a deliberate refusal rather than a truncated, broken app — a model that runs out of window mid-file produces code that ends halfway through a function.

Two ways out when you hit it: update the app through the cloud instead, or split the change into smaller steps. Updates use a diff-based edit mode that sends only the parts being changed, so small, specific requests stay comfortably inside the window while "redesign the whole thing" does not.

There is a practical implication for how you work. Local models are best on early builds and small, targeted changes. A large, mature app is usually easier to extend through the cloud, which is a trade-off rather than a defect — and if the plan is to leave the platform eventually, [what matters more is that the output is standard exportable HTML](/resources/avoid-vendor-lock-in-ai-builders/) either way.

### What still goes to the cloud

Being precise here matters, because "local AI" gets used loosely.

Generation is local: your prompt and the code the model writes stay on your machine. But these are separate actions that do use the network, and running Ollama does not change them:

- **Saving a project** stores it in the cloud, as does publishing.
- **AI features inside the generated app** — `window.NorthernGoAI.generate()`, `speak()` and `generateImage()` — always go to the cloud proxy. There is no path that routes a published app's own AI calls to your Ollama, because your visitors cannot reach your laptop.
- **The app's database** reads and writes against hosted Supabase.

So Ollama makes the *building* private, not the running. The [full comparison of what local and cloud generation each give you](/resources/local-ai-vs-cloud-ai-app-builders/) covers where that distinction matters, and the [GDPR implications](/resources/gdpr-compliant-app-building-eu/) are worth reading if the reason you want local generation is regulatory rather than practical.

### Limitations

- **Pro plan only**, and only from a desktop browser on the same machine as Ollama.
- **32768 token ceiling.** Large apps cannot be updated locally at all.
- **Quality varies with the model.** A small general-purpose model will ignore instructions a larger coder model follows. If updates keep coming back in the wrong format, the model is usually the cause rather than the prompt.
- **No streaming preview of the plan.** You see code stream in, but a weaker model produces less reliable phase markers, so the progress display can be less informative than it is on cloud builds.
- **One retry on format failures.** If a model ignores the required edit format, the editor retries once with stricter instructions and then gives up rather than looping. That is the intended behaviour, not a stall.

### Troubleshooting

If the editor cannot reach the model, work through these in order. Most failures are one of the first three.

**"Could not connect to Ollama."** Confirm Ollama is actually serving by opening `http://localhost:11434` in a browser tab — it should respond, not time out. Then confirm you started it with the origins variable set, not as a plain background service. Then confirm the model name in the editor matches exactly what `ollama list` reports.

**It worked yesterday and fails today.** Ollama restarted without the origins variable, most likely because the machine rebooted and the background service came back instead of your terminal process. The variable is not persistent unless you set it at system level.

**The port responds but the browser still refuses.** Two instances are running, and the one holding port 11434 is the one started without CORS. Stop all of them, confirm nothing answers on the port, then start it again with the variable.

**"This app is too large for the local model's memory window."** You have hit the 32768 token ceiling. Make a smaller, more specific change, or update this app through the cloud.

**Generation runs but produces nothing usable.** Try a coder-tuned model of a similar size. This is a model capability problem, not a connection problem, and no amount of prompt rewording fixes a model that is too small for the task.

**The toggle is on but generation clearly went to the cloud.** Check whether a WebGPU model is loaded. WebGPU takes priority over Ollama, and cloud is only used when neither local engine is active.

## Frequently asked questions

### Why does my browser refuse to connect to local Ollama?

Almost always because Ollama was started without the OLLAMA_ORIGINS variable. A browser blocks requests to a local server that does not return permissive CORS headers. Stop any background instance and start it again with the origins variable set.

### Does using Ollama mean my code never leaves my machine?

The generation itself happens on your machine, so prompts and generated code are not sent to a cloud model. Publishing an app, saving it to a cloud database or deploying it to a subdomain are separate actions that do involve the network.

### Which plan do I need to connect Ollama?

Pro. The Local AI (Ollama) setting sits in the account menu and is gated to the Pro plan; on Free and Premium it appears with a lock. If you want local generation without Pro, the in-browser WebGPU option runs Qwen 3.5 4B unlimited on the free plan instead.

### Why does it say my app is too large for the local model?

The context window for local generation is capped at 32768 tokens, and an existing app plus your instruction has to fit inside it with room left for the reply. Rather than producing code that gets cut off mid-function, generation is refused. Make a smaller, more specific change, or update that app through the cloud instead.

### Can the AI features inside my finished app run on my own Ollama?

No. Calls like window.NorthernGoAI.generate() inside a published app always go to the cloud AI proxy, because your visitors cannot reach your computer. Ollama makes the building private, not the running of the app. In-app AI features also require the app owner to be on Premium or Pro.

---

## Related

- [Build with Claude, Cursor and ChatGPT without remote-controlling the account](https://northerngo.com/resources/build-with-claude-cursor-chatgpt/)
- [How local AI works in the browser with WebGPU and React](https://northerngo.com/resources/webgpu-react-local-ai/)
- [Local AI vs cloud AI app builders: cost, privacy and speed](https://northerngo.com/resources/local-ai-vs-cloud-ai-app-builders/)
- [Building GDPR-compliant apps: a practical checklist for EU founders](https://northerngo.com/resources/gdpr-compliant-app-building-eu/)

---

NorthernGo is an AI-powered platform for building production-ready web apps with zero coding. Local AI generation via WebGPU is unlimited and free, and you own all generated source code. https://northerngo.com/