Self-Host Ollama on Hostinger VPS (2026)

Why self-host Ollama on a VPS?

Ollama packages open-weight language models (Llama, Mistral, Qwen, Phi, Gemma) into a single local runtime with an OpenAI-compatible API. Running it on your own VPS buys three things the big AI APIs cannot offer: privacy (prompts and documents never leave your server), flat cost (one monthly VPS bill instead of per-token metering that scales with usage), and control (any open model, any system prompt, no rate limits, no content-policy surprises).

The trade is speed and model size. A Hostinger VPS has no GPU (see our honest GPU hosting page), so you are doing CPU inference — perfectly good for personal assistants, document Q&A, and background jobs, but not for serving a snappy chatbot to paying customers. Go in with that understanding and Ollama-on-VPS is one of the best value setups in self-hosted AI.

Installing Ollama on the VPS

Provision a Hostinger KVM VPS with Ubuntu 22.04/24.04 (sizing guidance below — do this step first, because reinstalling on a bigger plan later wastes an afternoon). SSH in as root and run Ollama’s official install script:

curl -fsSL https://ollama.com/install.sh | sh

That is genuinely the whole install — the script sets up the ollama systemd service, which starts automatically and restarts on reboot. Pull your first model:

ollama pull llama3.2:3b
ollama run llama3.2:3b

By default Ollama listens on 127.0.0.1:11434 — localhost only, which is what you want. If your application runs on the same server, it talks to Ollama locally with no network exposure. If you need LAN or remote access, bind to 0.0.0.0 only behind authentication (a reverse proxy with basic auth, or a VPN) — an open Ollama port on the internet will be found and abused within hours.

Verify the install with a quick API call from the server itself: curl http://localhost:11434/api/generate -d '{"model": "llama3.2:3b", "prompt": "Say hello", "stream": false}' should return a JSON response with the model’s answer. If it hangs or errors, check systemctl status ollama — the usual culprit on a fresh VPS is simply not enough free RAM, which brings us to the most important part of this guide: sizing.

Model sizing: how much RAM per model

RAM is the entire sizing question for CPU inference. A useful rule of thumb: a quantized (Q4) model needs roughly 1 GB of RAM per billion parameters, plus ~1–2 GB for the OS and Ollama overhead. Bigger context windows and longer conversations add to it. Use this table to pick your plan:

• ~1B models (Llama 3.2 1B, Qwen 2.5 1.5B) — ~2–3 GB RAM total. Fits the entry KVM plan (1 vCPU / 4 GB). Good for classification, simple Q&A, and testing your pipeline.
• ~3B models (Llama 3.2 3B, Phi 3.5 mini, Qwen 2.5 3B) — ~4–5 GB RAM total. Entry KVM plan works; KVM 2 is more comfortable. The sweet spot for personal assistants on CPU.
• ~7B–8B models (Llama 3.1 8B, Mistral 7B, Qwen 2.5 7B) — ~8–10 GB RAM total. Needs KVM 2 (2 vCPU / 8 GB) at minimum; KVM 4 if you also run a database or web app on the box. The most capable models you can reasonably run on CPU.
• ~14B+ models — 16 GB+ RAM and patience. Technically possible on large KVM plans, but generation is very slow on CPU; this is where a GPU cloud starts making sense.
• Embedding models (nomic-embed-text, mxbai-embed-large) — under 1 GB. Run alongside anything; the backbone of private RAG search.

When in doubt, start one plan larger than the table suggests. RAM pressure causes the Linux OOM killer to terminate Ollama mid-conversation — the classic symptom is the model “randomly” dying under load. Hostinger lets you resize the VPS without rebuilding, so scaling up is painless. As a final sanity check before committing, run free -h after pulling your model and starting a conversation — if available memory stays comfortably above 1 GB, your sizing is right.

Current VPS pricing renders live from the deal database:

Honest CPU speed expectations

No benchmarks are quoted here because CPU inference speed depends on the exact vCPU, quantization, and prompt — anyone giving you a precise tokens/sec number for your server is guessing. What is safe to say from how CPU inference generally behaves:

• 1B–3B models: genuinely usable interactively — responses stream fast enough for a personal chatbot.
• 7B–8B models: noticeably slow — think seconds per sentence rather than instant streaming. Fine for background summarization, document Q&A where you can wait, and overnight batch jobs; frustrating for a live assistant you talk to all day.
• Long contexts (large documents, long chats) slow everything further — keep context windows modest on CPU.

The practical takeaway: match the model to the job’s patience budget. Drafting help and personal Q&A on a 3B model feels fine. Anything user-facing or latency-sensitive belongs on a GPU — see where to get real GPU hosting.

Putting a usable interface on it: Open WebUI

Ollama itself is an API — you talk to it with curl. For daily use, install Open WebUI, the popular ChatGPT-style frontend, via Docker on the same VPS:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

Point it at your Ollama instance, put it behind the same Nginx + Let’s Encrypt setup from our Node.js deployment guide, and add authentication — Open WebUI has built-in user accounts; enable them. What you get is a private ChatGPT clone: your models, your documents (its RAG file upload works well), your server, no subscription. Budget an extra 1–2 GB RAM for the container.

Good use cases (and bad ones)

• Private document Q&A: upload company docs or personal notes, ask questions — nothing leaves your server. The killer app for Ollama on VPS.
• Personal AI assistant: drafting, summarizing, brainstorming with a 3B model — fast enough, fully private, flat cost.
• Background processing: nightly summarization of tickets, classification of inbound email, extraction from PDFs — speed does not matter, cost does.
• Development sandbox: build and test your whole AI pipeline cheaply before paying for GPU inference in production.
• Bad fit: customer-facing chatbots (too slow on CPU), anything needing 70B+ models, and workloads where per-token APIs are cheaper than your time.

Security and maintenance notes

• Never expose Ollama’s port publicly without authentication — it has no built-in auth. Localhost binding plus a reverse proxy, or a VPN, is the safe pattern.
• Keep the OS updated (apt upgrade monthly) and the firewall limited to SSH, HTTP, and HTTPS.
• Back up your models and data: re-pulling models is free but slow; back up Open WebUI’s data volume and any custom Modelfiles.
• Monitor disk space: models are gigabytes each — a 20 GB VPS disk fills faster than you expect. ollama list shows what is stored; ollama rm removes what you do not use.
• Update Ollama itself by re-running the install script — new releases bring meaningful CPU performance improvements.

Frequently asked questions