The use-case: Imagine your time wants to use the company’s internal AI system collaboratively. Possibly, your company hosts Ollama with an internal RAG pipeline to make internal documents available to its employees.

Open WebUI (OUI) provides a set of capabilities that make it ideal for this situation: It offers a flexible and secure solution for natural language processing (NLP) tasks by providing key features that enable data control, customization, and scalability.

One of the primary benefits is the ability to host and manage sensitive data locally, reducing the need to send it to third-party cloud services, which is particularly useful for organizations with compliance or regulatory requirements. Furthermore, Open WebUI allows teams to adapt the interface to suit their specific needs, integrating with internal tools, choosing models that best fit their tasks, and even customizing the UI to match their branding and user workflows.

In addition, Open WebUI supports multiple language models, enabling teams to switch between different LLMs (local or via API) depending on the task at hand. This flexibility allows for a trade-off between speed, quality, and cost. The platform also includes shared resources and consistency features, such as prompt management and document support, which enable teams to re-use what works and maintain consistency.

By providing open-source software, Open WebUI reduces vendor lock-in and allows organizations to choose models with favorable licensing terms or self-hosting options, reducing recurring API costs. With role-based access and shared deployment, teams can scale usage across many users within an organization, supporting collaboration, auditing, governance, and scalability of deployment.

Overall, Open WebUI offers a robust and customizable platform for NLP tasks that prioritizes data control, flexibility, and scalability while providing a cost-effective solution for organizations.

Installation: Open WebUI

Installing OUI is straightforward, some familiarity with Docker provided. The installation process is well documented, overall. For the use with Ollama, specifically, I needed to take some extra steps to make OUI “see” Ollama:

docker run -d --name open-webui \
    --network=host \
    --restart always \
    -p 3000:8080 \
    -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
    -v open-webui-data:/app/backend/data \
    ghcr.io/open-webui/open-webui:main

This launches OUI with host’s network stack inside the container, and OLLAMABASEURL set appropriately. I also had to instruct Ollama to use OLLAMA_HOST=“0.0.0.0” via my .bashrc, i.e., to accept connections globally.

When launching, wait for some minutes to let the container set itself up. We can check the process using docker logs open-webui. Then, OUI is accessible via localhost:8080. As we are on a cloud VM, we do not have a graphical browser available. Using curl, we can check availability nevertheless.

Setup: Nginx

So far, we have OUI available locally on our cloud VM. For employees to be able to use the interface, we need to make it available globally, via the internet. For this, we can use nginx (“engine-x”), an open-source tool that can function also as a reverse proxy, in that it accepts incoming client requests from the internet via port 80 (HTTP) or 443 (HTTPS) and forwards those to the apps, as configured. Here it helps to either familiarize oneself with nginx a priori, or seek aid - for example, via ChatGPT. Nginx provides plenty of options and while with some experience, configuring a HTTP-baseline, requesting SSL certificates, configuring HTTPS, etc., exceeds at least my current level of understanding. However, the configuration file organisation is clear.

server blocks define HTTP or HTTPS server logic. For our initial SSL certificate request, we leave HTTPS deactivated.

server {
    listen 80;
    server_name chat.companyXYZ.org www.chat.companyXYZ.org;

    # ACME challenge must bypass any auth and be readable
    location ^~ /.well-known/acme-challenge/ {
        auth_basic off;
        root /var/www/html;             # use the same webroot you tested with
        try_files $uri =404;
        default_type "text/plain";
    }

    # # Everything else: redirect to HTTPS
    # location / {
    #     return 301 https://$host$request_uri;
    # }
}

We now check that port 80 is open (check firewall or VM provider inbound rules), run certbot to obtain our certificates, first in test-mode using the dry-run flag and then, fingers crossed and no errors displayed, to obtain the actual certificates.

sudo certbot --nginx -d chat.companyXYZ.org -d www.chat.companyXYZ.org --dry-run

Using the nginx flag instructs certbot to use its nginx-plug-in to edit our nginx configuration automatically, facilitating the configuration process. Only now we activate the HTTPS-block. Here, we define among others the nginx-authentication directive:

server / {
  listen 443 ssl http2; # IP4 HTTPS
  listen [::]:443 ssl http2; # IP6 HTTPS
  server_name chat.companyXYZ.org www.chat.companyXYZ.org;
  auth_basic "Company XYZ Chatbot - Authentication Required";
  auth_basic_user_file /etc/nginx/.htpasswd;

  # CERTBOT SSL configuration ... (automagically added)
}

In this way, nginx will request authentication upon access, providing added security. Importantly, we need to make sure that OUI can provide its functionality without being hampered by nginx and its authentication mechanism. We define a set of authentication exceptions:

# server / {
# ...
# ... other server-block config mentioned previously
    location /api/ {
        auth_basic off;               # critical
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;          # do not repeat this again below
        proxy_request_buffering off;
        proxy_read_timeout 3600s;
        client_max_body_size 100M;
    }

    # ---- WebSocket: NO Basic Auth here ----
    location /ws {
        auth_basic off;               # critical
        proxy_pass http://127.0.0.1:8080/ws;
        proxy_http_version 1.1;
        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
        proxy_read_timeout 3600s;
        client_max_body_size 100M;
    }

    # ---- Ollama proxy: NO Basic Auth here ----
    location ^~ /ollama/ {
        auth_basic off;
        proxy_pass http://127.0.0.1:8080;  # Open WebUI will forward to OLLAMA_BASE_URL
        proxy_http_version 1.1;

        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_buffering off;
        proxy_request_buffering off;
        proxy_read_timeout 3600s;
        client_max_body_size 100M;
        }

    # --- Site config JSON used by Admin/Settings ---
    location = /config {
        auth_basic off;
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;

        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_buffering off;
        proxy_request_buffering off;
        proxy_read_timeout 3600s;
    }

And now we are ready to log into OUI. First access gets admin priviliges per default, so we may continue configuring the system for the use as a company chatbot.

In summary, setting up OUI with nginx on a self hosted VM is no rocket science, but some rocks must be moved out of the way first, in form of configuration that demands some getting used to.