Ollama Has No API Authentication: How To Properly Gate Port 11434

Description and use

Ollama’s unauthenticated API on port 11434 exposes full control over models. The solution is to bind the server to 127.0.0.1 and/or place an SSH tunnel, VPN, or reverse proxy with bearer token in front of it, securing models, disk, and GPU.

Problem

Ollama’s HTTP API on port 11434 is unauthenticated, allowing anyone who can reach the port to list, pull, delete, and run inference on models, posing a severe security risk.

Outcome

By binding Ollama to localhost and/or placing a secure proxy or tunnel in front of it, users eliminate unauthenticated access to the API, protecting models, disk space, and GPU resources.

Workflow

• 1. Verify current bind address with OS‑specific commands (ss, lsof, netstat).
• 2. Test reachability from a local device and from outside the network to confirm exposure.
• 3. Audit the model directory for unexpected models or disk usage spikes.
• 4. Decide on a gating method based on user profile (local, VPN, SSH tunnel, reverse proxy).
• 5. Configure the chosen method: set OLLAMA_HOST to 127.0.0.1:11434 for local use; set up SSH tunnel or VPN; or deploy a reverse proxy with bearer token and HTTPS.
• 6. Apply platform‑specific environment settings (systemd unit, launchctl, Windows env vars).
• 7. Restart Ollama service or app to apply changes.
• 8. Re‑run reachability tests to confirm the port is no longer exposed.
• 9. Document the configuration and schedule periodic audits.

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