Is Ollama Local? Not Automatically, Not Any More (2026)
Short answer - is your Ollama setup still local?
- Local model, pulled to disk (
gemma4:12b-mlx,qwen3.5:9b, whatever you ran last year) → yes. Inference is on your machine. Nothing about that has changed. - A
-cloudmodel (ollama run gpt-oss:120b-cloud) → no. Your prompt goes to Ollama Inc.'s infrastructure, which is mostly in the US and may be routed to Europe or Singapore for capacity. Requires an account, so you can't land here entirely by accident. - Direct to
ollama.comwith an API key → obviously no, and at least this one is honest about itself in the URL bar. - Local-only mode → set
OLLAMA_NO_CLOUD=1, ordisable_ollama_cloudin~/.ollama/server.json. Cloud models and web search stop existing. One line, and it's the only version of this you can prove.
Bias, up front: I make Humla, a Mac meeting notetaker that can run its summaries and chat against Ollama, and I would love it if you downloaded it. Which also means the mistake described near the bottom is mine, in shipped code, right now. Everything below is quoted from Ollama's own live pages, checked 8 September 2026, with links, plus a couple of things I ran on my own laptop.
The sentence I have been saying for three years
"Just point it at Ollama."
I've said that to clients. I've said it on this blog. It's in my app's settings screen, in the actual product, in a string that says "Runs fully offline" underneath the Ollama server field. For about three years that sentence did an enormous amount of work, because it collapsed a whole privacy conversation into four words. Where does the summary happen? On your machine. Who sees the transcript? You. Done, next question, let's talk about something interesting.
The reason it worked is that Ollama was a place. Port 11434 on your own box, a model file on your own SSD, your fans spinning up like a small unhappy aircraft. You didn't need a policy for it, in the same way you don't need a data processing agreement with your text editor.
Ollama is now also a service. And - this is the bit that matters - it is a service that reaches you through the same door as the place.
Same port, same CLI, same JSON
Here is Ollama's own cloud documentation, describing what a cloud model is:
Ollama's cloud models are a new kind of model in Ollama that can run without a powerful GPU. Instead, cloud models are automatically offloaded to Ollama's cloud service while offering the same capabilities as local models, making it possible to keep using your local tools while running larger models that wouldn't fit on a personal computer.
"Keep using your local tools" is the product pitch, and as a product pitch it's great. You sign in with ollama signin, you ollama run gpt-oss:120b-cloud, and every tool you already own keeps working, because from the tool's point of view nothing changed. Same daemon. Same http://localhost:11434/api/chat. The docs even show you the cURL example against localhost, for a model that is running in a datacenter.
I went and checked the two ends of this myself, because I wanted to see the shape rather than read about it. My local daemon:
$ curl -s http://localhost:11434/api/tags
{"models":[{"name":"gemma4:12b-mlx", ... "capabilities":["completion","tools","thinking"]}, ...]}
And ollama.com, which their docs describe as acting "as a remote Ollama host":
$ curl -s https://ollama.com/api/tags
{"models":[{"name":"kimi-k3","model":"kimi-k3","modified_at":"2026-07-27T08:00:00-07:00", ...}]}
Same endpoint path. Same envelope. Same field names. If you handed me those two responses with the hostnames stripped off I could guess from the metadata, maybe, on a good day, but I could not know.
That is not a criticism of the engineering. It's beautiful engineering. It's the whole reason the thing is pleasant to use, and if you're wiring up a coding agent it is exactly what you want. It's just that a design goal of "indistinguishable from local" and a privacy question of "is this local" are now standing in the same room looking at each other.
(There's a smaller casualty in here too. Cloud models get deprecated and retired on a schedule; local models don't, because they're files. So "I pointed it at Ollama" isn't a reproducible statement any more either. The docs' upcoming-retirements table was still advertising dates in July when I read it in September, which tells you roughly how much traffic that page gets.)
What Ollama actually promises
Now the fair part, because I want to be very clear that Ollama has not pulled anything. They wrote it all down. Most people just haven't read it, because why would you read the privacy policy of a thing whose entire identity is that it runs on your laptop?
Three primary sources, all read on 8 September 2026:
| Where | What it says |
|---|---|
| ollama.com homepage | "Your data is never trained on by any provider. All cloud models are hosted in the US, Europe & Singapore." |
| Pricing FAQ, Privacy section | "Ollama hosts models and compute resources primarily in the United States. To serve global demand, we may route to Europe and Singapore for additional capacity." / "Prompt or response data is never logged or trained on." / "Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models. When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place." |
| Privacy Policy, last updated March 2026 | "When using cloud-hosted models, we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request." / "Data may be transferred to and processed in the United States." |
And the FAQ has a question titled almost exactly what a worried person would type into Google - "Does Ollama send my prompts and answers back to ollama.com?" - answered with:
Ollama runs locally. We don't see your prompts or data when you run locally. When using cloud-hosted models, we process your prompts and responses to provide the service but do not store or log that content and never train on it.
Read on its own terms, that is a genuinely strong set of commitments. No logging, no training, no retention beyond the request. Having now read OpenAI, Deepgram and Groq end to end for this blog, I can tell you it is at the strict end of the range, and it beats the default I found at two of those three.
Two soft spots, and they're both structural rather than sneaky.
One: you don't get to pick the region. The homepage says "hosted in the US, Europe & Singapore" in a way that reads, to me at least, like a menu. The pricing FAQ is more precise: primarily the US, with the other two used for capacity. The privacy policy just says your data may be transferred to and processed in the United States. Those three statements are compatible - they're describing one system at three levels of zoom - but only the FAQ tells you the true thing, which is that routing is theirs and not yours. If you needed EU residency you have not got EU residency. You've got a datacenter that is sometimes in Europe, which is a different product.
Two: it isn't Ollama's GPU. "Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models." The privacy policy's sharing section lists "cloud infrastructure providers, model inference providers" among the third parties. So the no-logging promise is one Ollama makes to you and then requires from someone else, contractually, and those someones aren't named. That's normal. Every hosted API works this way and most don't say it as plainly. But it's the difference between a promise about a machine and a promise about a supply chain, and if you're the person who has to answer a client's security questionnaire, it's the sort of thing you'd rather learn now than in the questionnaire.
And what does the local path send?
Since we're here. If you never touch a cloud model, what leaves?
Model pulls, for one - the FAQ's proxy section notes plainly that "Ollama pulls models from the Internet", over HTTPS. Auto-updates, on macOS and Windows, which the FAQ also documents. And per the privacy policy Ollama automatically collects device and browser information, IP address and general location, "diagnostic metadata for troubleshooting", and "Model download metadata". Section 2 mentions "limited device and usage metadata (such as app version and request counts)", which I read twice, because "request counts" sitting three sentences after "we do not collect, store, transmit, or have access to your prompts, responses, model interactions, or other content you process locally" is at minimum an ambiguous pair of sentences. I don't think it means your local /api/chat calls are being counted somewhere. I do think a policy this good in every other respect could say so in five more words.
So I looked. On my own machine, right now, with the daemon up and idle:
$ lsof -nP -iTCP -a -c ollama
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ollama 20185 ... 3u IPv4 0x... 0t0 TCP 127.0.0.1:11434 (LISTEN)
One socket. Listening on loopback. Nothing outbound at all. That's one snapshot on one Mac running 0.32.14 and it is not an audit, but it matches the documentation, and the thing is MIT-licensed on GitHub so anyone who wants to do the real version of that check can.
Local Ollama is still local. That was never the claim in question.
The off switch, which is one line
This is the part I'd tattoo on the inside of the settings screen if I could. From the FAQ:
// ~/.ollama/server.json
{
"disable_ollama_cloud": true
}
Or the environment variable, OLLAMA_NO_CLOUD=1. Restart, and the logs print Ollama cloud disabled: true. You lose cloud models and web search, which if you came to Ollama for the local thing is a cost of zero.
What I like about this - and I've now written four of these posts, so let me generalise irresponsibly - is that it's the third distinct place a vendor can put a privacy control. Groq puts theirs on the account, where no application can reach it. Deepgram puts theirs in the request, where the application decides and you never find out. Ollama puts theirs on the machine, in a file you own, enforced by a daemon running as you. That's the strongest of the three, and it's the only one where the answer is a thing you can grep for rather than a thing you have to trust.
It is also, and I say this with love, a JSON file in a dotfolder. Nobody's mum is turning this on.
Right. My turn.
Humla's local-model picker asks your server what it has, via /api/tags, and shows you the list. There's a filter on that list, which drops embedding-only models, because picking embeddinggemma for chat makes Ollama return a 400 and makes the user think my app is broken. I was quite pleased with that filter.
It does not drop cloud models. Nothing does. A -cloud model has no "embed" in its name, so it sails through into the dropdown and sits there next to gemma4:12b-mlx looking exactly as local as its neighbour. Worse: if you have no model selected yet, Humla picks the first usable one for you, on the reasonable-in-2024 theory that everything in that list is on your disk.
Above that dropdown, in the AI Chat settings, is a line of my copy that reads "Local runs fully offline against Ollama or any OpenAI-compatible server." On this very site I wrote "Point Humla at Ollama and everything - the chat model and the search index - runs on your Mac. Nothing leaves your machine."
Both of those are true for approximately everyone reading this, because approximately everyone reading this is running a model they pulled to their own SSD. Neither of them is true unconditionally, and I wrote them unconditionally, and the reason I wrote them unconditionally is that when I typed them it wasn't possible to be wrong. I've corrected the two worst lines on this site in the same commit as this post - they say "a local model in Ollama" now, which is four words longer and actually correct. The app-side fix is the real one and it's the next thing I do: mark cloud models in the picker, and stop auto-selecting one.
I'd rather you read that here than find it yourself. It also isn't a reason to be smug about anyone else's copy, because I'd bet a reasonable amount of money that every local-first app with an Ollama integration has the same three-year-old assumption baked into a string somewhere, and most of them haven't noticed either. Go check yours. I'll wait, I'm not going anywhere, I have a picker to fix.
What to actually do
If you use Ollama for anything you'd call confidential:
- Look at the model name.
-cloudmeans cloud. That's the whole tell, and it's a suffix, so it's at the far end of the string where your eye isn't. - Set
OLLAMA_NO_CLOUD=1if you never want the option. It costs you nothing and it converts a policy question into a config question, which is a much better kind of question. - Don't sign in if you don't need to. Cloud models require an account, which is the one real guardrail here - you cannot drift into this without at some point having typed
ollama signin. - If you're evaluating someone's "local" app, ask them which models their picker offers and whether it can tell the difference. Including mine. Especially mine.
The point I've been walking towards
This is the fourth provider post I've written, and the first three all ended the same way: you can't tell what a vendor does from their landing page, you have to read the boring document. I stand by that.
This one goes a step further and I'm still slightly annoyed about it. With Ollama you can't tell from the architecture either. The port is the same, the API is the same, the CLI is the same, the response looks the same, and "it's running on localhost" - which for a decade has been the most reliable privacy signal in computing, the one thing that couldn't lie to you - now means the daemon is on localhost. Not the inference. Not your meeting.
Local stopped being a place and became a setting. Settings have defaults, and defaults have opinions, and now somebody has to check.
If you want the version where there's nothing to check, that's the one I build: Humla records your mic and the call's system audio with no bot, transcribes with Whisper on your Mac's GPU, and does summaries and chat against a model you pulled yourself. MIT-licensed, so the picker I just admitted was wrong is a picker you can read. The honest tradeoffs, same as always: Apple Silicon only, no Windows, no mobile, a much smaller community than the incumbents, and a local chat model that wants a few gigabytes of download and won't out-reason gpt-oss:120b no matter how nicely you ask it. A cloud model through Ollama with those retention terms is a defensible, well-documented choice. I just want you making it on purpose. See what private means here, what runs locally, and what bring-your-own-key actually buys you - which, per the Groq post, is exactly the settings the vendor chose to expose, and not one more.
Every Ollama quote, price and policy line above was read on Ollama's live pages - homepage, pricing, privacy policy, cloud docs and FAQ - on 8 September 2026, and the two terminal outputs are from my own machine on the same day running Ollama 0.32.14. All Humla claims are checked against the app's source at v0.56.0. These pages change; re-read them before you make a compliance decision on them.