Ollama on DNotifier: Setup Guide

Part of a series on running AI workflows across model providers — this one's the first that isn't a hosted API at all.

Every provider covered so far in this series has been a hosted API — somewhere in the cloud, reachable over the internet, authenticated with a key. Ollama breaks that pattern completely. It's a runtime for models running on hardware you control, and that difference shows up immediately in how DNotifier connects to it — not through an API key, but through a network path that has to actually exist.

What Ollama is, in one line

Ollama is an open-source runtime (MIT-licensed, built on the llama.cpp inference engine) for downloading and running large language models directly on your own machine — a laptop, a workstation, a box in your own data center, or a VM inside your own cloud VPC. There's no DNotifier-side account to create for it, no API key to paste, and no usage bill from a model vendor. What you're managing instead is hardware, models, and network reachability.

The provider string and configuration

DNotifier's Ollama integration uses provider: "ollama". Setup happens under Projects → AI Studio → Providers → Ollama in the portal, where you configure one thing: the base URL DNotifier should call. There's no authentication field, because Ollama itself doesn't require one by default — reachability, not credentials, is the whole game here.

Every other provider in this series routes to someone else's cloud. Ollama routes to yours.

Setup steps

Three steps, all on the machine running Ollama: pull a model with ollama pull llama3.2, verify it downloaded correctly with ollama list, then paste the base URL into the DNotifier portal and save. The model name you use in code has to match what ollama list actually shows — the same "don't assume, verify" discipline this series has already covered for Azure's deployment names.

The detail that trips up almost everyone

Ollama's default local address is http://127.0.0.1:11434 — and DNotifier's own documentation is direct about what that means in practice: that address "only works if the DNotifier worker that runs AI can reach that address. Cloud workers cannot see your laptop loopback." A loopback address, by definition, only means "this same machine" — and DNotifier's AI runtime isn't running on your laptop.

The single most common Ollama setup failure: pasting a loopback URL into a portal that runs somewhere else entirely.

DNotifier's documentation lists three ways to fix this: run Ollama on a host that's actually reachable from wherever DNotifier's AI runtime executes, use a tunnel or VPN per the portal's instructions, or use a self-hosted DNotifier deployment if that's available to you. Whichever path you pick, the underlying requirement is the same, stated plainly in DNotifier's own docs: "whatever URL you save in the portal has to answer from the AI runtime."

A use case that shows this in practice

A small team building an internal tool prototype configured DNotifier's Ollama provider with http://127.0.0.1:11434, copied directly from what worked when testing curl commands on the developer's own laptop. Every call failed once deployed, with no obvious error pointing at the real cause. The fix wasn't a code change — it was standing up Ollama on a small reachable VM inside their own cloud VPC and pointing the portal at that address instead, which took longer to diagnose than to actually fix once the reachability issue was understood.

A practical note for development

DNotifier's guidance also suggests keeping saveHistory disabled while developing against a local Ollama setup, specifically to avoid cluttering history UIs during iteration — worth doing until the integration is stable.

Frequently asked questions

Does Ollama require an API key like the other providers in this series?

No — DNotifier's documentation doesn't mention any authentication requirement for Ollama specifically; the base URL is the only thing configured in the portal.

Can I just use my laptop for a production Ollama integration?

Not directly — a laptop's loopback address isn't reachable from DNotifier's cloud AI runtime. Production use needs a host that's actually network-reachable from wherever that runtime executes.

What models can I run through Ollama on DNotifier?

Any model available via ollama list on the machine you've configured — DNotifier's example uses llama3.2, and the constraint is what your hardware can run, not what DNotifier restricts.

Is a tunnel like ngrok a real, supported option?

DNotifier's documentation lists "tunnel/VPN per portal instructions" as one of three valid paths — check the current portal instructions for the specific tunnel setup it recommends.

The Bottom Line

Next in this series: what actually makes running a model on your own hardware a fundamentally different choice than calling someone else's API.

Read part two: What Makes Ollama Different?. Explore dnotifier.com.