Open WebUI

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform designed to operate entirely offline. It supports various LLM runners like Ollama and OpenAI-compatible APIs, with built-in inference engine for RAG, making it a powerful AI deployment solution.

Installation

For Ubuntu Users

Set up Docker’s apt repository:

sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Note:If using an Ubuntu derivative (e.g., Linux Mint), use UBUNTU_CODENAME instead of VERSION_CODENAME.

Install Docker Engine:

  sudo apt-get update
  sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Verify Docker Installation:

  sudo docker run hello-world

Step 1: Pull the Open WebUI Image

Start by pulling the latest Open WebUI Docker image from the GitHub Container Registry.

  docker pull ghcr.io/open-webui/open-webui:main

Step 2: Run the Container

Run the container with default settings. This command includes a volume mapping to ensure persistent data storage.

  docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

Important Flags

Volume Mapping (-v open-webui:/app/backend/data): Ensures persistent storage of your data. This prevents data loss between container restarts. Port Mapping (-p 3000:8080): Exposes the WebUI on port 3000 of your local machine.

Using GPU Support

For Nvidia GPU support, add –gpus all to the docker run command:

  docker run -d -p 3000:8080 --gpus all -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-   webui:cuda

Single-User Mode (Disabling Login)

To bypass the login page for a single-user setup, set the WEBUI_AUTH environment variable to False:

  docker run -d -p 3000:8080 -e WEBUI_AUTH=False -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

warning

You cannot switch between single-user mode and multi-account mode after this change. Advanced Configuration: Connecting to Ollama on a Different Server

To connect Open WebUI to an Ollama server located on another host, add the OLLAMA_BASE_URL environment variable:

  docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Access the WebUI

After the container is running, access Open WebUI at:

  http://localhost:3000

For detailed help on each Docker flag, see Docker's documentation. Updating

To update your local Docker installation to the latest version, you can either use Watchtower or manually update the container. Option 1: Using Watchtower

With Watchtower, you can automate the update process:

 docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once open-webui

(Replace open-webui with your container's name if it's different.) Option 2: Manual Update

Stop and remove the current container:

 docker rm -f open-webui

Pull the latest version:

 docker pull ghcr.io/open-webui/open-webui:main

Start the container again:

 docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

Both methods will get your Docker instance updated and running with the latest build.

🎙️ Troubleshooting Microphone Access

Ensuring your application has the proper microphone access is crucial for functionality that depends on audio input. This guide covers how to manage and troubleshoot microphone permissions, particularly under secure contexts. Understanding Secure Contexts 🔒

For security reasons, accessing the microphone is restricted to pages served over HTTPS or locally from localhost. This requirement is meant to safeguard your data by ensuring it is transmitted over secure channels. Common Permission Issues 🚫

Browsers like Chrome, Brave, Microsoft Edge, Opera, and Vivaldi, as well as Firefox, restrict microphone access on non-HTTPS URLs. This typically becomes an issue when accessing a site from another device within the same network (e.g., using a mobile phone to access a desktop server). Here's how you can manage these issues: Solutions for Non-HTTPS Connections

Set Up HTTPS:

It is highly recommended to configure your server to support HTTPS. This not only resolves permission issues but also enhances the security of your data transmissions.

Temporary Browser Flags (Use with caution):

These settings force your browser to treat certain insecure URLs as secure. This is useful for development purposes but poses significant security risks. Here's how to adjust these settings for major browsers:

Chromium-based Browsers (e.g., Chrome, Brave)

  Open chrome://flags/#unsafely-treat-insecure-origin-as-secure.
  Enter your non-HTTPS address (e.g., http://192.168.1.35:3000).
  Restart the browser to apply the changes.

Firefox-based Browsers

  Open about:config.
  Search and modify (or create) the string value dom.securecontext.allowlist.
  Add your IP addresses separated by commas (e.g., http://127.0.0.1:8080).

Considerations and Risks 🚨

While browser flags offer a quick fix, they bypass important security checks which can expose your device and data to vulnerabilities. Always prioritize proper security measures, especially when planning for a production environment.

By following these best practices, you can ensure that your application properly accesses the microphone while maintaining the security and integrity of your data.

Table of Contents