Ollama’s behaviour is almost entirely configurable through environment variables — where it stores models, what address and port it listens on, how long it keeps models in memory, how many parallel requests it handles. The defaults are sensible for a single-user local setup, but as soon as you want to customise anything — move models to a different drive, open the API to your network, tune performance — environment variables are where you go.
This guide covers every Ollama environment variable worth knowing, how to set them correctly on each platform, and the most useful configurations for common setups.
The Complete Environment Variable Reference
Here are all the environment variables Ollama reads, what they do, and their defaults:
OLLAMA_HOST
Default: 127.0.0.1:11434
Controls the address and port the Ollama server listens on. Set to 0.0.0.0:11434 to accept connections from other devices on your network. Set to a specific IP like 192.168.1.100:11434 to bind to one interface only. Change the port by changing the number after the colon.
OLLAMA_MODELS
Default: ~/.ollama/models (macOS/Linux) or C:UsersName.ollamamodels (Windows)
Where Ollama stores downloaded model files. Set this to move models to a different drive or directory. The path must exist and be writable by the user running Ollama. On Linux with systemd, the ollama service user must have ownership of the directory.
OLLAMA_KEEP_ALIVE
Default: 5m
How long Ollama keeps a model loaded in memory after the last request. Accepts durations like 5m, 1h, 30s. Set to -1 to keep the model loaded indefinitely. Set to 0 to unload immediately after each request. Keeping models loaded reduces cold-start latency on subsequent requests but holds memory continuously.
OLLAMA_NUM_PARALLEL
Default: 1
How many requests Ollama processes simultaneously. Increasing this lets multiple clients or multiple requests run in parallel, at the cost of more memory per request. For single-user local use, the default of 1 is fine. For serving multiple users or running batch jobs, setting this to 2 or 4 can improve throughput.
OLLAMA_MAX_LOADED_MODELS
Default: 1
Maximum number of models that can be simultaneously loaded in memory. Increase this if you’re switching between models frequently and want to avoid reload latency — Ollama will keep multiple models resident. Requires proportionally more memory.
OLLAMA_FLASH_ATTENTION
Default: 0 (disabled)
Set to 1 to enable Flash Attention, which reduces memory usage during inference and can speed up processing for long contexts. Requires a compatible GPU. Worth enabling if you’re running large models with long context lengths.
OLLAMA_GPU_OVERHEAD
Default: 0
Amount of VRAM in bytes to reserve for non-Ollama GPU usage. Useful if other applications also use your GPU — set this to prevent Ollama from trying to use VRAM that’s already occupied.
OLLAMA_DEBUG
Default: 0
Set to 1 to enable verbose debug logging. Useful for troubleshooting startup issues, GPU detection problems, or unexpected behaviour. Not recommended for normal use as it produces a lot of output.
OLLAMA_TMPDIR
Default: system temp directory
Where Ollama writes temporary files during model operations. Set this if your default temp directory is on a small or slow partition.
CUDA_VISIBLE_DEVICES
Default: all NVIDIA GPUs
Not Ollama-specific — controls which NVIDIA GPUs are visible to CUDA applications. Set to a comma-separated list of GPU indices to restrict Ollama to specific GPUs, or set to -1 to force CPU-only mode.
ROCR_VISIBLE_DEVICES
Default: all AMD GPUs
Same as CUDA_VISIBLE_DEVICES but for AMD ROCm. Use to restrict Ollama to specific AMD GPUs.
Figure 1 — Ollama Environment Variables: Quick Reference
How to Set Environment Variables on Each Platform
The mechanics of setting environment variables differ by OS, and getting this wrong is a common source of frustration — you set the variable, nothing changes, and you’re not sure why. Here’s the correct method for each platform.
Setting Variables on Linux (systemd)
On a standard Ollama installation on Linux, the service runs under systemd. Environment variables set in your shell (.bashrc, .zshrc) are not inherited by systemd services — you have to set them in the service configuration.
The correct way is a systemd override file:
sudo systemctl edit ollama
This opens an editor (usually nano). Add your variables inside a [Service] section:
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=2"
Save the file, then reload and restart:
sudo systemctl daemon-reload
sudo systemctl restart ollama
Verify the variables were picked up:
sudo systemctl show ollama --property=Environment
If you’re running Ollama manually (not via systemd), set variables in your shell before running ollama serve:
export OLLAMA_HOST=0.0.0.0:11434
export OLLAMA_MODELS=/data/ollama/models
ollama serve
Setting Variables on macOS
On macOS, the Ollama app runs as a LaunchAgent. Setting variables in your shell profile doesn’t affect the app — you need to use launchctl:
launchctl setenv OLLAMA_HOST 0.0.0.0:11434
launchctl setenv OLLAMA_MODELS /Volumes/Data/ollama-models
launchctl setenv OLLAMA_KEEP_ALIVE -1
After setting variables with launchctl setenv, quit Ollama from the menu bar and relaunch it. The new values take effect on the next launch.
The catch: launchctl setenv variables don’t survive a reboot. After a restart, you’d need to run the commands again. To make them permanent, create a LaunchAgent plist that sets the variables on login. Create a file at ~/Library/LaunchAgents/com.ollama.environment.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key><string>com.ollama.environment</string>
<key>RunAtLoad</key><true/>
<key>ProgramArguments</key>
<array>
<string>sh</string><string>-c</string>
<string>launchctl setenv OLLAMA_HOST 0.0.0.0:11434 && launchctl setenv OLLAMA_KEEP_ALIVE -1</string>
</array>
</dict>
</plist>
Load it:
launchctl load ~/Library/LaunchAgents/com.ollama.environment.plist
From now on, variables are set at login before Ollama launches.
Setting Variables on Windows
On Windows, set user environment variables through the System Properties dialog for persistence across reboots:
- Search “Environment Variables” in Start menu → “Edit the system environment variables”
- Click “Environment Variables” button
- Under “User variables”, click New for each variable
- Add name (e.g.
OLLAMA_HOST) and value (e.g.0.0.0.0:11434) - Click OK and restart Ollama from the system tray
Or set them from PowerShell (persists across sessions):
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:11434", "User")
[Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\ollama-models", "User")
[Environment]::SetEnvironmentVariable("OLLAMA_KEEP_ALIVE", "-1", "User")
After setting, quit Ollama from the system tray and relaunch — new environment variables are only picked up on a fresh process start.
Figure 2 — Recommended Configurations by Use Case
Common Mistakes and How to Avoid Them
The most frequent mistake is setting environment variables in your shell profile and wondering why Ollama ignores them. On Linux, the systemd service has its own environment — shell exports don’t carry over. Use the systemd override. On macOS, the app has its own environment — shell exports don’t affect it. Use launchctl setenv. On Windows, setting variables in PowerShell for the current session only ($env:OLLAMA_HOST=...) doesn’t persist — use the System Properties dialog or [Environment]::SetEnvironmentVariable with the “User” scope.
The second common mistake is forgetting to restart Ollama after changing variables. Environment variables are read at process startup — changing them while Ollama is running has no effect until you quit and relaunch. On Linux this means sudo systemctl restart ollama. On macOS, quit from the menu bar and reopen. On Windows, quit from the system tray and relaunch.
Finally, on Linux, if you set OLLAMA_MODELS to a new directory, make sure the ollama service user has ownership: sudo chown -R ollama:ollama /your/new/models/path. Without correct ownership, the service can’t write to the directory and model downloads will fail silently or with a confusing permission error that doesn’t obviously point to the ownership issue.
Getting these variables configured correctly is a one-time investment that makes Ollama behave exactly how you want it to for your specific setup — whether that’s a single laptop, a home network server, or a multi-user development machine. The reference table above covers every variable worth knowing; pick the ones relevant to your use case and set them on your platform using the method described for that OS.
Verifying Variables Took Effect
After setting variables and restarting Ollama, it’s worth confirming they were actually picked up. The simplest check is to test the behaviour you configured. If you set OLLAMA_HOST=0.0.0.0:11434, run curl http://localhost:11434 from another machine on your network — if you get “Ollama is running” back, the variable worked. If you set OLLAMA_MODELS to a new path, pull a small model and check that the files appear in the new directory rather than the old one. For OLLAMA_KEEP_ALIVE, load a model, wait longer than the duration you set, then run ollama ps — the model should have disappeared from the list. For Linux specifically, you can inspect what environment variables the running service sees directly: sudo cat /proc/$(pgrep ollama)/environ | tr ' ' ' — this reads the environment of the live process and filters for Ollama-specific variables, showing exactly what values the running service has. If a variable you set isn’t showing up here, the override file wasn’t saved correctly or the service wasn’t reloaded — run
' | grep OLLAMAsudo systemctl daemon-reload && sudo systemctl restart ollama and check again.
Using Variables for Testing and Debugging
Environment variables are also useful for temporary configuration during testing without changing your persistent setup. On any platform, you can prefix a command with variable assignments to set them only for that invocation. On Linux and macOS: OLLAMA_DEBUG=1 OLLAMA_NUM_PARALLEL=4 ollama serve starts Ollama with debug logging and 4 parallel workers, just for that session — your normal settings are unchanged next time. This is useful for testing performance with different settings, debugging a specific issue, or trying out a configuration before committing it to your permanent setup. On Windows in PowerShell, you can do the same by setting variables for the current session only with $env:OLLAMA_DEBUG=1 before running ollama serve, then closing that PowerShell window when done to discard the temporary settings.