Install Open WebUI on a VPS Without a GPU

Open WebUI gives you one browser interface for conversations with different AI models. It can be useful when a small team wants a shared entry point, or when you want to manage your own chat history and switch providers without changing applications.

The practical question is where the model runs. Installing a web interface on a small VPS is straightforward. Running a large model at an acceptable speed is a different workload. Connecting to a hosted API lets you start with ordinary VPS hosting and pay the model provider for the inference you use.

Open WebUI, Ollama and hosted APIs: what runs where?

Open WebUI supports local and cloud model providers. Ollama is one option for serving models, but it is not a requirement for an API connection. Here we disable unused Ollama discovery and use a separate provider account.

The official slim image leaves out much of the local machine-learning and document-processing stack. It suits this basic chat setup. PDF extraction, local embeddings, speech and other features can require additional services or the standard image; enable them only after checking their requirements.

Keep the project’s branding when following this recipe, and review the current Open WebUI licence before changing branding or redistributing a customised deployment.

1. Choose a VPS for the application

For a small initial deployment, 2 vCPU and 4 GB RAM is a reasonable planning allowance for the OS, Docker, Open WebUI and updates. This is a starting recommendation, not a measured concurrency limit. Watch memory, disk growth and response behaviour as usage increases.

• Use a maintained Linux server with sudo access and Docker Engine plus the Compose plugin. Our Ubuntu Docker guide covers installation.
• Allow SSD space for images, application data and temporary upgrade needs. Retention and uploads determine how quickly it grows.
• Have an account and API key for a supported model provider. Hosting the interface does not include API credits.
• For public browser access later, prepare a hostname such as ai.example.com pointing to your VPS. Bootstrap privately first.

Keep SSH access restricted and install the command-line tools used below if your image lacks them: sudo apt update && sudo apt install curl openssl nano. This guide assumes Docker is already running.

2. Deploy Open WebUI with Docker Compose

Create a dedicated directory. The bind mount keeps the database and other application files visible in one location for backups.

sudo install -d -m 755 /opt/open-webui
sudo install -d -m 700 /opt/open-webui/data
cd /opt/open-webui
sudo nano compose.yaml

Save this configuration as compose.yaml:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.5-slim
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY:?Set WEBUI_SECRET_KEY in .env}
      ENABLE_OLLAMA_API: "False"
      WEBUI_URL: "http://127.0.0.1:3000"
      CORS_ALLOW_ORIGIN: "http://127.0.0.1:3000"
    volumes:
      - ./data:/app/backend/data
    restart: unless-stopped
    logging:
      driver: local

The application is bound to 127.0.0.1 on the VPS, which we will reach through SSH. Port 3000 is not published on every network interface. See Docker's port publishing reference for that distinction.

Generate a secret, create .env and paste the generated value after WEBUI_SECRET_KEY=. Keep the value stable across container recreation.

openssl rand -hex 32
sudo install -m 600 /dev/null .env
sudo nano .env

WEBUI_SECRET_KEY=replace_with_the_generated_value

Use the real generated value, not the placeholder. Keep .env private and run these initial file-creation commands only for a new deployment; do not overwrite an existing secret file during an update.

sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=100 open-webui
curl --fail http://127.0.0.1:3000/health

The health endpoint checks the application, not whether your provider will answer a chat request. Give first startup time to complete, then inspect the logs if the endpoint does not respond. Avoid sharing logs or configuration output that contains credentials.

The pinned v0.12.5 release, published on 29 October 2026, includes security fixes. Read the current release notes before deploying or upgrading. The rolling main tag can change independently of a stable release.

3. Create the first administrator through an SSH tunnel

On your own computer, open a second terminal and forward a local port to the VPS. Replace the username and address with your normal SSH details.

ssh -N -L 3000:127.0.0.1:3000 your-user@your-vps-ip

Keep that terminal open, then visit http://127.0.0.1:3000 in your browser. If port 3000 is already occupied on your computer, stop the conflicting local service or choose a consistent alternative port and update the allowed origin.

Create your account. In this release the first account becomes administrator and further signups are disabled automatically. Confirm New Sign Ups is off in the Admin Authentication settings before sharing access. The versioned signup implementation documents that first-account behaviour.

Open WebUI separates Admin settings from personal settings. Add shared provider connections in the Admin area. Personal display preferences and defaults belong to the signed-in user.

4. Connect a hosted AI API

Open Settings → Admin → Connections and add a connection under the compatible API connections list. The official provider guide lists supported endpoints and any provider-specific limitations.

For example, a Mistral connection uses https://api.mistral.ai/v1 as its base URL and an API key from your provider account. Choose an available model from the discovered list rather than copying a model name from an old tutorial. Mistral's API quick start explains its account and request setup.

1. Enter the provider's base API URL and a key authorised for inference. Use a dedicated key with a spending limit where the provider offers one.
2. Verify the connection and save it. Keep the connection enabled.
3. Choose an allowed model and send a short test message.
4. Confirm the reply streams correctly and check the provider's usage view. Test as an ordinary user too if you plan to add a team.

Some providers do not expose the expected model-list endpoint. In that case, add their exact model IDs manually using the connection's Model IDs setting. A successful model-list request and a successful chat request test different things.

5. Add HTTPS when you are ready to share access

You can keep using the SSH tunnel for personal access. For a shared browser service, put a reverse proxy on the same VPS in front of port 3000. Point your domain's DNS to the server and allow TCP 80 and 443 through the relevant firewalls. Keep the application's 3000 port bound to loopback.

With Caddy installed as a host service using its official installation instructions, add this site block to /etc/caddy/Caddyfile, replacing the example domain. Preserve any existing site blocks.

ai.example.com {
    reverse_proxy 127.0.0.1:3000
}

Caddy's reverse proxy guide covers the basic configuration. Its proxy supports WebSocket upgrades. DNS and inbound reachability must work for automatic HTTPS certificate issuance.

Before switching access, set the public WebUI URL in Admin → General to https://ai.example.com. Update the Compose environment block to use that URL, the exact HTTPS origin and secure cookies:

      WEBUI_URL: "https://ai.example.com"
      CORS_ALLOW_ORIGIN: "https://ai.example.com"
      WEBUI_SESSION_COOKIE_SECURE: "True"
      WEBUI_AUTH_COOKIE_SECURE: "True"

Replace the existing URL/origin entries rather than duplicating them. Keep the other environment settings. Recreate the application with sudo docker compose up -d, then validate and reload the host Caddy service:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Use the HTTPS address from then on. Secure cookies deliberately prevent the earlier plain-HTTP tunnel login from working in the same way. Check login, a streamed reply and browser console errors. Open WebUI's connection troubleshooting guide covers origins, cookies and proxy behaviour. Our proxy comparison explains other approaches if you already use a proxy.

Fix “no models”, authentication errors and stalled replies

There is another easy source of confusion: saved Admin settings can override initial environment values. If you change a variable and nothing happens, check the saved setting in the Admin interface. The configuration reference explains which settings persist. Deleting the data directory to reset configuration also deletes user data.

Use sudo docker compose logs --since=10m --tail=100 open-webui while reproducing one failed request. If the VPS is short of memory or disk space, fix that separately from provider errors. Our OOM troubleshooting guide and disk-full guide cover those symptoms.

Start with ordinary chat before adding documents, functions or external tools. Those features introduce extra services, permissions and resource demands. The AI tooling security guide covers the broader operational questions.

Back up the data before upgrading

For this single-container SQLite deployment, schedule a short maintenance window, stop Open WebUI, and copy the complete data directory, Compose file and .env file to a protected backup. Then restart the container. Keeping the whole directory avoids overlooking files associated with the active database.

The project's backup documentation describes its persistent storage. Protect backups as carefully as the live instance because they can contain conversations and credentials. Keep an encrypted copy outside the VPS and test recovery on an isolated machine.

A HYEHOST Storage Box can hold encrypted backup files through SFTP; our rclone walkthrough covers that transfer. A snapshot is useful before a change, but retain a separate recovery copy too.

When upgrading, read the release notes, update the image tag deliberately and follow our Compose update procedure. Database changes may affect rollback, so keep the matching backup and old image version until you have verified login and a real chat request.

Plan the VPS and API costs separately

The recurring costs are the application server, model API usage and backups. If several people share one provider connection, check its spending controls and Open WebUI user permissions before adding them. A larger VPS does not increase a provider's quota or fix its rate limit.

HYEHOST Cloud VPS provides Linux root access in Wolverhampton, Ashburn and Auckland. Choose a region appropriate for your users and the data you store, then check connectivity to your chosen model endpoint. Keep capacity for the application, retention and updates. Large-scale local model inference needs its own hardware assessment.

Open WebUI VPS FAQ