Open WebUI Self-Hosting Guide: Ollama, APIs, Docker, Security and Scaling

By AiCybr Editorial · Published August 10, 2026

Open WebUI is not an LLM runtime. It is a self-hosted interface and application layer that can sit in front of local or remote model providers. That distinction determines what hardware you need, where your data goes, and how you should secure the deployment.

The project currently supports Ollama, OpenAI-compatible APIs and Open Responses providers, and its official documentation provides Docker, Python and Kubernetes deployment paths. Docker is the project’s recommended starting point for most users. Open WebUI can run on Linux, macOS and Windows, including ARM64 systems such as Raspberry Pi and NVIDIA DGX Spark.

This guide focuses on the decisions that matter after the one-line install: which architecture to choose, what must persist, what changes when you add a GPU or multiple users, and why exposing an AI interface directly to the internet deserves more care than exposing a simple dashboard.

Quick decision table

1. Decide what Open WebUI will actually do

A useful deployment starts by separating three layers:

1. Interface/application layer: Open WebUI handles the browser experience, users, chats and integrations.
2. Inference layer: Ollama, vLLM, another OpenAI-compatible server, or a remote commercial API runs the model.
3. Infrastructure layer: Docker, a VM, bare metal or Kubernetes provides networking, storage and lifecycle management.

This separation prevents a common hardware-sizing mistake. Installing Open WebUI on a low-power server does not mean that server must also run a 70B model. You can keep the interface on one machine and point it at an inference server with the GPU resources the model needs.

Conversely, a completely self-hosted UI does not make a conversation local if the selected backend is a cloud API. Your data path follows the provider you choose.

2. Docker is the best default for most self-hosters

Open WebUI’s official quick-start documentation recommends Docker for most users. The standard container listens internally on port 8080 and the documented example maps it to host port 3000. The important part is not the exact command but the persistent volume mounted at /app/backend/data.

Without persistent storage, removing the container can remove the application state you expected to keep. Treat that data directory as stateful application data and include it in your backup plan.

Open WebUI publishes several image variants:

The rolling main and latest tags point to the newest build. For a service you care about, prefer a controlled update process and verify release notes before major upgrades rather than treating an automatically moving container tag as a maintenance strategy.

When Python makes more sense

The official project also supports installation through Python with pip or uv. This can be useful for lightweight or manually managed systems where a container runtime is undesirable. It shifts more dependency and service lifecycle responsibility to you, however.

When Kubernetes makes sense

Kubernetes is supported, but it is not a better home-lab installation simply because it is more sophisticated. Use it when you already operate Kubernetes or actually need orchestration, multiple replicas and externalized state.

3. Connecting Ollama and other model servers

For local AI, Ollama is the most straightforward pairing because Open WebUI supports it directly. The two services do not have to live in the same container or even on the same computer.

A common architecture is:

Browser
   |
Open WebUI
   |
   +---- Ollama on local GPU server
   |
   +---- vLLM / another OpenAI-compatible server
   |
   +---- optional remote API provider

This architecture has two practical advantages. The UI can stay available while you change inference hardware, and multiple inference backends can be presented through one interface.

The security implication is equally important: do not focus only on protecting port 3000 while leaving the inference API broadly exposed. A model endpoint can consume expensive compute and may expose capabilities you intended only for authenticated users.

4. Do you need a GPU for Open WebUI?

Not necessarily.

If Open WebUI is only the interface for a model running elsewhere, its host can be modest. GPU and VRAM requirements are primarily determined by the inference backend, model size, quantization, context length and concurrency.

Open WebUI does have functions that can benefit from local acceleration, and the project provides a CUDA image variant for NVIDIA GPU access. But that should not be confused with the GPU requirements of Ollama, vLLM or another model server.

This is why a small home server can host Open WebUI while a separate workstation handles local inference, or while the interface talks to remote APIs.

5. Authentication: avoid disabling it casually

The official quick start documents a single-user mode using WEBUI_AUTH=False, but it also warns that changing between single-user and multi-account modes later is not supported as a simple toggle.

For anything reachable by other devices, keeping authentication enabled is the safer default. Open WebUI is increasingly an application platform rather than a passive chat page: authenticated users may have access to inference, tools, code-related capabilities, knowledge stores and other integrations depending on how you configure it.

A deployment intended only for localhost is a different risk profile from one reachable across a LAN, VPN or public reverse proxy.

6. Network placement matters more than the install command

Open WebUI’s own hardening documentation describes it as infrastructure intended for private, trusted networks and compares its placement considerations to databases, container registries and CI systems.

For a home deployment, a useful preference order is:

1. localhost-only access when only one machine needs it;
2. trusted LAN access when household devices need it;
3. private overlay/VPN access for remote use;
4. internet-facing reverse proxy only when you understand and maintain the additional security boundary.

If you expose it beyond a trusted network, use TLS, strong authentication, prompt updates, restrictive firewall rules and a reverse proxy configured for WebSockets. Open WebUI’s documentation explicitly notes that WebSocket support is required.

Do not expose the Ollama or other inference backend simply because Open WebUI itself is protected.

7. Tools change the security model

A plain chat interface sends text to a model. An AI application with tools can potentially make network requests, execute configured functions, interact with files or services, and retrieve external information.

That means the right question is not merely, “Can someone read my chats?” It is also, “What can an authenticated account cause this deployment to do?”

Use the least privilege practical for tool integrations. Keep sensitive internal services outside the reach of tools that do not require them, and do not assume a model’s refusal behavior is an infrastructure security control.

For multi-user systems, test permissions with a normal user account rather than validating everything while signed in as an administrator.

8. Persistent data and backups

The official Docker example persists /app/backend/data. Back up the application data you actually depend on before upgrades, migrations or container changes.

Also remember that Open WebUI is only one layer of a local-AI stack. A useful recovery plan may need to cover separately:

• Open WebUI application data;
• model-server configuration;
• knowledge/document stores;
• external databases or vector databases;
• reverse-proxy configuration;
• identity-provider configuration;
• custom tools or pipelines.

Large model weight files are often reproducible downloads and may not deserve the same backup priority as unique application data. Decide that deliberately rather than backing up terabytes by accident.

9. Development builds should not share production data

The official documentation warns against sharing a data volume between dev and production images. Development builds can include database migrations that are not backward-compatible.

If you want to test a new feature, use a separate volume and preferably a separate test instance. This is a simple precaution that prevents an experimental upgrade from silently changing the state used by your working deployment.

10. Scaling past one instance changes the architecture

The one-container installation is intentionally simple. A multi-replica deployment is not just “run three copies.”

Open WebUI’s current documentation says clustered/multi-worker deployments need shared configuration and an external key-value database such as Redis. It also warns that the default ChromaDB arrangement uses local SQLite-backed storage that is unsuitable for concurrent multi-replica writes.

Therefore, high availability requires you to think about:

• shared session/state infrastructure;
• database/vector-store concurrency;
• identical secrets/configuration across instances;
• WebSocket-aware load balancing;
• persistent storage accessible in the way the chosen architecture expects.

For a home lab or one-to-five-user environment, a well-backed-up single instance is usually operationally simpler than premature HA.

11. Open WebUI on Raspberry Pi, mini PCs and DGX Spark

Open WebUI itself supports x86_64 and ARM64 platforms. The official quick-start documentation explicitly includes Raspberry Pi and NVIDIA DGX Spark among supported environments.

That does not imply equivalent model performance across those devices. The interface can run comfortably on hardware that would be inappropriate for a large local model.

This makes Open WebUI useful in split deployments:

• low-power mini PC: interface, authentication and lightweight services;
• GPU workstation: Ollama/vLLM and large local models;
• NAS: persistent document or backup storage;
• remote API: optional models that cannot be run locally.

The result is often more flexible than forcing the entire AI stack onto one computer.

12. Open WebUI + Ollama vs an all-in-one container

The bundled Ollama image can make a first installation convenient. Separate services are usually easier to reason about once the setup becomes important.

Bundled approach

• fewer moving pieces initially;
• convenient for experimentation;
• inference and UI lifecycle are coupled.

Separate approach

• upgrade Open WebUI without rebuilding your model runtime arrangement;
• place inference on another GPU host;
• connect several interfaces or applications to one model server;
• isolate networking and resource limits more deliberately.

For a durable home server, separate services are generally the more flexible architecture. The bundled image remains useful for testing or a simple single-host installation.

13. Open WebUI vs Ollama: they are complements, not substitutes

This is another common source of confusion.

Ollama primarily manages and serves local models.

Open WebUI provides a browser-facing application that can connect to Ollama and other providers.

You can run Ollama without Open WebUI, for example through its API or another client. You can also run Open WebUI without Ollama by connecting it to another supported backend.

A useful mental model is:

Open WebUI = interface/application
Ollama    = model runtime/server
Model     = the actual weights being executed

14. Practical deployment recommendations

Personal workstation

Use Docker or the supported desktop/Python route, keep access local, and connect directly to your preferred model backend. Avoid adding reverse proxies and external databases unless you need them.

Home lab

Use a persistent Docker deployment, keep authentication enabled, expose it only on the LAN or through a private remote-access layer, and keep inference APIs restricted. Back up Open WebUI’s state separately from replaceable model files.

Small technical team

Use authenticated accounts, explicitly review tool permissions, keep the service behind controlled network access, and establish a tested update/backup process. If using external model APIs, document which data leaves your infrastructure.

Larger or high-availability deployment

Follow the project’s multi-replica requirements rather than cloning the single-container pattern. Externalize the state that must be shared and validate database/vector-store behavior under concurrent workers.

15. What Open WebUI does not solve

Self-hosting the interface does not automatically provide:

• private inference when you select a cloud model;
• enough VRAM for the models you want to run;
• safe internet exposure;
• backups;
• secure tool permissions;
• high availability;
• model licensing rights;
• protection against every prompt-injection or agent/tool risk.

Those are properties of the complete deployment, not of the web interface alone.

Recommended architecture for most home users

For most technically comfortable home users, a strong default is:

Open WebUI in a persistent Docker container + authentication enabled + LAN/private-network access + Ollama or another inference server kept off the public internet.

Run the inference backend on the machine with the right GPU or memory rather than choosing the Open WebUI host around model requirements. Back up unique application state, test upgrades separately when practical, and add public exposure or multi-replica complexity only when there is a concrete reason.

That architecture keeps Open WebUI replaceable, the model backend flexible and the security boundary understandable.

Sources

• Open WebUI documentation
• Open WebUI Getting Started
• Open WebUI Quick Start
• Open WebUI Security
• Open WebUI hardening guide