Ollama can run on CPU, but the experience varies enormously. Below is a relatively realistic configuration reference:

If you just want to try it out, a CPU VPS can be tried; if you want to truly replace APIs, use it with multiple people, or connect it to business systems, prioritize a GPU VPS, and especially look at VRAM, not just CPU core count.

This article chooses Docker Compose deployment for simple reasons:

1. Ollama and Open WebUI can be managed separately.
2. The data directories are clear, making backup and migration easy.
3. If there is a problem, containers can be restarted individually without polluting the host.
4. Later, connecting Nginx/Caddy reverse proxy is also smoother.

If you are already using 1Panel, you can also install Open WebUI through the app store and fill in the Ollama address. But writing Compose by hand is more transparent and suitable for troubleshooting.

It is recommended to use Ubuntu 22.04 / 24.04 or Debian 12. First update the system and install Docker:

sudo apt update
sudo apt install -y ca-certificates curl gnupg
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

After logging in to SSH again, confirm Docker and Compose:

docker version
docker compose version

If the commands return version numbers normally, you can continue.

mkdir -p ~/ollama-webui
cd ~/ollama-webui
mkdir -p ollama open-webui

The directory meanings are simple:

• ollama/: stores model files.
• open-webui/: stores WebUI data, users, chat records, and configuration.

Model files can be very large, so it is recommended that your VPS has at least 50GB of available disk. If you plan to pull multiple models, 80GB or more is safer.

Create the file:

nano docker-compose.yml

Write the following content:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ./ollama:/root/.ollama
    expose:
      - "11434"

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    depends_on:
      - ollama
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data

There are two important security points here:

1. Ollama only uses expose and is not directly exposed to the public internet.
2. Open WebUI binds to 127.0.0.1:3000, first allowing only local access, and later opening HTTPS through an Nginx or Caddy reverse proxy.

Do not map 11434:11434 directly to the public internet. Once the Ollama API is exposed, others can directly call your model, which at best exhausts resources and at worst leads to abuse.

docker compose up -d

Check status:

docker ps

View logs:

docker logs -f ollama
docker logs -f open-webui

If Open WebUI does not start, common reasons are slow image pulling, insufficient disk, or insufficient memory. Do not rush to reinstall; look at the logs first.

Enter the Ollama container:

docker exec -it ollama bash

Pull a relatively small model for testing:

ollama pull llama3.1:8b
ollama run llama3.1:8b

If your machine does not have enough memory, pulling the model may succeed, but running it will be very slow and may even trigger OOM. Low-configuration VPS can first try smaller models, such as 3B or smaller quantized versions.

Exit the container:

exit

Assume your domain is ai.example.com. First point the DNS A record to the VPS IP, then install Nginx:

sudo apt install -y nginx certbot python3-certbot-nginx

Create the site configuration:

sudo nano /etc/nginx/sites-available/open-webui

Write:

server {
    listen 80;
    server_name ai.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
    }
}

Enable the site:

sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/open-webui
sudo nginx -t
sudo systemctl reload nginx

Issue the certificate:

sudo certbot --nginx -d ai.example.com

After completion, visit https://ai.example.com. The first time you enter Open WebUI, you will create an administrator account.

It is recommended to open only these ports:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Do not open:

• 11434: Ollama API port.
• 3000: Open WebUI internal port, already proxied by Nginx.

If you use a cloud provider security group, you must also restrict it there. Many people only configure UFW but forget the cloud firewall, so ports can still be accessed from the external network.

It is normal for a CPU VPS to run large models slowly; it is not necessarily a deployment error. You can judge from these aspects:

htop
free -h
docker stats
df -h

Common bottlenecks:

• Insufficient memory: after the model loads, available memory is almost 0, and the system starts swapping.
• CPU does not support AVX2: inference speed will be worse.
• Disk too slow: model loading takes a long time.
• Too much concurrency: fine for one person, but lags when multiple people ask at the same time.

Optimization suggestions:

1. Start with small models; do not go straight to 14B/32B.
2. Limit the number of users; do not use a personal VPS as a public AI service.
3. Put the model directory on an NVMe disk, not on a very slow large-storage VPS.
4. If you really need daily use, consider a GPU VPS or a local machine with a graphics card.

Update containers:

cd ~/ollama-webui
docker compose pull
docker compose up -d

Back up data:

tar -czf ollama-webui-backup-$(date +%F).tar.gz ollama open-webui docker-compose.yml

If model files are too large, you can also back up only open-webui/ and docker-compose.yml, and re-pull the models later.

In the following situations, it is recommended to use an API directly or choose a GPU service:

1. You only have a cheap 1C1G / 1C2G VPS.
2. You want multiple people to use it at the same time.
3. You need stable, fast responses.
4. You need to run 14B, 32B, or larger models.
5. The VPS disk space is very small, only around 20GB.

Ollama deployment is simple, but what is truly difficult is cost and performance expectations. If you are just learning, an ordinary 4C8G VPS can be experienced; if you want long-term use, it is best to start evaluating from 8C16G or a GPU VPS.

The value of Ollama + Open WebUI is not "free replacement for all AI APIs," but that you can control data, models, and access entry points in your own hands. For personal knowledge bases, internal Q&A, code snippet lookup, and small-team private assistants, it is very attractive.

But VPS selection must be realistic: CPU-only can run, but that does not mean the experience is good; enough memory to pull a model does not mean it is usable by multiple people; ports can be opened, but that does not mean they should be exposed to the public internet. The correct approach is to first validate with a small model, then decide whether to upgrade to a higher-configuration VPS or GPU VPS based on latency, memory, disk, and concurrency requirements.