How to Self-Host Open WebUI in 2026: Model Endpoints, Storage and Security

Treat Open WebUI as a small system, not a Docker image. The user-facing goal for Open WebUI is clear: chat interface for OpenAI-compatible and local model endpoints; the deployment is acceptable only when you can connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart.

That distinction catches the failure mode operators meet after local testing: OLLAMA_BASE_URL points at localhost inside the WebUI container. It also makes the backup and upgrade plan specific enough to test.

Choose the smallest viable Open WebUI topology

Start with the Open WebUI network namespace: its web listener is port 8080, not a host port copied from a laptop tutorial. The network contract for Open WebUI is an OpenAI-compatible API or reachable Ollama service. Keep private endpoints on internal DNS, permit only required outbound calls and give Open WebUI a scoped service credential.

After the requirement is satisfied, run the complete scenario — connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart. Record logs and measurements for model latency, concurrent streams, embedding jobs, uploaded file size and vector-index growth. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

TLS is easy; generated URLs are not

TLS issuance is only half of the Open WebUI route. Make the model endpoint reachable from the container network. Send traffic internally to 8080 and forward the external scheme so generated URLs and secure cookies remain consistent.

Use the complete Open WebUI scenario from a clean network, not merely the root page. A 502 or certificate failure can be isolated with automatic domain and TLS setup. If traffic reaches the process and OLLAMA_BASE_URL points at localhost inside the WebUI container, diagnose that condition where it occurs instead of stacking redirects.

Start Open WebUI without hiding the moving parts

Keep the initial Open WebUI invocation reproducible enough to review in a pull request.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v open-webui-data:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-with-a-long-random-value \
  ghcr.io/open-webui/open-webui:main

Do not rely on latest after real data exists. Capture the working digest, container user and mount ownership. Follow the application log through a complete test — connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart — and note any migrations before putting the route behind production traffic.

Upgrade Open WebUI without guessing

An idle health check says little about Open WebUI. Watch model latency, concurrent streams, embedding jobs, uploaded file size and vector-index growth, then alert on the symptom users experience: failure of the action “connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart”. Keep liveness local and cheap; let readiness report migrations or initialization without causing a restart storm.

The risky upgrade area is that database migrations, retrieval backends and model-endpoint settings can change independently of the chat frontend. Read release notes, snapshot state, deploy the target version against a restored copy and repeat the acceptance action. If OLLAMA_BASE_URL points at localhost inside the WebUI container, correlate the client request with the first relevant application log rather than deleting state or adding redirects blindly.

Five checks stronger than container health

Do not make first-user traffic the acceptance test for Open WebUI. Prepare harmless sample state and run the complete action “connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart”. Note the exact public URL, result, image reference and log interval associated with the run.

Replace the container and repeat without rebuilding data. Next, recover onto an empty host; the recovery condition is that accounts, chats, files and retrieval collections return and the restored instance can reach the same model endpoint. Observe model latency, concurrent streams, embedding jobs, uploaded file size and vector-index growth in every pass and define an alert around degradation of the transaction rather than around idle container metrics.

One final check should fail on purpose: temporarily deny the test identity access to an OpenAI-compatible API or reachable Ollama service. Verify that the resulting Open WebUI message identifies the relevant boundary instead of triggering data deletion or an endless restart. Restore the valid condition and confirm the same sample transaction succeeds. Keep this short drill in the release checklist.

Find every durable byte in Open WebUI

For Open WebUI, redeploy safety starts with users, chats, files, vector data and application configuration. Mount /app/backend/data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Test the path by replacing the container while harmless sample data exists; this exposes mounts pointed one directory too high or low.

Next test disaster recovery on a blank host. Use an application-consistent database export where necessary and verify that accounts, chats, files and retrieval collections return and the restored instance can reach the same model endpoint. The restore-tested database backup guide provides a stronger target than merely checking that an archive file was created.

Do not give Open WebUI the whole host

A secure Open WebUI deployment starts by removing authority. Avoid leaving signup open or using an ephemeral WEBUI_SECRET_KEY; instead, disable public sign-up unless intended, retain a stable WebUI secret and keep model administration limited to trusted users.

Treat WEBUI_SECRET_KEY according to its Open WebUI role: keep sensitive values out of Git, document rotation effects and never substitute a public example in production. Restrict administrative routes, use private DNS for dependencies and review every bind mount. When logs are shipped centrally, filter secrets and private content before they leave the server.

Use Dockup for the platform layer

Dockup removes manual reverse-proxy and lifecycle work around Open WebUI. The service receives a stable HTTPS route to 8080, injected configuration and persistent storage during replacements. An attached customer server follows the same model as Dockup-hosted compute.

After launch, satisfy the application contract: make the model endpoint reachable from the container network, connect and test an OpenAI-compatible API or reachable Ollama service and run this proof: connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart. This keeps the one-click experience useful without flattening the details that make Open WebUI recoverable and secure.

Frequently asked questions

What does Open WebUI need for a production deployment?

Route the Open WebUI container on port 8080 through one HTTPS origin. The supporting network requirement is an OpenAI-compatible API or reachable Ollama service. Do not call Open WebUI ready until you can connect one remote model endpoint, stream a chat response, upload a document, run retrieval and reopen the conversation after restart.

Which Open WebUI data belongs in a backup?

Persist /app/backend/data and include users, chats, files, vector data and application configuration in the same recovery manifest. A clean Open WebUI restore passes only when accounts, chats, files and retrieval collections return and the restored instance can reach the same model endpoint.

Does Open WebUI require HTTPS behind a reverse proxy?

Use HTTPS for the public Open WebUI origin and keep port 8080 on the internal route. Apply the Open WebUI setting correctly: make the model endpoint reachable from the container network. For Open WebUI, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should an Open WebUI upgrade be tested?

Restore current Open WebUI state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because database migrations, retrieval backends and model-endpoint settings can change independently of the chat frontend. Keep the previous Open WebUI image until its data-migration and rollback boundary are understood.