Securing Ollama

What this article covers

• Why Ollama is unsafe on the network by default.
• How to restrict access to your local network.
• How to set up a reverse proxy with authentication.
• How to enable secure remote access with Tailscale or a VPN.
• Essential firewall and system rules.

Introduction: securing Ollama

By default, Ollama listens on 127.0.0.1:11434 and provides no built-in authentication. Once you expose the service on your network, anyone with access can interact with your models, send prompts, and potentially query data from the runtime environment. Properly securing Ollama becomes essential the moment you need to share it across multiple devices.

This article walks through securing Ollama with network isolation, firewall rules, reverse proxies, and VPN setup.

Key terms

• Bind: The network interface on which Ollama listens.
• Firewall: Rule-based network protection.
• Reverse Proxy: An intermediary between clients and Ollama.
• Authentication: Verification of who is allowed to access.
• Tailscale: A mesh VPN for secure remote access.
• mTLS: Mutual TLS authentication.
• API Key: A secret token for authenticated access.

Ollama’s default behavior

Without any configuration, Ollama is only reachable on localhost. This is secure as long as everything runs on a single machine. The moment you want to connect another host on your network, you must bind Ollama to an external interface. But then the service becomes potentially accessible to anyone on that network.

Restricting network binding

To allow access from your local network:

export OLLAMA_HOST=0.0.0.0:11434

A better approach is to bind to a specific interface:

export OLLAMA_HOST=192.168.1.50:11434

This way, Ollama only listens on your internal address, not on all interfaces.

Firewall rules

On a Proxmox host or Linux server, the Ollama port should not be exposed to the internet. Here’s an example using iptables:

iptables -A INPUT -p tcp --dport 11434 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 11434 -j DROP

On Proxmox, you can configure appropriate rules in the integrated firewall at the datacenter and LXC/VM levels.

Reverse proxy with authentication

A reverse proxy like Nginx or Traefik can expose the Ollama port while enforcing authentication. Here’s an Nginx example:

server {
    listen 443 ssl;
    server_name ollama.home.local;

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

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Now Ollama is accessible only with a username and password.

Tailscale for remote access

Instead of exposing Ollama publicly, you can use Tailscale:

• Ollama stays bound to 127.0.0.1.
• Clients connect to the host over Tailscale.
• All communication is encrypted.
• No public ports required.

Ollama behind Open WebUI

Open WebUI can act as a central gateway. Ollama itself remains unreachable from the network, while Open WebUI accesses it locally. Users authenticate through Open WebUI. This significantly simplifies your security model.

-e OLLAMA_BASE_URL=http://localhost:11434
-p 8080:8080

Open WebUI gets port 8080, while Ollama stays local.

API keys via a proxy

Ollama has no native API key support. If you need key-based authentication, you can use a proxy like oauth2-proxy, Traefik, or Caddy with forward authentication. Alternatively, middleware solutions can validate API keys before forwarding requests to Ollama.

mTLS

For maximum security, you can use mTLS between clients and your reverse proxy. Both sides verify each other using certificates. This approach works well for automated agents and internal services.

Docker and container security

When running Ollama in Docker:

• Bind port 11434 only to 127.0.0.1: -p 127.0.0.1:11434:11434.
• Do not run as root.
• Use --read-only and --security-opt no-new-privileges.
• Minimize capabilities.

Logs and monitoring

Access logs help you spot unusual activity. Reverse proxies write HTTP logs. Ollama itself logs sparingly, so the proxy or a gateway in front of it becomes important for visibility.

Common pitfalls

• Binding Ollama to 0.0.0.0: The port becomes accessible everywhere.
• No authentication: Anyone on the network can use your models.
• An open port on the internet: This can be exploited quickly.
• Open WebUI without protection: Authentication should be active here too.
• Forgotten firewall rules: Isolate networks where possible.

Further reading

• BotServ.de Tailscale basics
• BotServ.de Proxmox LXC vs. VM
• BotServ.de Proxmox Storage
• BotServ.de Open WebUI administration

FAQ: securing Ollama

Do I need authentication for Ollama? Yes, once more than one device accesses it.

Does Ollama support API keys natively? No, a reverse proxy or another tool must handle that.

Is Tailscale secure enough? Yes, it’s an excellent solution for remote access.

Should I expose Ollama to the internet? No. If absolutely necessary, only behind a reverse proxy with authentication, TLS, and rate limiting.

What’s the safest way to offer Ollama on the network? Keep Ollama on 127.0.0.1 and expose it via Open WebUI or a protected reverse proxy.

Sources and further reading

• Ollama Docs: https://github.com/ollama/ollama/blob/main/docs/
• Nginx Reverse Proxy: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• Tailscale: https://tailscale.com/

Summary: securing Ollama

Ollama is not designed for network access without additional measures. If you want to use Ollama on your local network or remotely, restrict the bind address, set firewall rules, enforce authentication through a reverse proxy, and secure remote connections with Tailscale. Open WebUI can serve as a protected gateway while Ollama itself remains accessible only locally. By layering these protections, you get secure access to your local AI models.