Securing Ollama’s Unauthenticated API by Gating Port 11434

Description and use

Ollama exposes port 11434 without authentication, letting any connected device manage models. The fix is to keep the bind to 127.0.0.1 or put a VPN, SSH tunnel, or token/mTLS proxy in front to gate access.

Problem

Ollama’s HTTP API on port 11434 is unauthenticated; any host that can reach the port can list, pull, delete, and run inference on models, exposing sensitive data, GPU resources, and disk space.

Outcome

By keeping Ollama bound to 127.0.0.1 or placing a secure boundary (VPN, SSH tunnel, or reverse proxy) in front of it, the unauthenticated API is effectively gated, eliminating the risk of unauthorized model manipulation, inference, or disk exhaustion.

Workflow

• 1. Verify current bind address with ss/lsof/netstat and test reachability from another device.
• 2. If exposed, stop Ollama and audit model directory for unknown models.
• 3. Decide on a protection method based on use case (loopback, VPN, SSH tunnel, reverse proxy).
• 4. Configure the chosen method: set OLLAMA_HOST to 127.0.0.1 for local use; set up Tailscale/WireGuard for mesh VPN; create an SSH tunnel; or deploy a reverse proxy with bearer token/mTLS.
• 5. Restart Ollama with the new environment variable via systemd, launchctl, or Windows env.
• 6. Re‑test reachability from an external device to confirm the port is no longer exposed.
• 7. Monitor logs and model directory for unauthorized activity.

Evidence

Ollama has no username, no password and no API key. Anything that can reach TCP port 11434 can list your models, run inference on your GPU, pull a 40 GB model onto your disk and delete every model you have, with a single curl command and no credential.

Source

The fix is not a setting inside Ollama, because there is not one: you keep the default bind on 127.0.0.1, and if you genuinely need remote access you put a bearer token proxy, an SSH tunnel or a mesh VPN in front of it.

Source

Anything curl can send, a stranger can send.

Source