Intermediate 📅 Last Updated: July 1, 2026 ⏱️ 12 min read 🔒 Security
Default Ollama binds to 127.0.0.1:11434 — that is safe. The danger is when people set OLLAMA_HOST=0.0.0.0 to access it from another machine, exposing it to the entire network or internet with zero authentication. Open WebUI without a password, API keys in config files, and shared model directories are the other top mistakes. This guide shows you how to check if you're exposed and lock everything down.
Thousands of Ollama and Open WebUI instances are publicly accessible right now. People set OLLAMA_HOST=0.0.0.0 to use their AI from a phone, forget about it, and their entire model server is open to the internet. This is not theoretical — it is happening daily. Read this before you expose anything.
Read this if: You run Ollama, Open WebUI, or any local AI server — especially if you access it from another device, have it on a server, or followed a tutorial that mentioned 0.0.0.0.
Everyone running local AI should read this. No exceptions.
Machine: MSI laptop (dual GPU)
GPU 1: NVIDIA RTX 5070 Ti Laptop (12GB)
GPU 2: NVIDIA RTX 5070 (12GB)
CPU: Intel Core Ultra 7 255HX (20 cores)
RAM: 96GB
OS: Ubuntu 26.04 LTS
Date: July 2026
This is the #1 security mistake. Ollama's default is 127.0.0.1 (localhost only — safe). But many tutorials tell you to change it to 0.0.0.0 to access Ollama from other devices. This binds to every network interface, including your public IP if you're not behind NAT.
# Check what address Ollama is listening on
ss -tlnp | grep 11434
# SAFE output (localhost only):
# LISTEN 127.0.0.1:11434
# DANGEROUS output (exposed to all interfaces):
# LISTEN 0.0.0.0:11434
# LISTEN *:11434
# Edit the Ollama service environment
sudo systemctl edit ollama
# Add this under [Service]:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
# Save, then restart:
sudo systemctl restart ollama
# Verify it's locked down:
ss -tlnp | grep 11434
# Should show: LISTEN 127.0.0.1:11434
If you legitimately need to access Ollama from another machine, do not use 0.0.0.0. Instead: (1) Use a VPN like Tailscale or WireGuard to connect securely, or (2) Use an SSH tunnel: ssh -L 11434:localhost:11434 user@server, or (3) Put it behind a reverse proxy (nginx/Caddy) with authentication.
Open WebUI is a full chat interface. If it's exposed without a login, anyone who finds it can: use your models (burning your GPU), read your chat history, upload files to your server, and potentially access your file system depending on configuration.
# If Open WebUI is running in Docker, check the port binding:
docker ps | grep webui
# DANGEROUS: 0.0.0.0:3000->8080/tcp (exposed to network)
# Check if auth is enabled — visit the URL in a browser
# If you get a chat interface with NO login screen, it's open
# Always run Open WebUI with authentication enabled.
# In your Docker run command or compose file, ensure:
docker run -d -p 127.0.0.1:3000:8080 \
-e WEBUI_AUTH=True \
-v open-webui:/app/backend/data \
--name open-webui \
ghcr.io/open-webui/open-webui:main
# Note the 127.0.0.1:3000 binding — localhost only.
# The first user to register becomes the admin.
# Add a strong password immediately.
Key principles: bind to 127.0.0.1 only, enable WEBUI_AUTH=True, and use a reverse proxy with HTTPS if you need remote access.
If you use Open WebUI or any tool with API keys (OpenAI, Anthropic, etc.), those keys are often stored in config files or environment variables. If those files are readable or your server is exposed, your keys can be stolen and used to rack up charges.
# BAD: Hardcoded in docker-compose.yml (visible in git, readable by anyone)
environment:
- OPENAI_API_KEY=sk-proj-abc123yourrealkey
# GOOD: Reference from environment file that is gitignored
environment:
- OPENAI_API_KEY=${OPENAI_API_KEY}
# .env file (chmod 600 and add to .gitignore):
OPENAI_API_KEY=sk-proj-abc123yourrealkey
# Lock down the file:
chmod 600 .env
echo ".env" >> .gitignore
If you've ever committed an API key to git, it's in your history forever. Rotate (revoke and regenerate) any key that has been in a git repo, even if you removed it in a later commit.
Even if you accidentally expose a service, a firewall can save you. Ubuntu ships with UFW — use it.
# Enable UFW (Ubuntu/Debian)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh # Don't lock yourself out!
sudo ufw allow from 192.168.1.0/24 to any port 11434 # LAN only, if needed
sudo ufw enable
# Verify:
sudo ufw status verbose
# Ollama port should NOT be open to the world:
sudo ufw status | grep 11434
# Should show: ALLOW from 192.168.1.0/24 (or nothing if local-only)
Ollama stores models in /usr/share/ollama/.ollama/models (or ~/.ollama/models). If multiple users share a machine and this directory is readable, anyone can access or tamper with your models.
# Check permissions:
ls -la /usr/share/ollama/.ollama/
# Fix: Ensure only the ollama user can access:
sudo chown -R ollama:ollama /usr/share/ollama/.ollama
sudo chmod -R 700 /usr/share/ollama/.ollama
| Check | Command | Expected (Safe) |
|---|---|---|
| Ollama bound to localhost | ss -tlnp \| grep 11434 | 127.0.0.1:11434 |
| Open WebUI bound to localhost | docker ps \| grep webui | 127.0.0.1:3000 |
| Open WebUI auth enabled | Visit URL in browser | Login screen appears |
| Firewall active | sudo ufw status | Status: active |
| No API keys in git | git log -p \| grep -i key | No real keys found |
| Model dir locked | ls -la ~/.ollama/ | drwx------ |
Run the six checks above right now. If any show a problem, fix it before doing anything else. If you need remote access to your local AI, use Tailscale (free, zero-config VPN) — it's dramatically safer than exposing ports. Never run
OLLAMA_HOST=0.0.0.0without a firewall and reverse proxy in front. Security is not optional when you're running a model server.
Exposing the Ollama API (port 11434) or Open WebUI (port 3000) to the public internet without authentication. Always bind to localhost (127.0.0.1) instead of 0.0.0.0. Use a VPN or Cloudflare Tunnel for secure remote access.
If exposed, attackers can use your GPU resources, access chat history, or generate harmful content traced to your IP. Open WebUI without auth lets anyone read conversations and documents. Always use firewalls and authentication.
Models have safety training but can produce biased or inappropriate content with adversarial prompts. Unlike cloud APIs, there are no server-side content filters. You are responsible for monitoring output, especially in customer-facing applications.
Local models do not send data anywhere - a major privacy advantage. However, models can memorize and reproduce training data. If you fine-tune on private data, it could theoretically be extracted from weights. Avoid fine-tuning on highly sensitive information.
Run containers with least privilege: non-root users, read-only mounts for sensitive dirs, and resource limits. Never mount your entire home directory. Use Docker network isolation and regularly update images for security patches.
The $19 Starter Kit includes a printable security checklist, firewall config templates, Docker compose files with proper auth, and a Tailscale setup guide. Don't guess — follow the checklist.
Get the Starter Kit →Send me your setup details. I will check your configuration and tell you exactly what to fix. $99 Setup Review includes a full security audit.
Get a Security Audit →Get the free Local AI Setup Checklist delivered to your inbox.
Get the Free ChecklistLast Updated: July 1, 2026 — Security practices verified on Ubuntu 26.04 LTS with Ollama and Open WebUI.