Exposing Ollama to the internet safely

OLLAMA_HOST=0.0.0.0 is the first line of most Ollama-remote-access advice, and it's also where a lot of that advice stops. It's worth being specific about what that line actually does before combining it with a port forward or a plain tunnel: Ollama's API has no built-in authentication. Anyone who can reach the port can list your models, run inference on them, and pull new ones, with no login, no rate limit, and nothing in your logs identifying who.

What's actually at risk

• Compute theft. Someone else runs inference on your GPU or CPU, on your electricity, for free. This is the most common outcome of an openly exposed instance: it's a resource, and unattended resources get used.
• Denial of service. A large enough request, or enough concurrent ones, can pin your hardware and make the machine unusable for you. No exploit required, just an open door.
• Model or prompt disclosure. If you've built a system prompt or a RAG setup around private data, an unauthenticated caller can often extract more of that context than you intended, just by asking the model about itself.

None of this requires a sophisticated attacker. Port scanners index the whole IPv4 space continuously, and an open Ollama port on a default port number gets found in hours, not months.

What a safe setup actually needs

1. Keep Ollama bound to localhost. Never set OLLAMA_HOST=0.0.0.0 if the goal is remote access; that's solving the wrong layer. Ollama should only ever answer 127.0.0.1.
2. Put something with authentication in front of it. Amallo runs as an authenticated reverse proxy on the same machine: every request has to carry a valid key before it reaches Ollama at all, and the key is generated per install, not a default anyone can guess.
3. Make the key revocable without downtime. Regenerating Amallo's key invalidates the old one for every client immediately, useful the moment a key leaks into a shared config file or a screen-share.
4. Prefer outbound over inbound. Amallo holds one outbound connection to Relay rather than listening for inbound traffic. There's no port on your router for a scanner to find in the first place, which closes off the discovery step most opportunistic attacks depend on.

What this doesn't protect against

Authentication stops a stranger from reaching your models. It doesn't stop a model from being tricked by the content of a prompt, and it doesn't turn a system prompt into a secret. Treat anything you put in front of an LLM as something the LLM might eventually repeat back to whoever's talking to it, authenticated or not. That's a property of the model, not the transport, and no tunnel changes it.

The reasoning behind this tradeoff, and where the OpenAI-compatible path specifically stops being end-to-end encrypted, is laid out in full on the about page.