By default, Ollama only listens on localhost — it accepts connections from your own machine and ignores everything else. That’s fine for solo use, but if you want to query Ollama from another device on your network, run Open WebUI on a different machine, access it from a phone or tablet, or share it with someone else in your house, you need to open it up. This guide covers exactly how to do that on Windows, macOS, and Linux, plus how to keep it reasonably secure while you’re at it.
How Ollama’s Network Binding Works
Ollama listens for connections on a host address and port, controlled by the OLLAMA_HOST environment variable. The default is 127.0.0.1:11434 — the loopback address, which means only processes on the same machine can connect.
To accept connections from other devices, you change the host to 0.0.0.0:11434. The address 0.0.0.0 means “all network interfaces” — Ollama will listen on your Ethernet adapter, your Wi-Fi adapter, and any other network interface your machine has, accepting connections from any device that can reach those interfaces.
You can also bind to a specific IP address if you want to expose Ollama only on one interface — for example, 192.168.1.100:11434 to only accept connections on your local network interface, not a VPN or other adapter.
Setting OLLAMA_HOST on Windows
On Windows, set OLLAMA_HOST as a user environment variable so it persists across reboots:
- Search “Environment Variables” in the Start menu and open “Edit the system environment variables”
- Click “Environment Variables” at the bottom of the dialog
- Under “User variables”, click New
- Variable name:
OLLAMA_HOST - Variable value:
0.0.0.0:11434 - Click OK on all dialogs
Then restart the Ollama service — right-click the Ollama icon in your system tray and choose Quit, then relaunch Ollama from the Start menu. The new setting takes effect on restart.
Verify it’s listening on the right address by running this in PowerShell:
netstat -ano | findstr 11434
You should see a line with 0.0.0.0:11434 in the Local Address column and LISTENING in the State column. If you still see 127.0.0.1:11434, the environment variable didn’t take effect — double-check the variable name and restart Ollama again.
Setting OLLAMA_HOST on macOS
On macOS, set the variable via launchctl before restarting the Ollama app:
launchctl setenv OLLAMA_HOST 0.0.0.0:11434
Then click the Ollama icon in the menu bar → Quit, and relaunch Ollama from Applications. The environment variable is picked up on restart.
To make this permanent across reboots, add a LaunchAgent or add the export to your shell profile. The launchctl setenv approach doesn’t survive a reboot — each login you’d need to run it again, which is fine for occasional use but annoying for a persistent setup. The reliable approach is a LaunchAgent plist, covered in the Mac Ollama setup guide.
Setting OLLAMA_HOST on Linux
For a systemd-managed Ollama installation (the standard Linux install), use a systemd override:
sudo systemctl edit ollama
Add inside the [Service] block:
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Save, then reload and restart:
sudo systemctl daemon-reload
sudo systemctl restart ollama
Verify with:
ss -tlnp | grep 11434
You should see 0.0.0.0:11434 in the output.
Figure 1 — Ollama Network Exposure: Setup by Platform
Opening the Firewall
Changing OLLAMA_HOST makes Ollama listen on the right address, but your OS firewall may still block incoming connections on port 11434. You need to open it explicitly.
Windows Firewall: Search for “Windows Defender Firewall with Advanced Security” in the Start menu. Go to Inbound Rules → New Rule → Port → TCP → Specific local ports: 11434 → Allow the connection → apply to Domain, Private (you probably don’t need Public) → name it “Ollama API”.
Or do it from PowerShell in one line:
New-NetFirewallRule -DisplayName "Ollama API" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow
macOS Firewall: If your Mac firewall is enabled (System Settings → Privacy & Security → Firewall), you may need to explicitly allow Ollama incoming connections. When you first run Ollama after enabling network access, macOS may prompt you — click Allow. If you missed the prompt, go to Firewall Options and add Ollama manually.
Linux (ufw):
sudo ufw allow 11434/tcp
sudo ufw status # confirm it's open
If ufw is disabled on your system (sudo ufw status shows “inactive”), you don’t need to do anything — there’s no firewall blocking the port.
Testing the Connection from Another Device
First, find your machine’s local IP address:
# Windows
ipconfig # look for IPv4 Address under your active adapter
# macOS
ipconfig getifaddr en0 # en0 for Wi-Fi, en1 for Ethernet
# Linux
ip addr show # look for inet address on eth0 or wlan0
Then from another device on the same network, open a browser or run curl:
curl http://192.168.1.100:11434
Replace 192.168.1.100 with your machine’s actual IP. You should get back:
Ollama is running
If you get a connection refused or timeout, work through this checklist: Ollama is running (check system tray or systemctl status ollama), OLLAMA_HOST is set to 0.0.0.0:11434 and Ollama was restarted after setting it, the firewall port is open, and both devices are on the same network (not one on VPN or a different subnet).
Connecting Open WebUI to a Remote Ollama Instance
One of the most common reasons to expose Ollama to the network is to run Open WebUI on a separate machine — for example, on a laptop connecting to Ollama running on a desktop. Once Ollama is network-accessible, point Open WebUI at it via the OLLAMA_BASE_URL environment variable:
docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=http://192.168.1.100:11434 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main
Replace 192.168.1.100 with the IP of the machine running Ollama. Open WebUI will proxy all model requests to the remote Ollama instance — you get the full UI experience without Ollama running locally on the WebUI machine.
Security Considerations
Ollama’s API has no authentication by default. Anyone who can reach port 11434 on your machine can list your models, run inference, and pull new models. On a home network with trusted devices, this is usually fine. But a few things are worth being aware of:
Don’t expose port 11434 to the public internet. If you need remote access from outside your home network, use a VPN (WireGuard or Tailscale are both excellent for this) rather than port forwarding through your router. Tailscale in particular is very easy to set up and gives you secure remote access to your Ollama instance without exposing anything publicly.
If you need basic access control on your local network — for example, you’re sharing Ollama with a small team and want to restrict who can use it — put Nginx in front of Ollama as a reverse proxy and add HTTP Basic Authentication at the Nginx layer. Ollama itself doesn’t have built-in auth, but Nginx handles it cleanly.
If you’re on a corporate network or a shared Wi-Fi (hotel, café, university), be particularly careful — 0.0.0.0:11434 means Ollama is reachable by everyone on that network, not just your own devices. Use 127.0.0.1:11434 (the default) in those environments.
Figure 2 — Ollama API: Useful Endpoints Once Exposed
Using the Remote API from Python
Once Ollama is accessible on the network, any device on that network can use it as an API backend. From a Python script on another machine, set the host explicitly:
import ollama
# Point the client at the remote Ollama instance
client = ollama.Client(host='http://192.168.1.100:11434')
response = client.chat(
model='llama3.2',
messages=[{'role': 'user', 'content': 'Hello from another machine!'}]
)
print(response['message']['content'])
Or use the OpenAI Python SDK pointed at the Ollama instance — useful if you’re building something that should work with either OpenAI or local Ollama:
from openai import OpenAI
client = OpenAI(
base_url='http://192.168.1.100:11434/v1',
api_key='ollama' # any non-empty string works
)
response = client.chat.completions.create(
model='llama3.2',
messages=[{'role': 'user', 'content': 'Tell me something interesting.'}]
)
print(response.choices[0].message.content)
Exposing Ollama to your local network turns a single-machine AI setup into something you can share across all your devices — your phone, your tablet, your other computers — without running a model on each one. A capable desktop running Ollama becomes a shared inference server for your whole home or small office network, with all the heavy lifting centralised on one machine.
Using Tailscale for Secure Remote Access
Tailscale is the cleanest way to access your Ollama instance from outside your home network — from a coffee shop, a hotel, or anywhere else. Tailscale creates a private mesh VPN between your devices using WireGuard under the hood. Install it on both the machine running Ollama and the device you want to access from, sign in with the same account, and both devices appear on a private network with stable IP addresses. You can then hit your Ollama instance at its Tailscale IP (http://100.x.x.x:11434) from anywhere as if you were on the same local network. No port forwarding, no public exposure, no credentials beyond your Tailscale account. The free tier covers personal use comfortably — up to 3 users and 100 devices. Combined with Ollama’s network exposure setup above, it gives you a private, secure, globally accessible local LLM backend reachable from all your devices.
Troubleshooting: Connection Refused vs Timeout
When connecting to Ollama from another device fails, the error type tells you where to look. A “connection refused” error means the connection reached your machine but nothing was listening on that port — either Ollama isn’t running, or it’s still bound to localhost rather than 0.0.0.0. Check netstat -ano | findstr 11434 (Windows) or ss -tlnp | grep 11434 (Linux) to see what address Ollama is actually listening on. A timeout error means the connection never reached your machine — the firewall is dropping packets. Open the firewall port for TCP 11434 and try again. If you’re on macOS and see neither error but just get no response, check that the Ollama app is actually running (menu bar icon visible) and that you restarted it after setting the environment variable — the variable change only takes effect after a full restart of the app, not just a model reload.