Open-WebUI + Ollama on VPS: multi-user interface for local LLMs

Why add Open-WebUI to your Ollama server

Ollama exposes a REST API compatible with OpenAI — efficient for developers, inaccessible for other team members. Open-WebUI bridges that gap: a complete web interface that connects to Ollama (or any OpenAI-compatible provider) and turns an inference server into a collaborative tool.

With over 150,000 GitHub stars (MIT licence), Open-WebUI has become the reference frontend for Ollama. Its growth was amplified by Ollama's Series B — 65 million dollars raised in July 2026 — which accelerated adoption of the inference engine in development teams.

The project is active, continuously maintained, and publishes stable tags (v0.6.x at the time of writing). Its maturity allows it to cover needs well beyond chat: RAG on local files, management of multiple models, user groups and SSO integration via OpenID Connect.

What Open-WebUI concretely adds to your Ollama stack

Multi-user interface: each team member has their own account, history and conversations — without access to the raw API or command line.
Native RAG: import PDF, Markdown or Word files directly from the interface; Open-WebUI indexes them and injects them into each conversation's context.
Model management: download, delete and activate Ollama models from the web interface, without going through docker exec.
OpenID Connect SSO: connect Open-WebUI to your identity provider (Keycloak, Authentik, Google Workspace…) for unified access and centralised revocation.
Groups and roles: define who can access which models, who can upload files, who has administration rights.
No cloud dependency: all tokens, conversations and files stay on your infrastructure.

Hardware and software requirements

Open-WebUI runs in a Docker container and connects to Ollama via the internal Docker network. Both can coexist on the same VPS.

For a team of 5 to 10 people with quantised 7B models (Q4), plan for at minimum:

- 8 GB RAM (6 GB for the model + headroom for Open-WebUI and the system)
- 4 vCPU: CPU inference is slow with fewer cores; move to 8 vCPU for comfortable daily use
- 30 GB SSD storage minimum, plus space for your models (a 7B Q4 model ≈ 4.5 GB, a 13B model ≈ 8 GB)
- Docker and Docker Compose installed
- A domain name pointing to your VPS (required for TLS and SSO)
- A reverse proxy with HTTPS — Nginx, Traefik or Caddy (Open-WebUI requires HTTPS for secure session cookies)

If Ollama is already deployed on your VPS (see the article How to host Ollama on a VPS), you can skip directly to the Open-WebUI installation.

Deploy Open-WebUI and Ollama with Docker Compose

Create the Docker Compose file

Create a working directory then write the compose file:

mkdir -p /opt/openwebui && cd /opt/openwebui

Content of compose.yml:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=change-this-to-a-random-string
    volumes:
      - open_webui_data:/app/backend/data
    restart: unless-stopped

volumes:
  ollama_data:
  open_webui_data:

The WEBUI_SECRET_KEY must be a long random string: generate it with openssl rand -hex 32.

Start the stack

Start both services:

docker compose up -d

Check that both containers are active:

docker compose ps

Ollama may take a few seconds to start. Open-WebUI waits for Ollama to be ready thanks to depends_on, but if you see connection errors on first start, wait 15 seconds and reload.

Download a first model

From the host, download a model via Ollama:

docker exec -it ollama ollama pull llama3.1:8b

You can also do it from the Open-WebUI interface once logged in, under Administration Panel → Models → Download from Ollama.com.

Configure the Nginx reverse proxy with HTTPS

Open-WebUI listens on 127.0.0.1:3000. Create an Nginx virtual host to expose it over HTTPS:

server {
    listen 443 ssl;
    server_name openwebui.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/openwebui.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openwebui.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;

        # WebSocket (required for response streaming)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 300s;
    }
}

Obtain the certificate with Certbot:

certbot --nginx -d openwebui.yourdomain.com

Create the administrator account

Open https://openwebui.yourdomain.com in your browser. The first account created automatically becomes administrator. Enter an email and password.

From the administration panel (avatar icon → Administration Panel), you can:
- define whether new registrants are immediately active or pending validation;
- create user groups and associate models with them;
- configure SSO.

Configure OpenID Connect SSO

Open-WebUI natively supports authentication via OpenID Connect (OIDC). You can integrate it with Keycloak, Authentik, Authelia, or any compatible provider (including Google Workspace or Microsoft Entra).

In compose.yml, add the following environment variables to the open-webui service:

environment:
  - OAUTH_CLIENT_ID=your-client-id
  - OAUTH_CLIENT_SECRET=your-client-secret
  - OPENID_PROVIDER_URL=https://your-idp.example.com/.well-known/openid-configuration
  - OAUTH_PROVIDER_NAME=My SSO
  - ENABLE_OAUTH_SIGNUP=true

The callback URL to declare in your identity provider is https://openwebui.yourdomain.com/oauth/oidc/callback.

Restart the stack after modification:

docker compose up -d

To restrict SSO access to a specific email domain (e.g. @your-company.com), configure the restriction directly in your identity provider, not in Open-WebUI. Keycloak and Authentik both allow domain filtering at the OIDC client level — this is the safest control point, as it also covers the API.

Enable RAG on your documents

Open-WebUI includes a RAG (Retrieval-Augmented Generation) pipeline that allows you to query your local documents in a conversation. Processing happens entirely on your VPS — no document is sent to an external service.

To enable RAG:

1. From the interface, click the paperclip in the input area of a conversation, or use the Documents tab in the side menu.
2. Import a PDF, Markdown, DOCX or TXT file. Open-WebUI chunks it, vectorises it and stores it in its local database.
3. In the conversation, prefix your message with # followed by the document name to inject it as context.

For advanced use (multiple documents, thematic collections), the Workspace → Documents section allows you to organise files into collections and associate them with specific models.

By default, Open-WebUI uses its own lightweight embeddings engine. For better performance on a large corpus, you can configure a dedicated Ollama embeddings model (for example nomic-embed-text) in Administration Panel → Documents → Embeddings model.

Open-WebUI, AnythingLLM, LibreChat: which interface to choose

Criterion	Open-WebUI	AnythingLLM / LibreChat
LLM backend	Native Ollama + any OpenAI endpoint	OpenAI, Ollama, Azure, LM Studio
User management	Built-in, groups, native OIDC	Built-in (AnythingLLM: isolated workspaces)
RAG	Native, no configuration required	Native, configurable (LanceDB, pgvector)
GitHub stars	150,000+ (MIT)	40,000+ (MIT) / 20,000+ (MIT)
Primary use case	Team with Ollama already deployed	Advanced multi-source RAG / multi-backend chat

Troubleshooting: common errors

Connection refused on Open-WebUI startup.
Ollama is not yet ready when Open-WebUI tries to connect. Wait 20 seconds and run docker compose restart open-webui. To avoid this on every restart, add a healthcheck on the Ollama service in compose.yml.

Streaming stops after 60 seconds.
Your reverse proxy applies a default HTTP timeout. Add proxy_read_timeout 300s; in the Nginx location / block (or the equivalent timeout in Traefik). LLMs sometimes take several minutes to generate a long response.

WebSocket connection failed.
Verify that the Upgrade and Connection headers are correctly forwarded by the reverse proxy. Without them, SSE/WebSocket streaming is blocked and responses don't arrive in real time.

SSO authentication returns redirect_uri_mismatch.
The callback URL declared in your identity provider does not match what Open-WebUI sends. It must be exactly https://openwebui.yourdomain.com/oauth/oidc/callback — with the full domain name, no trailing slash.

An SSO user can log in but has no access to any model.
New accounts created via SSO are placed in the pending role by default if ENABLE_OAUTH_SIGNUP is not configured. Change their role to user in Administration Panel → Users, or set DEFAULT_USER_ROLE=user in the environment variables.

Secure access to the Ollama API

By default, Ollama listens on 0.0.0.0:11434 inside its container. The compose.yml configuration proposed above does not publish this port on the host — only Open-WebUI accesses it via the internal Docker network. This is the correct posture.

If you need to access the Ollama API directly (from an IDE, Jupyter notebook or external application), two options:

1. SSH tunnel: ssh -L 11434:localhost:11434 user@your-vps — the API is accessible locally without public exposure.
2. Reverse proxy with authentication: expose Ollama behind Nginx with auth_basic or a Bearer token, if you have clients that don't support SSH tunnelling.

Never publish port 11434 directly on the public interface without authentication: the Ollama API has no native protection against unauthorised access.

To keep Open-WebUI up to date, change the image from ghcr.io/open-webui/open-webui:main to ghcr.io/open-webui/open-webui:v0.6.x (or the latest stable tag) in your compose.yml. The :main tag follows continuous development — handy for testing new features, less predictable in production. Check the release notes on GitHub before each update: some versions have introduced database migrations.

Advanced features to explore after deployment

Pipelines and functions: Open-WebUI allows writing Python functions that intercept the conversation flow — filters, context enrichers, connectors to external APIs.
Custom models: create pre-configured 'models' (system instructions, temperature, context) and share them with specific user groups.
Image generation: connect Open-WebUI to a local Stable Diffusion or ComfyUI instance to generate images directly in chat.
Integration with external tools: via the MCP (Model Context Protocol) protocol, Open-WebUI can call external tools — databases, REST APIs, web search.

Official documentation

For advanced configuration and tool-specific options, refer to the official Open-WebUI documentation. This guide covers basic deployment and the most common configurations — parameters specific to your environment (LDAP integration, pipeline configuration, embeddings tuning) are in the project documentation.