Ollama Environment Variables and Service Configuration

Ollama has no traditional configuration file; almost all service behavior is controlled by environment variables: listen address, model path, context, concurrency, proxy, and debugging.

This section first covers the setup methods for the three platforms, then explains each core variable in detail across three layers: network entry, request scheduling, and model runtime.

Where Configuration Variables Live in the Service

Let's first create a map: the dozen or so environment variables are not all on the same level; they each act on different stages of the service process.

To view the full list of variables supported by the current version, run `ollama serve --help`.

How to Set Environment Variables on Three Platforms

The same variable has completely different setup entry points across the three platforms; this is where beginners get stuck most easily.

macOS：launchctl

When Ollama runs as an app, environment variables must be injected via launchctl; after setting them, restart the app for them to take effect:

Linux: systemd Service Override

Windows: System Environment Variables

Search for "environment variables" in the Start menu, select "Edit environment variables for your account," create or edit the variable, then save.

Key step: quit Ollama from the tray first, then restart it from the Start menu after saving; only then will the new variables take effect in the new process.

There is also a JSON configuration file server.json (located at ~/.ollama/) for a small number of toggle-style settings; for example, write {"disable_ollama_cloud": true} to disable cloud features. The vast majority of configuration still follows environment variables.

Network Entry: HOST, ORIGINS, and Proxy

OLLAMA_HOST: Let Your LAN Access Your Models

By default, it only listens on 127.0.0.1, so only the local machine can use it; to let other devices on the LAN call it, change it to listen on all network interfaces:

Opening it to the LAN is equivalent to exposing an unauthenticated model service to all devices on the same subnet. This is acceptable on a home network, but on a corporate network you must pair it with firewall rules or a reverse proxy (discussed in detail in the private deployment chapter).

OLLAMA_ORIGINS: Cross-Origin Allowlisting

By default, Ollama only accepts cross-origin requests from 127.0.0.1 and 0.0.0.0. When web pages or browser extensions connect directly to the local API, you need to explicitly allowlist them:

Proxy: HTTPS_PROXY Is the Only One Needed

Model downloads use HTTPS for outbound traffic; in network-restricted environments, just point HTTPS_PROXY at the proxy.

Set only HTTPS_PROXY, not HTTP_PROXY: Ollama does not fetch models over HTTP, and adding an HTTP proxy may actually interrupt the connection between client and server. In Docker scenarios, pass -e HTTPS_PROXY=... when starting the container; if using a proxy with a self-signed certificate, you also need to install the CA certificate into the system (or bake it into the image).

Model Runtime: Path, Context, and Keep-Alive

OLLAMA_MODELS: Store Models on Another Drive

By default, models are stored in the user directory; the paths for the three platforms are as follows:

Point OLLAMA_MODELS at the new directory to migrate everything; after moving the downloaded model files there, they can be used directly.

OLLAMA_CONTEXT_LENGTH: Global Context Length

Sets the default context length for all models; it takes effect when not overridden at the model or request level:

Priority from highest to lowest: options.num_ctx in the API request, PARAMETER num_ctx in the Modelfile, this environment variable, and the automatic tiered default based on VRAM.

OLLAMA_KEEP_ALIVE: Global Keep-Alive Duration

Uniformly adjusts how long a model stays resident after loading; the value format matches the keep_alive parameter in the API:

A keep_alive passed individually in an API request takes precedence over this global value, enabling a tiered strategy like "10 minutes globally, key models always resident."

Request Scheduling: The Concurrency Trio

Ollama supports two levels of concurrency: multiple models resident at the same time, and a single model handling multiple requests in parallel—each controlled by its own variable.

The scheduling logic is worth understanding: when VRAM is sufficient, models process requests in parallel; when VRAM is insufficient, new requests queue up, waiting for idle models to be unloaded and free up space.

NUM_PARALLEL is the variable most likely to trip you up: setting it to 4 means the context cache is multiplied by 4, VRAM usage instantly quadruples, and models may be pushed off the GPU as a result. Planning for multi-user shared instances is covered in the private deployment chapter.

Debugging and Logging: OLLAMA_DEBUG

The first step in troubleshooting is always to enable debugging and check the logs.

To enable debugging in the Windows GUI app: first quit the app from the tray, then run in PowerShell:

Summary of log locations across the four environments:

Quick Reference for Other Useful Variables

The remaining variables are mostly tied to specific scenarios; full chapter-by-chapter explanations are covered in the corresponding topic sections. Here we'll establish an index first.