Ollama for Business: Setup Beyond the Laptop

Out of the box, Ollama listens on 127.0.0.1:11434, keeps a model in memory for five minutes after its last request, works on one request per model at a time, and answers anyone who can reach the port without asking who they are. Those defaults are right for one person on a laptop. Running Ollama for business, as a service ten or fifty colleagues share, means changing almost every one of them on purpose. Setting names and defaults here follow the Ollama documentation as of October 2026; confirm them with ollama serve --help on your installed version.

If you are still deciding whether Ollama is the right server at all for many concurrent users, read the comparison of Ollama and vLLM for production first. What follows assumes Ollama is the choice.

Run it as a service account, not as a person

The official Linux install script sets up a systemd service that runs as a dedicated ollama user. If you install by hand, the documentation gives the equivalent steps:

sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama
sudo usermod -a -G ollama $(whoami)

The first line creates a system user with no login shell and a home directory at /usr/share/ollama. The second adds the administrator to the ollama group so they can manage model files without becoming root. The service unit then runs /usr/bin/ollama serve with User=ollama, Restart=always and RestartSec=3, so a crash restarts the server within seconds instead of waiting for someone to notice.

Never run a shared Ollama in a terminal under a staff member's account; it dies when they log out. Put every setting in a systemd override rather than editing the unit file, so an upgrade does not overwrite your changes:

sudo systemctl edit ollama

This opens /etc/systemd/system/ollama.service.d/override.conf. Each setting is one Environment= line under [Service]. After saving, run systemctl daemon-reload and systemctl restart ollama. Logs go to the journal and are read with journalctl -e -u ollama.

Bind address: decide who can reach the port

OLLAMA_HOST sets the address and port the server listens on. The documentation's way to expose Ollama on a network is OLLAMA_HOST=0.0.0.0:11434, which makes it answer on every interface. For a shared office service that is usually the wrong move, for one reason stated plainly in the API docs: the local API at port 11434 does not require authentication. Anyone who can reach the port can run prompts, list models, pull new ones and delete existing ones.

There are three sensible patterns:

Pattern	OLLAMA_HOST	Who can reach Ollama directly
Proxy on the same machine	127.0.0.1:11434 (default)	Only processes on the server itself
Proxy on a separate gateway	the server's private LAN address	Only hosts the firewall allows, ideally just the gateway
Lab or test only	0.0.0.0:11434	Everyone on the network, unauthenticated

The first pattern is the simplest to get right: leave the default, put a reverse proxy on the same box, and let only the proxy face the network. Firewall rules and patching are covered in securing a local LLM server.

A related setting matters for a private deployment. Recent Ollama versions can sign in to ollama.com and route some models to cloud inference. If the whole reason for running locally is that data stays in the building, set OLLAMA_NO_CLOUD=1, which the FAQ describes as disabling cloud features, including cloud models and web search.

A reverse proxy that asks who is calling

Since Ollama has no user accounts, authentication lives in front of it. Nginx is a common choice, and the Ollama FAQ gives the two lines it needs to forward correctly:

location / {
    auth_basic "Ollama";
    auth_basic_user_file /etc/nginx/ollama.htpasswd;

    proxy_pass http://localhost:11434;
    proxy_set_header Host localhost:11434;
    proxy_buffering off;
    proxy_read_timeout 600s;
}

auth_basic and auth_basic_user_file come from the nginx basic authentication module; the password file holds one name:hashed-password line per user, created with the htpasswd utility. Serve this over HTTPS, since basic auth sends credentials with every request.

Two lines in that block exist because of how language models answer:

• proxy_buffering off. Nginx buffers responses by default. Ollama streams tokens as they are generated, and buffering can hold them back so the user stares at a blank box and then gets the whole answer at once.
• proxy_read_timeout 600s. The nginx default is 60 seconds between two reads from the upstream. A cold model load followed by processing a long document can exceed that before the first token arrives, and nginx closes the connection.

Basic auth or a token

Basic auth suits people. Applications written against OpenAI-style clients send an Authorization: Bearer <key> header instead. In nginx, a map turns that header into a client name, and the location refuses anything unknown:

map $http_authorization $ollama_client {
    default "";
    "Bearer 7f3c...a91e" "invoice-bot";
    "Bearer 2b8d...44c0" "open-webui";
}

location / {
    if ($ollama_client = "") { return 401; }
    proxy_pass http://localhost:11434;
    # same Host, buffering and timeout lines as above
}

One key per application lets you revoke one without breaking the rest, and logging $ollama_client in the access log shows which application sent what. Most staff will reach the model through a team chat front end such as Open WebUI, which handles their accounts itself, so it needs only one key of its own.

Model storage: plan the disk before the first pull

On Linux the default model directory is /usr/share/ollama/.ollama/models, inside the service user's home. That often sits on a small root partition. Move it with OLLAMA_MODELS, pointing at a data disk the ollama user can read and write:

[Service]
Environment="OLLAMA_MODELS=/srv/ollama/models"

Size the disk from the models you intend to keep, not the one you start with. A 32-billion-parameter model at about 4.9 bits per weight is roughly 32.5 x 4.89 / 8 = 19.9 GB on disk. Keep four models of that size plus two smaller 8 GB ones and you need 4 x 19.9 + 2 x 8 = 95.6 GB, before older versions you keep for rollback. A 250 GB volume leaves room to test a new model next to the old one instead of deleting first.

Consider blocking the pull and delete endpoints at the proxy for everyone except an admin key, so the models in use change only when someone decides they should.

Keep-alive: how long a model stays loaded

After a request, Ollama keeps the model in memory for five minutes, then unloads it, so the first question after lunch pays the full load time again.

OLLAMA_KEEP_ALIVE changes the default. It accepts a duration such as 10m or 24h, a number of seconds, a negative value such as -1 to keep the model loaded indefinitely, or 0 to unload immediately. A per-request keep_alive value in the API overrides the server setting, so a client can unload your main model by accident.

A reasonable rule: if one model serves the office during working hours and the GPU has no other job, set OLLAMA_KEEP_ALIVE=-1 and let it stay resident. If the same GPU also runs overnight batch work with a different model, use a long but finite value such as 8h, so the daytime model releases memory in the evening.

Parallel requests and memory: the setting that bites

OLLAMA_NUM_PARALLEL sets how many requests each model processes at once. The documented default is 1, so a second user waits until the first answer is finished. Raising it is the obvious fix, and it has a cost the FAQ states directly: required memory scales with OLLAMA_NUM_PARALLEL x OLLAMA_CONTEXT_LENGTH.

Work through an example. The default OLLAMA_CONTEXT_LENGTH is 4096 tokens, which is short for document work, so an office raises it to 8192. With OLLAMA_NUM_PARALLEL=4, the server reserves context memory for 4 x 8192 = 32,768 tokens. For a 32B model, where the VRAM arithmetic puts 16,384 tokens of cache at about 4.3 GB, 32,768 tokens costs about 8.6 GB on top of the 19.9 GB of weights. That is 28.5 GB, which no longer fits a 24 GB card.

Three levers bring it back:

1. Lower parallelism to 2: 2 x 8192 = 16,384 tokens, about 4.3 GB, for a total near 24.2 GB plus overhead. Still too tight on 24 GB.
2. Set OLLAMA_KV_CACHE_TYPE=q8_0, which the docs describe as using about half the memory of the default f16. It applies only with flash attention, which Ollama turns on automatically where the GPU supports it. Four slots at 8192 then cost about 4.3 GB, for roughly 24.2 GB in total. Also too tight on 24 GB, comfortable on 32 GB or more.
3. Choose a smaller model. Often the honest answer for a single 24 GB card serving several people.

Two more settings shape behavior under load. OLLAMA_MAX_LOADED_MODELS caps how many models can be resident at once (by default three per GPU, if they fit), and on a GPU a new model must fit entirely in free VRAM to load alongside the others. OLLAMA_MAX_QUEUE, default 512, is how many requests may wait before the server starts answering with HTTP 503. Applications should treat a 503 as "retry later", not as a crash.

After any change, run ollama ps and send a few simultaneous requests through the proxy. A model that spills to system RAM still answers, only far more slowly, which a one-user test will miss.

Frequently asked questions

Can Ollama itself require a password or API key?

No. The Ollama API documentation states that the local API at port 11434 does not require authentication. The API keys it describes are for ollama.com's cloud service, not for protecting your own server, so access control has to come from a reverse proxy, a gateway or a front end placed in front of it.

Does the systemd override survive an Ollama upgrade?

That is the point of keeping settings in override.conf under /etc/systemd/system/ollama.service.d/: it is a separate file from the main unit, which the installer writes. systemd merges the two at load time, so a replaced unit file does not erase your settings. After an upgrade, confirm with systemctl cat ollama and check ollama serve --help for renamed or new variables.

Should the GPU server also run the chat front end and the proxy?

For a small office, one machine running Ollama, nginx and a chat front end is common and keeps Ollama on 127.0.0.1. Splitting them pays off when the GPU box needs to sit on a restricted network segment, or when several model servers sit behind one gateway that handles logins and keys.

Can different applications use different context lengths?

OLLAMA_CONTEXT_LENGTH is only the server default. A client can set num_ctx in the options object of a request, so a summarization job can ask for a long context while chat stays short. The catch is that a loaded model runs with one context size, so clients that alternate between sizes can force repeated reloads. If two workloads need different lengths, separate model tags with num_ctx set in each Modelfile avoid the churn, at the cost of each tag holding its own memory when both are loaded.