AI
"Rigid old corporate firewalls" usually means two things at once: outbound traffic only leaves through a monitored HTTP(S) proxy with a TLS-inspecting certificate, and nobody is installing new software or opening new ports without a change request. A local model runner has to work within both constraints — it isn't just about running inference offline, it's about getting the runtime installed and its (occasional) network calls routed through infrastructure the security team already controls.
The Two Real Problems
1. Getting model weights in. Runtimes like Ollama pull models directly from the internet by default, which a locked-down network won't allow. The practical fix is a two-machine handoff: pull the model on a machine that has internet access, then copy the model files to the restricted machine.
2. Routing the runtime's own traffic through the corporate proxy. Even "local" runners phone home occasionally (update checks, optional cloud features) unless told not to, and if your workflow does call an external API for anything, it needs to go through the proxy your firewall expects — with the proxy's own TLS certificate trusted, or every HTTPS connection fails with a certificate error.
# 1. On a machine WITH internet access: pull the model normally
ollama pull llama3.1:8b
# Ollama stores models on disk in a plain directory, not inside a container -
# find the location with:
echo $OLLAMA_MODELS # defaults to ~/.ollama/models (macOS/Linux)
# Copy that whole directory to the restricted machine (USB, internal file share, etc.)
# then point Ollama at it there:
export OLLAMA_MODELS=/path/to/copied/models
# 2. Route Ollama's own outbound calls through the corporate proxy.
# Ollama only pulls over HTTPS, so only set HTTPS_PROXY - setting HTTP_PROXY
# too can interrupt the client's own connection to the local server.
export HTTPS_PROXY=https://proxy.internal.example.com:8080
# If the proxy does TLS inspection (most enterprise proxies do), the proxy's
# own CA certificate has to be trusted by the OS, or every pull will fail
# with a TLS handshake error - this is not an Ollama-specific step.| Environment Variable | Purpose | Notes |
|---|---|---|
OLLAMA_MODELS |
Points Ollama at a model directory that isn't the default | Used to load models copied in manually, without a network pull |
HTTPS_PROXY |
Routes Ollama's outbound HTTPS calls through a corporate proxy | Ollama's own docs say to avoid also setting HTTP_PROXY, since it only pulls over HTTPS and that variable can interrupt local client connections |
None of this is exotic — it's the same "get the artifact past the perimeter, then get the runtime talking through the approved egress path" pattern IT teams already apply to any new piece of self-hosted software. The main thing that trips people up is assuming a "local" AI tool has zero network dependencies; in practice the model weights and the runtime binary both cross the perimeter at some point, so it's worth planning both.
Practical Challenge
On a machine with internet access, run ollama pull for a small model, locate the resulting files under your OLLAMA_MODELS directory, and confirm you can copy that directory to a second location and point a fresh Ollama instance at it with the environment variable — without any network pull happening on the second instance.
Concept Check
HTTPS_PROXY but avoid setting HTTP_PROXY when running Ollama behind a corporate proxy?Sources & Further Reading
- Ollama FAQ — Official Docs — covers the HTTPS_PROXY/HTTP_PROXY distinction, custom CA certificates for TLS-inspecting proxies, and the default OLLAMA_MODELS storage locations per OS, cited directly for the commands in this lesson.