Full Offline Ollama: Block All Telemetry and External Traffic

One of the core reasons to run AI locally is data sovereignty — your prompts, documents, and outputs stay on your hardware, not on a third-party server. Ollama is designed with this in mind: inference happens entirely on-device, and no prompt content is transmitted externally by default.

That said, like most software, Ollama can make outbound network connections for purposes unrelated to inference — update checks, version pings, and similar housekeeping. For personal use this is usually not a concern. For corporate environments, regulated industries, or anyone handling sensitive data on an air-gapped network, it's worth understanding what leaves the machine and how to lock it down completely.

What Ollama sends by default

Ollama's outbound traffic is minimal and not privacy-invasive by cloud-service standards, but it's worth knowing what to expect:

• LOW
  Update checks

  Ollama periodically checks its own release endpoint to notify you of new versions. This sends your current Ollama version and OS type — no user data, no prompt content.

• MODEL DL
  Model manifest fetches

  When you run "ollama pull" or "ollama run" a new model, Ollama contacts the Ollama model registry (registry.ollama.ai) to download the model manifest and weights. This is expected behavior during model acquisition — not during inference.

• NONE
  No prompt telemetry

  Ollama does not transmit prompt content, responses, or conversation history. Inference is fully local. This has been confirmed by independent network traffic analysis of the open-source codebase.

Disable update checks

The simplest step is to disable the update check mechanism via environment variable. Set OLLAMA_NO_UPDATE_CHECK=1 before starting Ollama and it will skip outbound version checks entirely.

Linux and macOS

# Set for the current shell session only
export OLLAMA_NO_UPDATE_CHECK=1

# Set permanently — add to ~/.bashrc or ~/.zshrc
echo 'export OLLAMA_NO_UPDATE_CHECK=1' >> ~/.zshrc
source ~/.zshrc

# Verify it's set
echo $OLLAMA_NO_UPDATE_CHECK
1

Windows

# PowerShell — set for current session
$env:OLLAMA_NO_UPDATE_CHECK = "1"

# PowerShell — set permanently (user scope, survives reboots)
[System.Environment]::SetEnvironmentVariable("OLLAMA_NO_UPDATE_CHECK", "1", "User")

# Alternatively: System Properties → Advanced → Environment Variables
# Add new User variable: OLLAMA_NO_UPDATE_CHECK = 1

Linux with systemd service

If Ollama runs as a systemd service (the default on Linux after using the official install script), environment variables set in your shell won't be inherited by the service. Use a systemd override file instead:

# If Ollama runs as a systemd service (Linux install script default)
# Edit the service override file
sudo systemctl edit ollama

# Add the following block in the editor that opens:
[Service]
Environment="OLLAMA_NO_UPDATE_CHECK=1"
Environment="OLLAMA_ORIGINS=http://localhost"

# Reload and restart
sudo systemctl daemon-reload && sudo systemctl restart ollama

Firewall rules for full isolation

For environments where environment variables alone aren't sufficient — or where you want a hard network-layer guarantee — use firewall rules to block all outbound traffic from the Ollama process while keeping the local API port accessible. On Linux with ufw:

# Allow the Ollama API port from localhost only
sudo ufw allow from 127.0.0.1 to any port 11434

# Deny all outbound traffic from the ollama binary
# First, find the ollama binary path
which ollama
/usr/local/bin/ollama

# Block outbound connections by user (Ollama runs as system user 'ollama')
sudo ufw deny out from any to any user ollama

# Enable and check rules
sudo ufw enable
sudo ufw status numbered

On macOS, the built-in Application Firewall (System Settings → Privacy & Security → Firewall → Firewall Options) lets you block incoming connections per-application. For outbound control you'll need a third-party tool like Little Snitch or Lulu (free, open-source) — both allow you to create per-process outbound rules with a GUI prompt when an app first tries to connect.

On Windows, the built-in Windows Defender Firewall supports outbound rules. Open Windows Defender Firewall with Advanced Security, add an Outbound Rule, select "Program", point it at %LOCALAPPDATA%\Programs\Ollama\ollama.exe, and set the action to "Block".

Verify with netstat or ss

After applying your configuration, confirm that Ollama only holds local connections. Run the following while Ollama is running and actively serving a model:

# Linux — list active connections from the ollama process
ss -tupn | grep ollama

# Expected output (only localhost connections — no external IPs):
tcp   LISTEN  0  128  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=12345,fd=7))

# macOS — equivalent check
lsof -i -n -P | grep ollama

# Windows PowerShell
Get-NetTCPConnection | Where-Object { $_.OwningProcess -eq (Get-Process ollama).Id }

The output should list only connections to 127.0.0.1 or ::1 (IPv6 localhost). Any connection to an external IP address warrants investigation. For deeper inspection, Wireshark with a filter of udp.port != 5353 && ip.src == <your-machine-ip> will capture all non-mDNS outbound traffic during an inference session.

Is this necessary for most users?

For everyday personal use, no — Ollama is already orders of magnitude more private than cloud AI services. Your prompts never leave the machine, and the update-check traffic that does exist is minimal and non-identifying.

The steps in this guide are most relevant for corporate deployments handling regulated data (healthcare, legal, financial), teams building on air-gapped infrastructure, or anyone with a specific compliance requirement that prohibits any outbound traffic from AI tooling. If that's your context, the environment variable and firewall approach above gives you a verifiable, auditable baseline.