Ollama Local-Only: The Boundary the Setting Really Creates

“Local AI” can describe several different properties. A client may connect to an API on the same machine while inference happens remotely. A model may run locally even though another part of the workflow accesses the internet. Ollama’s cloud features may be disabled without establishing that every process on the host is isolated from the network.

Ollama’s current documentation provides specific controls for disabling its cloud features. It also identifies local and remote API paths and explains that cloud models are offloaded to Ollama’s service. Together, those details provide a useful configuration boundary—but not proof of zero outbound traffic.

Scope: This article explains current official Ollama documentation. No network-isolation test was performed, and no particular configuration or complete workflow was observed to remain offline. The cited pages do not identify the product version or date on which these controls were introduced.

Four meanings of “local”

Before configuring Ollama, define what the project needs:

1. Local API access: The client sends its request to an Ollama service on the same computer.
2. Local inference: The selected model runs on hardware inside the intended boundary.
3. Ollama cloud features disabled: Ollama cloud models and web search are unavailable.
4. Whole-workflow isolation: Every component within a defined scope produces no outbound network traffic.

These properties can overlap, but none automatically establishes all the others.

For an installed Ollama service, the documented default API base URL is http://localhost:11434/api. Ollama separately documents https://ollama.com/api for cloud models hosted on ollama.com (API introduction).

That endpoint distinction identifies where a client initially sends its request. It does not necessarily identify where inference runs. Ollama says cloud models are automatically offloaded to its cloud service while allowing users to continue working with local tools (cloud-model documentation). A local interface can therefore participate in remote inference.

A useful review separates the available evidence:

The two documented cloud controls

Ollama’s FAQ provides two ways to disable its cloud features.

Configuration file

Set disable_ollama_cloud to true in ~/.ollama/server.json:

{
  "disable_ollama_cloud": true
}

The path, setting name, and value are specified in Ollama’s FAQ (FAQ: disabling cloud features). The supplied documentation does not describe platform-specific alternatives to this path.

Environment variable

The documented alternative is:

OLLAMA_NO_CLOUD=1

Ollama presents this environment variable as another way to disable its cloud features (FAQ: disabling cloud features).

The documentation does not specify precedence if the environment variable and server.json contain conflicting values. Avoid that unresolved case by using one mechanism or keeping both values consistent.

Restart and check the reported state

After changing the configuration, restart Ollama. The FAQ says its logs will then show:

Ollama cloud disabled: true

This line indicates that Ollama reports the cloud-disabled state (FAQ: disabling cloud features). It is a configuration check, not a packet-level test of the process or the wider system.

What disabling cloud features changes

According to Ollama, disabling its cloud features removes access to two named capabilities:

• Ollama cloud models
• Web search

Those are the effects expressly documented in the FAQ (FAQ: disabling cloud features). The page does not provide an exhaustive inventory of every possible outbound action by Ollama, external integrations, other applications, or operating-system services.

Cloud models are a documented remote execution path. Ollama says these models are automatically offloaded to its cloud service and require an ollama.com account. Its documented sign-in command is ollama signin (cloud-model documentation).

There is also a direct remote API path. In that mode, ollama.com acts as the remote Ollama host. Requests target https://ollama.com/api, and authentication uses an API key supplied through OLLAMA_API_KEY (cloud-model documentation). This is distinct from targeting the installed service through its default localhost address.

A documentation-based configuration review can therefore check that:

1. The client targets the installed API at http://localhost:11434/api.
2. The requested model is not one of the cloud models being intentionally offloaded through Ollama’s documented cloud path.
3. Either disable_ollama_cloud or OLLAMA_NO_CLOUD=1 is set.
4. Ollama has been restarted after the change.
5. The logs report Ollama cloud disabled: true.

The CLI reference documents ollama ls for listing models and ollama ps for listing running models (CLI reference). These commands can help inspect the current setup, but Ollama does not describe them as network-verification tools.

What requires separate testing

A stronger requirement such as “this workflow produces no outbound traffic” needs a precise boundary. A test or enforcement plan should answer:

• Scope: Is the boundary one process, a container, a virtual machine, or the whole host?
• Workflow: Does it cover startup, inference, tool calls, idle periods, and shutdown?
• Participants: Which clients, agents, integrations, and system services are included?
• Evidence: Are attempted connections, successful connections, or both being examined?
• Policy: Is outbound activity merely observed, or technically blocked?

Preparation and routine operation may also need separate treatment. Ollama documents ollama pull as the command for downloading a model (CLI reference). A project might allow network access while acquiring resources and impose a different boundary during inference. Those are separate stages and should not be collapsed into one locality claim.

The practical decision rule has three levels. Documented: the settings disable Ollama cloud models and web search. Observed: a separately designed test can evaluate the chosen process and workflow. Enforced: network controls can restrict communication within a defined boundary. Use the first claim when documentation is sufficient; require the latter two when “local-only” must mean more than Ollama’s cloud-feature setting.

Sources and further reading

• https://docs.ollama.com/api/introduction
• https://docs.ollama.com/cloud
• https://docs.ollama.com/faq#how-do-i-disable-ollama-cloud-features
• https://docs.ollama.com/cli