Ollama environment variables on a server

What Ollama environment variables control

Ollama environment variables are the settings the Ollama server reads when it starts. On a Linux VPS the server runs as a systemd service, so the variables belong in a systemd override file, not in your shell. Set them with sudo systemctl edit ollama, restart the service, and then read the server config line in the journal to prove the server saw them.

This guide covers the ten variables that matter on a VPS. Each one gets one line first, then a closer look where a default surprises people. Every default here was read from the envconfig/config.go source file at the v0.40.15 release tag. That was the latest stable release on GitHub as of 7 November 2026, published on 3 November. Defaults move between releases, so check your version with ollama --version. If it is not v0.40.15, open envconfig/config.go at your own tag on GitHub before you trust any number below.

If Ollama is not on the server yet, start with running Ollama on a VPS to self-host an LLM and come back here to tune it.

The ten variables that matter on a VPS

• OLLAMA_HOST: the address and port the server binds. Default 127.0.0.1:11434, so only the server itself can connect.
• OLLAMA_MODELS: the directory where pulled models land. Default $HOME/.ollama/models for the user that runs the server.
• OLLAMA_KEEP_ALIVE: how long a model stays in memory after its last request. Default 5m.
• OLLAMA_CONTEXT_LENGTH: the context window used when a request does not set one. The code default is 0, which means "pick by VRAM".
• OLLAMA_NUM_PARALLEL: how many requests one loaded model processes at the same time. Default 1.
• OLLAMA_MAX_LOADED_MODELS: how many models may be in memory at once. Default 0, which the scheduler turns into 3 per GPU, or 3 on a CPU-only server.
• OLLAMA_MAX_QUEUE: how many requests wait in line when the server is busy. Default 512.
• OLLAMA_FLASH_ATTENTION: unset means Ollama decides. Set it to 1 to force flash attention on.
• OLLAMA_KV_CACHE_TYPE: the number format of the K/V (key/value) cache, the memory that holds the context. Default f16.
• OLLAMA_ORIGINS: extra web origins a browser may call the API from, added to a built-in allow-list.

OLLAMA_HOST: who can reach port 11434

The value is an address with an optional scheme and port. With no scheme, Ollama assumes http and keeps the default port 11434, so OLLAMA_HOST=0.0.0.0 binds 0.0.0.0:11434. With an explicit scheme and no port, the port follows the scheme instead: http://0.0.0.0 gives port 80, and https:// gives 443. The safe habit is to always write the port: OLLAMA_HOST=0.0.0.0:11434.

Binding 0.0.0.0 makes the port reachable on every network interface the server has, which on a VPS includes the public one. Do that only with a firewall rule or a reverse proxy in front of it. The full set of choices, from SSH tunnels to a proxy with a password, is in the guide to the Ollama API and port 11434.

OLLAMA_MODELS: where downloads go

Model files are large, and the default directory sits on the root disk. Point OLLAMA_MODELS at a bigger volume if you have one. With the standard Linux install the service runs as the ollama user, so that user needs read and write access to the new directory:

sudo mkdir -p /srv/ollama/models
sudo chown -R ollama:ollama /srv/ollama/models

The server reads only the directory the variable names. Models already in the old directory are not moved for you. How the store is laid out, and what pull writes compared with run, is covered in Ollama pull vs run and where models are stored.

OLLAMA_KEEP_ALIVE: how long a model stays loaded

After the last request, a model stays in memory for 5 minutes and is then unloaded. The next request pays the full load time again. The value is a duration such as 10m or 24h. A negative value keeps models loaded with no time limit. Zero unloads the model right after each request. If the first answer after a quiet period is slow, this is the setting to change, and keeping an Ollama model loaded in memory covers the trade-off with RAM.

OLLAMA_CONTEXT_LENGTH: the default context window

The code default is 0, which tells Ollama to choose from the VRAM (video memory) it finds. The context-length page in the Ollama docs gives three tiers: under 24 GiB of VRAM gives 4k, 24 to 48 GiB gives 32k, and 48 GiB or more gives 256k. The v0.40.15 source uses the same three values but switches slightly lower, at 23 GiB and 47 GiB, and a comment in the code says the lower thresholds allow for small differences in the exact VRAM value. A GPU that reports a little under 24 GiB therefore still gets 32k. The Ollama FAQ still says the default is 4096 tokens. On the tier values, the context-length page and the v0.40.15 source agree with each other, so trust them over the FAQ.

Most VPS plans have no GPU. The docs do not state the CPU-only value in plain words, so do not assume it. Load a model and read the CONTEXT column of ollama ps instead. A request can still set its own context length, and this variable only applies when it does not. The details, including the num_ctx request option, are in setting Ollama context length with num_ctx.

OLLAMA_NUM_PARALLEL and OLLAMA_MAX_QUEUE: concurrent requests

OLLAMA_NUM_PARALLEL defaults to 1, so one model handles one request at a time and the rest wait. Raising it costs memory, because the FAQ says parallel requests increase the context size by the number of parallel requests. Memory for the context therefore grows with OLLAMA_NUM_PARALLEL times OLLAMA_CONTEXT_LENGTH. Four parallel slots of 8k context need about as much context memory as one slot of 32k. Embedding models are always loaded with a parallel value of 1, whatever you set.

OLLAMA_MAX_QUEUE defaults to 512. When the queue is full, a new request is rejected with this error:

server busy, please try again. maximum pending requests exceeded

On a small VPS that runs one request at a time, a queue of 512 mostly means long waits. A shorter queue makes clients fail fast and retry. How to size both values together is in Ollama NUM_PARALLEL and MAX_QUEUE.

OLLAMA_MAX_LOADED_MODELS: models in memory at once

The source default is 0, which means automatic. The scheduler turns 0 into 3 models per GPU, and counts a CPU-only server as one GPU, so you get 3. The FAQ states the same rule: 3 times the number of GPUs, or 3 for CPU inference. On a GPU, a new model is loaded next to the others only if it fits completely in VRAM. If memory is short, new requests queue until a model is unloaded. On a server with little RAM, setting this to 1 makes the behaviour easier to predict. Check what fits first with how big an LLM fits in your RAM.

OLLAMA_FLASH_ATTENTION and OLLAMA_KV_CACHE_TYPE: less memory per token

These two work as a pair. Flash attention is a more memory-efficient way to compute attention. When OLLAMA_FLASH_ATTENTION is unset, the FAQ says Ollama uses it automatically when the selected backend and devices support it. OLLAMA_FLASH_ATTENTION=1 forces it on.

OLLAMA_KV_CACHE_TYPE takes one of three documented values:

• f16: the default, and the most memory.
• q8_0: about half the memory of f16, with very little loss of precision.
• q4_0: about a quarter of the memory of f16, with a larger loss of precision that may show more at long context lengths.

Quantization of the cache only applies when flash attention is enabled, so set both lines together. It is also a global setting: every model on the server runs with the same cache type. When q4_0 is worth it is covered in Ollama KV cache quantization.

OLLAMA_ORIGINS: browser access from other sites

This is a comma-separated list of extra origins for CORS (cross-origin resource sharing), the check a browser runs before a web page on one site may call an API on another. The built-in list already covers http and https on localhost, 127.0.0.1 and 0.0.0.0, with and without a port, plus app://*, file://*, tauri://*, vscode-webview://* and vscode-file://*. What you set is added to that list. Set it only when a web front end served from another domain calls Ollama straight from the browser, for example OLLAMA_ORIGINS=https://chat.example.com. To control which machines can reach the port, use OLLAMA_HOST and the firewall.

How to set the variables with systemctl edit ollama

Open an override file for the service:

sudo systemctl edit ollama.service

This opens an editor on a drop-in file. Recent systemd versions show the current unit below as comments. Type your lines above the comment that says the text below it will be discarded. Write one Environment= line per variable under a [Service] header:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/srv/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Save and close the editor, then reload systemd and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart ollama

The restart is the step people skip. A running process keeps the environment it started with, so daemon-reload alone changes nothing in the server you already have. The drop-in lives at /etc/systemd/system/ollama.service.d/override.conf, and you can write that file by hand instead if you manage servers with a configuration tool. systemctl cat ollama prints the unit with every drop-in, so you can see the file was saved where systemd looks.

Why exporting a variable in your shell does nothing for the service

export OLLAMA_KEEP_ALIVE=1h changes the environment of your shell and the programs your shell starts. The Ollama service is not one of them. systemctl restart asks systemd to start the process, and systemd builds its environment from the unit file and its drop-ins. Your login shell is not involved. This is why the Ollama FAQ says that when Ollama runs as a systemd service, its variables should be set with systemctl.

You can watch this happen:

export OLLAMA_KEEP_ALIVE=1h
sudo systemctl restart ollama
systemctl show ollama --property=Environment

The last command prints only the Environment= values from the unit and its drop-ins. OLLAMA_KEEP_ALIVE=1h is not there unless you put it in the override. To see what the running process really holds, read its environment from /proc:

pid=$(systemctl show -p MainPID --value ollama)
sudo cat /proc/$pid/environ | tr '\0' '\n' | grep '^OLLAMA'

The FAQ example OLLAMA_CONTEXT_LENGTH=8192 ollama serve is a different thing. It starts a second server in the foreground, with that variable set, and that server is not the systemd service. While the service holds port 11434, the second server cannot bind the same address. Stop the service first, or give the foreground server another port with OLLAMA_HOST.

How to confirm the server read your values

At start-up the server writes a log line with the message server config, which holds the environment values it read. A few lines later comes a Listening on line with the address and the version. Read both from the journal:

journalctl -u ollama -b --no-pager | grep -E 'server config|Listening on'

journalctl -e -u ollama from the Ollama Linux docs shows the same log, opened at the end. Find each variable you set in the server config line. The Listening on line should show the address from OLLAMA_HOST and the version you expect. If the address is still 127.0.0.1:11434 after you changed it, the override was not saved or the service was not restarted.

Some settings only show once a model is loaded. Run a model you have already pulled, then list what is in memory:

ollama run <model> "hello"
ollama ps

ollama ps lists each loaded model. The PROCESSOR column shows how the model is split between GPU and CPU, and the CONTEXT column shows the context length that was allocated. If CONTEXT does not match OLLAMA_CONTEXT_LENGTH, check whether your client sends its own context length with each request. If requests start failing with a deadline error after you raise the context, fixing Ollama context deadline exceeded walks through the causes.

Mistakes that look like an ignored setting

• No restart. daemon-reload reloads unit files. It does not restart Ollama, so the old values stay in the running process.
• A misspelled name. OLLAMA_KEEPALIVE is not OLLAMA_KEEP_ALIVE. The server reads only the names it knows, so a typo leaves the default in place and the server config line shows the default value.
• A scheme with no port. OLLAMA_HOST=http://0.0.0.0 binds port 80, not 11434, because an explicit http scheme brings its own default port. Clients pointed at 11434 then cannot connect.
• A directory the service cannot write. A custom OLLAMA_MODELS path owned by root means the ollama user cannot save pulls there. Run the chown line above and restart.
• A cache type without flash attention. OLLAMA_KV_CACHE_TYPE=q8_0 on its own may not apply, because quantization needs flash attention. Set OLLAMA_FLASH_ATTENTION=1 too.

If you run Ollama in a container instead of as a systemd service, the same variable names apply but they go into the container's environment, as shown in running Ollama with rootless Podman.

FAQ

Where do I set Ollama environment variables on Linux?

When Ollama runs as a systemd service, run sudo systemctl edit ollama.service and add one Environment="NAME=value" line per variable under [Service]. Then run sudo systemctl daemon-reload and sudo systemctl restart ollama. The drop-in file is saved as /etc/systemd/system/ollama.service.d/override.conf, and you can also create that file by hand.

Why does Ollama ignore the variable I exported in my terminal?

The systemd service is started by systemd, not by your shell, so it never sees variables you export in a terminal. Its environment comes from the unit file and its drop-ins. Put the variable in a systemctl edit ollama override and restart the service. systemctl show ollama --property=Environment shows what the unit will pass to the server.

How do I check which settings the Ollama server is using?

Read the start-up log with journalctl -u ollama -b --no-pager | grep -E 'server config|Listening on'. The server config line holds the environment values the server read, and the Listening on line shows the bind address and version. After loading a model, ollama ps shows the allocated context in its CONTEXT column and the GPU and CPU split in its PROCESSOR column.

What is the default context length in Ollama?

At v0.40.15 the source default of OLLAMA_CONTEXT_LENGTH is 0, which means Ollama picks a value from the VRAM it finds: 4k under 23 GiB, 32k from 23 GiB, and 256k from 47 GiB. The context-length docs give the same three values but round the switch points to 24 and 48 GiB. The FAQ still says 4096 tokens. On a CPU-only VPS, load a model and read the CONTEXT column of ollama ps.

Is it safe to set OLLAMA_HOST to 0.0.0.0 on a VPS?

Binding 0.0.0.0:11434 makes the API reachable on every interface, including the public one. Put a firewall rule or a reverse proxy with authentication in front of it first, or keep the default 127.0.0.1:11434 and reach the server through an SSH tunnel. OLLAMA_ORIGINS does not help here, because it only sets which web origins a browser may call from.