Keep an Ollama workflow local.

Define the boundary

Write down the app, server, model store and client involved. Downloading weights and running inference are different phases. A local model can work without a network after its required artifacts are present, but a client may still use remote search, remote assets or its own analytics. The acceptance task is to test this exact workflow, not to certify a whole operating system.

Prepare before going offline

Install the intended version and obtain permitted model artifacts on your own test machine. Record the installed-model digest. Keep a backup of existing server settings and note the previous environment configuration. Do not remove an existing authenticated or production setup to test this guide.

Configure the server you own

The official FAQ documents OLLAMA_NO_CLOUD and a disable_ollama_cloud configuration setting. For a temporary POSIX-shell server, first quit any existing test instance so the port is free, then set the environment for that process. Desktop apps and system services inherit settings differently; use their platform instructions instead of assuming a terminal variable changes the app.

OLLAMA_NO_CLOUD=1 OLLAMA_HOST=127.0.0.1:11434 ollama serve

Verify configuration and placement

After restarting, inspect the log for the cloud-disabled state and inspect the actual listener address with your OS network tools. Save only the relevant sanitized line, not the full private log. List local models and select an installed one. Do not choose a cloud-labelled model or an uninstalled alias that would require a download.

curl --fail http://127.0.0.1:11434/api/tags

Run an offline acceptance

Disconnect networking only on an authorized test machine with a recovery path. Send the same small local request you used before disconnecting, and exercise the client features you actually need. Expected evidence is a completed response from the same installed digest while external networking is unavailable. The website does not toggle networking or call your model server. If only the API succeeds, record the client as unverified.

Separate three acceptance questions

First, confirm the listener is actually bound to 127.0.0.1 rather than all network interfaces. Second, confirm the runtime’s documented cloud-disable setting after restart. Third, exercise the full client and its required features without external networking. A pass for one boundary does not imply a pass for the other two. Browser extensions, web search and remote client assets belong to the client check rather than the model-server check.

Diagnose a partial pass

If the local API works but the client fails, inspect the client's remote dependencies and model selection. If the model is absent, reconnect only to acquire the permitted artifacts, then repeat acceptance. If the disabled-cloud setting is missing from the process log, check which process owns the port and how that process receives its environment. A blocked connection is a useful observation, not proof of comprehensive privacy.

Restore deliberately

Stop the temporary server with Ctrl+C. Restore the previous settings and restart only your own app or service. Record whether the offline test passed, failed or was not run; the current page is not run. Keep personal prompts, account material and complete logs outside a public reproduction package. Recheck the boundary when either the client or runtime version changes.

Sources & change log

1. Ollama FAQ ↗Checked 2026-10-17 · Local-only configuration, loopback binding, processor reporting and memory caveats.
2. Ollama list models API ↗Checked 2026-10-17 · Installed-model digest capture.
3. Ollama generate API ↗Checked 2026-10-17 · Local request fields and response shape.

17 Oct 2026 · Revision 2. Source-based task guide and downloadable resource. Source documentation inspected; environment reproduction not run. Moving documentation may change after review.