Install Ollama on a VPS: the commands we ran on Ubuntu 24.04, with timings

To install Ollama on a VPS, run the official script (curl -fsSL https://ollama.com/install.sh | sh) on a fresh Ubuntu server, then ollama pull a model. On our five Hetzner servers the script took 14.1 to 24.2 seconds, and Llama 3.2 3B downloaded in 6.6 to 14.1 seconds. Ollama then listens on 127.0.0.1:11434, private to the server, and it should stay that way.

Why this matters now: the install is the easy part. The parts that go wrong on a VPS are picking a server too small for the model, and opening port 11434 to the internet, where the API has no login. This guide is the exact sequence we ran on Ubuntu 24.04 for our CPU-only benchmark, with what each step took. It is part of our local AI section.

Tested in the Lab Hetzner CX23, CX33, CX43, CAX11, CAX21 · Nov 2026

Step 0: pick a server that fits the model

RAM decides what runs. With the model loaded, system RAM used was 3002 to 3282 MiB for Llama 3.2 3B on our servers, and 5796 to 6023 MiB for Llama 3.1 8B. On both 4 GB servers (CAX11 and CX23) the 8B model ran out of memory. Short version: 4 GB for 1B and 3B models, 8 GB for 7B to 8B. A GPU is not required; every number here is CPU-only. The full buying guide is VPS for Ollama.

Measured by AI Hosting Lab on 2026-11-05 · 5 servers · method · raw data

Step 1: lock down SSH first

Do this before installing anything. Log in with an SSH key, check that key login works from a second terminal, then turn off password logins. These lines are from the hardening script we ran on our own Ubuntu server (hardening.sh):

apt-get update && apt-get -y upgrade
apt-get -y install unattended-upgrades ufw fail2ban
cat > /etc/ssh/sshd_config.d/10-lab-hardening.conf <<CONF
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
CONF
sshd -t
systemctl reload ssh 2>/dev/null || echo "ssh.socket activation: config applies to new connections"
systemctl enable --now fail2ban

One Ubuntu 24.04 gotcha we hit: sshd is started through ssh.socket, so systemctl reload ssh fails with "ssh.service is not active". That is not an error in your config. New SSH connections already use the new settings, which is why the script just prints a note. The full checklist is in secure an Ubuntu VPS.

Step 2: firewall with only SSH open

Our benchmark script turned on the firewall before installing anything, with only SSH allowed:

ufw allow OpenSSH
ufw --force enable

For a server that only runs Ollama, that is all you need. Do not add a rule for 11434. If you later put a web UI or reverse proxy in front, open 80 and 443 for that, not the Ollama port.

Step 3: install Ollama with the official script

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

We read the script before running it. On Linux it detects the architecture (x86_64 or arm64, anything else is refused), creates an ollama system user with its home in /usr/share/ollama, writes /etc/systemd/system/ollama.service running ollama serve as that user with Restart=always, then enables and starts the service. It looks for NVIDIA or AMD GPUs; on a normal VPS it finds none and runs CPU-only.

Measured install time, start to finish:

Most of that time is the download, so it says more about the network on the day than about the server. The script works the same on ARM; see Ollama on ARM servers for how ARM performs.

Step 4: check that it runs and where it listens

curl -s localhost:11434/api/version
systemctl status ollama
journalctl -e -u ollama

The first line returned version 0.40.14 on all five servers. The Ollama FAQ states the default: "Ollama binds 127.0.0.1 port 11434 by default." The script itself ends with "The Ollama API is now available at 127.0.0.1:11434." The journalctl command is what the Linux docs give for the service logs; it is where you will see memory errors.

Step 5: pull a model

ollama pull llama3.2:3b

The default tags from the Ollama library are Q4_K_M quantized: the weights are compressed to about 4 to 5 bits each, so the 3B model is a 2.0 GB download and Llama 3.1 8B is 4.9 GB. Our pull times:

A completed pull does not mean the model will run. Llama 3.1 8B downloaded on both 4 GB servers (19.6 s on the CAX11, 34.2 s on the CX23) and then failed on both for lack of memory.

Step 6: send a first request

curl -s localhost:11434/api/generate -d '{"model":"llama3.2:3b","prompt":"Explain in plain English what a virtual private server is.","stream":false,"options":{"num_predict":256,"temperature":0}}'

This is a shortened version of the request our benchmark sends (ours also fixes "seed":42 and uses a longer prompt). The JSON reply contains the answer plus timers: load_duration, prompt_eval_duration and eval_duration, all in nanoseconds, and the token counts. Divide eval_count by eval_duration (in seconds) and you have generation tokens/s, the same way we calculated ours. On the CX33 the first 3B request spent 3.7 s loading the model; after that it generated 13.5 tokens/s.

If a model does not fit, this is the reply you get. Ours, from Llama 3.1 8B on the 4 GB CAX11 (3805 MiB total, no swap):

llama-server process has terminated: exit status 1: ggml_aligned_malloc: insufficient memory (attempted to allocate 4402.48 MB)

On the 4 GB Intel CX23 the same model failed in a sneakier way. There was no error at first: Ollama's fit check estimated 1698 MiB would stay free and started loading. After about 50 seconds the kernel's out-of-memory killer stopped the model process (llama-server, 3.5 GB of memory in use). If a request hangs and then dies on a small server, look in journalctl -e -u ollama and the kernel log for an OOM kill.

The fix is a smaller model or a server with more RAM. With Llama 3.2 3B loaded, the same server had 591 MiB left, and the 4 GB Intel CX23 had 817 MiB left (3002 of 3819 MiB used). Check your headroom with the VPS RAM calculator.

Step 7: reach Ollama from outside without opening 11434

The Ollama docs describe no login for the local API. Anyone who can reach the port can use your server's CPU and every model on it. Options, safest first:

• Keep it local. If the app that calls Ollama (n8n, a bot, a script) runs on the same server, it talks to localhost:11434 and you change nothing.
• SSH tunnel for yourself. From your own computer, ssh -L 11434:localhost:11434 you@your-server makes the remote Ollama appear on your local port 11434 while the server port stays closed.
• Reverse proxy with authentication and HTTPS if other people or services must reach it. Ollama stays on 127.0.0.1; only the proxy is public.

If you do need Ollama on another interface, the FAQ's method is systemctl edit ollama.service and, under [Service], Environment="OLLAMA_HOST=0.0.0.0:11434", then a reload and restart. Only do that behind a firewall rule that allows your own IPs. One more trap: if you run Ollama in Docker instead of the native install, Docker's documentation says published container ports are routed before ufw sees them, so a ufw rule will not protect them. The native install has no such problem.

Step 8: keep it running

• Updates: run the install script again. The Linux docs say you can pin a version by setting OLLAMA_VERSION when you run it.
• Memory: Ollama keeps a model loaded for 5 minutes after the last request by default. To free RAM now, send a request with "keep_alive":0, as our script does between models.
• One request at a time: the FAQ gives OLLAMA_NUM_PARALLEL a default of 1 per model. Fine for one app; plan for it before you share the server with several users.

Next step: see what your new install should deliver on your server size in our Ollama CPU-only performance report.