Hosting Ollama on a VPS: advanced operational guide

Deploying Ollama takes a few minutes. Running it reliably over time takes more attention. In production, three points concentrate most of the problems: model management (which to load, which to remove to free disk space), the API attack surface (unauthenticated by default on port 11434), and memory usage (an oversized model saturates RAM and gets killed by the kernel). This guide assumes the ollama container is already running and focuses on these three areas, plus integration with your stack tools.

A model's size is expressed in billions of parameters (B) and determines the RAM required. A 1B/3B model fits in 2 to 3 GB and suits simple tasks (classification, short summary) on a modest VPS. A 7B/8B requires 5 to 6 GB in Q4: this is the most common quality/resource ratio. A 13B needs 9 to 10 GB, and a 70B exceeds 40 GB — reserved for high-memory VPS or GPU configurations. For each size, quantization adjusts the quality/speed trade-off: Q4_K_M offers a good quality/speed balance on CPU, Q8 preserves more precision at the cost of doubled RAM. Before pulling a model, check free space with df -h and available RAM with free -h.

By default, Ollama listens on 127.0.0.1:11434 without authentication. To expose it to your tools (Open WebUI, n8n, a remote script), place nginx as a front end with a Bearer token. The configuration block below delegates access to a secret token defined in the $api_token variable, checks the Authorization header and proxies to Ollama. CORS is configured to accept requests from your interface without exposing the API to all origins.

In /etc/nginx/sites-available/ollama:

map $http_authorization $api_token_valid {
    default 0;
    "Bearer YOUR_SECRET_TOKEN" 1;
}
server {
    listen 443 ssl;
    server_name api-ia.your-domain.com;
    ssl_certificate /etc/letsencrypt/live/api-ia.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api-ia.your-domain.com/privkey.pem;
    location / {
        if ($api_token_valid = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        add_header Access-Control-Allow-Origin "https://ui.your-domain.com";
    }
}

Activate with ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ then nginx -t && systemctl reload nginx.

Four situations come up regularly in production.

Model too slow. Generation exceeds 2-3 tokens per second on CPU for a 7B? Check that OLLAMA_NUM_THREADS is not at 1 (default if not set on some images). Also check that only one model is loaded (OLLAMA_MAX_LOADED_MODELS=1): two simultaneous models compete for cores and memory bandwidth.

Insufficient VRAM (GPU). If the Docker log shows CUDA out of memory or ROCm error, the model does not fit in VRAM. Switch to the q4_K_M tag or reduce OLLAMA_CONTEXT_SIZE. Ollama falls back to CPU if VRAM is insufficient, but without clearly indicating it: compare generation speeds to detect this.

API connection refused. curl: (7) Failed to connect from outside while the service is listening? The firewall is blocking port 11434, or nginx is not started. Check with ss -tlnp | grep 11434 (should show 127.0.0.1, not 0.0.0.0) and systemctl status nginx.

Signal killed / OOM. The process is killed by the kernel (OOM killer). The VPS RAM is insufficient for the selected model. Switch to a smaller size or enable a 4 to 8 GB swap as a buffer: fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. Swap slows generation but avoids brutal stops.

Ollama is a backend: it takes its full value when other services connect to it. Three tools integrate naturally on the same VPS.

Open WebUI exposes a conversation interface similar to ChatGPT, connected to the local Ollama API. In its environment file, set OLLAMA_BASE_URL=http://ollama:11434 (if both containers share a Docker network) or OLLAMA_BASE_URL=http://127.0.0.1:11434 if Open WebUI runs on the same host. Open WebUI handles model selection, conversation history and user management. Note: the Ollama ↔ Open WebUI coupling exposes an additional attack surface — see the CVE-2026-45672 section below.

LangFlow is a visual LLM pipeline builder. Add an Ollama node to your flow, enter http://127.0.0.1:11434 as the base URL and select the model from the dropdown. LangFlow calls the /api/generate endpoint directly without internal authentication — place it on the VPS private network, not exposed publicly.

n8n lets you trigger Ollama calls from an automation workflow. Use the HTTP Request node pointing to http://127.0.0.1:11434/api/chat with a JSON body containing model and messages. From n8n, you can chain an Ollama call to a data retrieval step, email send or outgoing webhook without writing code.

Published on May 21, 2026 (GHSA-482j-2pq6-q5w4), this vulnerability affects all versions of Open WebUI prior to 0.8.12. CVSS score: 8.8 (high).

Attack mechanics. An authenticated user can execute arbitrary Python code via the /api/v1/utils/code/execute endpoint, even if the administrator has disabled code execution in settings (ENABLE_CODE_EXECUTION=false). The guard is declared in the configuration but is never enforced at the API layer: any verified account on the instance can trigger execution.

Impact. The attacker gains access to the underlying Jupyter backend and can read arbitrary files on the VPS, steal secrets (API keys, Ollama Bearer token, environment variables), or establish persistence. The confidentiality, integrity and availability of the server are compromised.

Why this is critical in an Ollama ↔ Open WebUI coupling. Ollama and Open WebUI often run on the same VPS, sometimes in the same Docker network, with shared secrets (fallback OpenAI API key, Ollama API Bearer token). An RCE on Open WebUI therefore gives direct access to the Ollama API and models in memory, bypassing the reverse proxy entirely.

Fix. Update Open WebUI to version 0.8.12 or later. This version enforces the ENABLE_CODE_EXECUTION check at the API endpoint level, where it should always have been.

Check your version. From the container: docker exec open-webui cat /app/package.json | grep '"version"'. If the output is below 0.8.12, the update is urgent: docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui then restart with the same environment parameters.