Is Your Local AI Open to the Internet?

A security report dropped this week that made me immediately check my own setup: researchers found 175,000 Ollama servers publicly accessible on the internet, spanning 130 countries.

That means tens of thousands of people set up local AI for privacy reasons — and then accidentally exposed it to anyone who cared to look.

If you followed my guide on running AI locally, or set up Ollama some other way, it's worth spending five minutes to make sure you're not one of them.

Why This Matters

When Ollama runs, it starts an API server. That server is how chat interfaces, coding tools, and other apps talk to your models.

By default, Ollama binds to localhost — meaning only your own machine can connect. Safe.

The problem: people change that default. Maybe they want to use Ollama from their phone, another computer, or a remote server. They set OLLAMA_HOST=0.0.0.0:11434 and suddenly it's listening on all network interfaces.

If your firewall doesn't block that port, congratulations — your AI is now available to the entire internet.

What's the Risk?

An exposed Ollama server lets anyone:

Use your hardware. Running inference costs money (electricity) and wears out your GPU. Attackers can use your machine for their own AI workloads, free.

Access your models. If you've fine-tuned or customized models, those are now available to anyone.

Execute code on your system. This is the scary one. Nearly half of the exposed servers had tool-calling capabilities enabled — meaning the AI could run code, access APIs, and interact with external systems. One creative prompt and someone could be running commands on your machine.

Steal your prompts. If you're using local AI for sensitive work, anyone watching your traffic could see exactly what you're doing.

This isn't theoretical. The researchers confirmed these systems are actively findable and accessible.

Check If You're Exposed

From Your Local Machine

First, check what Ollama is actually listening on:

Linux/Mac:

ss -tlnp | grep 11434
# or
netstat -tlnp | grep 11434

Windows:

netstat -an | findstr 11434

You want to see 127.0.0.1:11434 (localhost only). If you see 0.0.0.0:11434 or *:11434, Ollama is listening on all interfaces.

From Outside

Check if your home IP is exposing port 11434:

# Replace with your actual public IP
curl -s http://YOUR_PUBLIC_IP:11434/api/version

If you get a JSON response with Ollama's version, you're exposed.

Don't know your public IP? Run:

curl -s ifconfig.me

Or just check whatismyip.com.

Quick Online Check

Some port-checking services can test this for you:

• canyouseeme.org — enter port 11434
• yougetsignal.com/tools/open-ports

How to Fix It

Option 1: Bind to Localhost Only (Recommended)

If you don't need to access Ollama from other devices, bind it to localhost only.

Check if you've set OLLAMA_HOST anywhere:

# Check environment
echo $OLLAMA_HOST

# Check systemd service (Linux)
cat /etc/systemd/system/ollama.service | grep OLLAMA_HOST

If OLLAMA_HOST is set to 0.0.0.0, change it to 127.0.0.1:

OLLAMA_HOST=127.0.0.1:11434

Or just unset it entirely — the default is localhost.

After changing, restart Ollama:

# Linux systemd
sudo systemctl restart ollama

# Mac
brew services restart ollama

# Or just kill and restart
pkill ollama
ollama serve

Option 2: Block the Port on Your Firewall

If you need Ollama accessible on your local network but not the internet, block port 11434 on your router/firewall.

UFW (Ubuntu/Debian):

# Block from internet, allow local
sudo ufw deny in on eth0 to any port 11434

iptables:

# Block incoming from internet
sudo iptables -A INPUT -p tcp --dport 11434 -i eth0 -j DROP

Router firewall: Log into your router and block inbound traffic on port 11434. The exact steps depend on your router model.

Option 3: Put It Behind Authentication

If you genuinely need remote access, put a reverse proxy with authentication in front of it.

Nginx with basic auth:

server {
    listen 443 ssl;
    server_name ollama.yourdomain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
    }
}

Create the password file:

sudo htpasswd -c /etc/nginx/.htpasswd yourusername

Now Ollama is only accessible with credentials, over HTTPS.

Option 4: VPN/Tailscale

For the cleanest solution, use a VPN or Tailscale to access your home network remotely.

Ollama stays bound to localhost (safe), and you connect to your home network when you need access. No ports exposed, no firewall rules to maintain.

Tailscale is free for personal use and takes about 5 minutes to set up.

Best Practices Going Forward

Default secure, then relax. Start with Ollama bound to localhost. Only change it if you have a specific reason, and then add proper security.

Disable tool-calling if you don't use it. Tools that let the AI execute code or access APIs are powerful but increase risk significantly.

Keep Ollama updated. Security patches happen. Run ollama --version and check for updates periodically.

Monitor what's happening. Check Ollama's logs occasionally:

journalctl -u ollama -f  # Linux systemd

Assume your network is hostile. Even on your home network, devices get compromised. Defense in depth.

The Bigger Picture

I see this pattern constantly in self-hosted software: people set something up, tweak a setting to make it "work" from their phone, and accidentally expose it to the world.

It happens with home NAS boxes, security cameras, databases, and now AI servers.

The instinct to self-host is good — privacy matters. But "local" only means private if you actually keep it local.

Run the checks above. Fix it if needed. Then get back to using your AI in peace, knowing it's actually yours.