Open WebUI Deep Dive: Users, Models, Documents, Prompts, and Safe Sharing

08/28/2026 10/02/2026

Tech Guru

The short answer: Open WebUI is suitable for a personal or shared homelab only when you patch it, keep signup controlled, separate admin and user accounts, grant models and knowledge bases explicitly, restrict tools, and back up the complete data volume. Self-hosting gives you control; it does not make every provider, plugin, upload, or tool private or safe.

This guide assumes an existing Docker installation administered by someone who can manage volumes, logs, DNS, TLS and firewall rules. The original interface examples were checked against v0.10.2 in July 2026; that is a historical reference, not a current security baseline. Check the installed release and target release notes before upgrading. Backup, group and file-management guidance was rechecked on October 2, 2026.

http://localhost:3000

The following LAN address is an example, not an instruction to expose the port. For another device, use an approved VPN or HTTPS path with authentication and a restricted origin; do not send account credentials over an untrusted plain-HTTP network.

http://192.168.1.100:3000

Use this deep dive as a map of what to configure after the first successful login.

Quick Feature Map

Interactive Open WebUI Map: What Each Area Does

Click each step to see what it means in a beginner-friendly local AI setup.

Select a step

Choose a box above to view details.

UsersAccounts

ModelsSwitching

KnowledgeDocs/RAG

AdminSettings

Area	What it does	Beginner example
Chat	The main place you talk to models	Ask Llama 3.1 to explain a log file
Models	The list of available AI models and custom model presets	Switch between a coding model and a writing model
Knowledge/Documents	Upload files so the AI can search them	Ask questions about a PDF manual
Prompts	Reusable slash commands	Type `/summarize` instead of pasting a long instruction
Users/Groups	Control who can log in and what they can use	Give family access but hide admin tools
Connections	Tell Open WebUI where model APIs live	Connect Ollama, OpenAI, LiteLLM, vLLM, OpenRouter, or another compatible API
API Keys	Let scripts call Open WebUI	Use a local automation script to send chat requests
Admin Settings	Instance-wide switches	Enable/disable signup, API keys, model defaults, RAG settings
Backups/Updates	Keep data safe and software current	Back up the Docker volume before pulling a new image
Proxy/VPN	Safer network access	Use Tailscale or Nginx instead of opening a random port to the internet

First Login and Users

The first account you create is the admin account. Save that login in your password manager. If you lose the first admin account, approving later users and changing settings can become annoying.

Open WebUI has three simple system roles:

Role	What it means	Give it to
Admin	Full control of users, settings, connections, and resources	Only the homelab owner or trusted maintainers
User	Normal chat access, limited by permissions and groups	Family, teammates, or your own non-admin account
Pending	Signed up but not approved yet	New accounts waiting for review

Beginner-safe setup:

Log in with the first admin account.
Open Admin Panel.
Go to Users.
Approve only the accounts you recognize.
Keep new users as User, not Admin.
Use groups when different people should see different models, prompts, or knowledge bases.

Manage groups under Admin Panel > Users > Groups. Grants are additive: a user receives the union of permissions from their groups. There is no deny override. A restrictive group cannot cancel a grant from another group, so inspect the user's complete membership before relying on an access boundary.

Good starter groups:

Group	Purpose	Example permissions
Family	Basic household chat	Chat and selected models
Power Users	Trusted technical users	More models, file uploads, maybe API keys
Admin Helpers	People who help manage the instance	Carefully selected admin-like permissions
Kids/Guests	Limited access	Selected models, no API keys or workspace tools; model choice does not guarantee safe answers

Important security note: be careful with workspace tools and functions. Some Open WebUI extension features can execute code on your server. Do not give that power to untrusted users.

Model Switching

The model selector is usually near the top of the chat screen. It decides which model answers the next message.

Simple model switching steps:

Open a chat.
Click the model name near the top.
Pick a different model.
Send a new message.
Compare the answer quality, speed, and style.

You can switch models inside the same conversation. The chat history remains visible, but the new model may understand the conversation differently. A small model may struggle with a long chat that a larger model handled fine.

Common model types:

Model type	Best for	Tradeoff
Small local model	Quick simple questions, private offline use	Weaker reasoning
Larger local model	Better answers on your own hardware	Needs more RAM/VRAM
Coding model	Code, scripts, error messages	May be less friendly for general writing
Cloud model	Strong reasoning and broad capability	Sends prompts to the provider you configured
Custom Open WebUI model preset	A reusable "agent" with system prompt, tools, and knowledge attached	Needs setup time

Open WebUI also has a Workspace > Models area. This is not just a download list. It lets you create a custom model preset on top of a base model.

Example: You have one base model called llama3.1. You can create:

Preset	Base model	Added behavior
Home IT Helper	`llama3.1`	Uses a system prompt about explaining steps slowly
Recipe Helper	`llama3.1`	Uses a cooking prompt and pantry knowledge base
Log Analyzer	`llama3.1`	Uses a troubleshooting prompt and lower temperature

This is easier for beginners than remembering which settings to attach every time.

Documents and Knowledge

Documents are where Open WebUI becomes more than a chat box. You can upload files and ask questions about them. This is often called RAG, short for Retrieval-Augmented Generation. In plain English: Open WebUI searches your documents, finds relevant chunks, and gives those chunks to the model so it can answer with context.

There are two common ways to use files:

Method	When to use it	Example
Chat upload	One-off file for one conversation	Drop in a PDF and ask for a summary
Knowledge base	Reusable collection of files	Build a "Homelab Manuals" collection

Beginner document workflow:

Open Open WebUI.
Go to Workspace.
Open Knowledge or Documents, depending on your version and menu layout.
Create a new knowledge collection, such as Homelab Notes.
Upload PDFs, text files, Markdown files, spreadsheets, or code files.
Wait for processing to finish.
Start a chat and attach or reference that knowledge collection.
Ask a specific question, such as: "Using the Homelab Notes knowledge base, how do I restart the media server?"

Tips for better document answers:

Tip	Why it helps
Use text-based PDFs when possible	Scanned images may need OCR before the model can read them well
Split huge topics into separate knowledge bases	"Networking", "Docker", and "Recipes" are easier to search than one giant pile
Ask specific questions	"What port does the guide say to use?" beats "Explain this"
Keep private docs private	Uploaded files live on your server, but approved users may access shared knowledge
Delete stale files	Old notes can cause wrong answers

Open your profile menu, then Settings > Data Controls > Manage Files > Manage. Current documentation says deleting a file there also removes its Knowledge Base associations and vector embeddings. Check the effect on every collection that uses it. This is not a promise to erase text already copied into chat answers, logs, exports, provider systems or backups; those need separate retention handling.

Prompts

Prompts are reusable commands. Instead of typing the same long instruction over and over, you save it once and call it with a slash command.

Example:

/summarize

A prompt can be simple:

Summarize the text below in plain language. Use short bullets. End with action items.

Or it can use variables:

Summarize this for {{audience}}. Keep the tone {{tone}}. Focus on {{topic}}.

Beginner prompt workflow:

Go to Workspace.
Open Prompts.
Create a new prompt.
Give it a short command name, such as summarize.
Paste the instruction.
Save it.
Open a chat.
Type /summarize.
Fill in any fields if the prompt asks for them.

Useful starter prompts:

Prompt command	Purpose	Example use
`/summarize`	Condense long text	Meeting notes, articles, PDFs
`/explain-like-newbie`	Slow explanation	Error messages and logs
`/rewrite-email`	Make a message clearer	Support emails or work replies
`/docker-help`	Troubleshoot containers	Paste `docker logs` output
`/compare`	Compare options	Mini PC vs used workstation

Keep prompts boring and clear. A good prompt tells the model the task, the audience, the format, and what to avoid.

Admin Settings That Matter First

Open WebUI has many settings. Do not try to learn all of them on day one. Start with the settings that affect access, models, documents, and safety.

Admin area	What to check	Beginner recommendation
Users	Who can log in	Keep unknown users pending
Groups	Shared permissions	Make a small number of clear groups
Connections	Model provider URLs and keys	Verify Ollama or OpenAI-compatible providers work
Models	Visible models and defaults	Grant only intended models; verify unauthorized API access is denied
General/Auth	Signup and API keys	Keep signup controlled; enable API keys only if needed
Knowledge/RAG	File handling and retrieval	Test with one small knowledge base before uploading everything
Data Controls	Files and exports	Learn where uploaded files are managed
Security/Network env vars	CORS, URL, cookies, secret key	Set these when using HTTPS or a reverse proxy

Good beginner defaults:

Setting idea	Safer choice
New user role	`pending`
Number of admins	As few as possible
API keys	Disabled until you need them
Workspace tools for regular users	Disabled
Public internet exposure	Avoid unless you understand reverse proxies and authentication
Backups	Before every update, plus scheduled backups

If you use Docker, many settings can be passed as environment variables in docker run or docker-compose.yml. For a normal homelab, Docker Compose is easier to maintain than a very long docker run command.

Connecting OpenAI-Compatible Providers

"OpenAI-compatible" means a service speaks an API shaped like OpenAI's API. It does not always mean you are using OpenAI. Many tools can provide an OpenAI-compatible endpoint, including LiteLLM, vLLM, LocalAI, OpenRouter, some cloud providers, and other gateways.

There are two different directions people confuse:

Direction	What it means	Example
Provider into Open WebUI	Open WebUI calls another model API	Add OpenRouter or LiteLLM under `Admin Settings > Connections`
Client into Open WebUI	Another app calls Open WebUI's API	A script sends a chat request to `/api/chat/completions`

Add a Provider to Open WebUI

Steps:

Log in as admin.
Open Admin Panel.
Go to Settings.
Open Connections.
Find the OpenAI-compatible section.
Add the provider base URL.
Add the API key.
If model auto-detection does not work, manually add allowed model IDs.
Click verify or save.
Return to chat and pick the new model from the model selector.

Example provider table:

Provider style	Base URL example	Notes
LiteLLM on your LAN	`http://192.168.1.50:4000/v1`	Useful as a gateway to many providers
vLLM OpenAI server	`http://192.168.1.60:8000/v1`	Common for self-hosted inference
OpenRouter	`https://openrouter.ai/api/v1`	Add a model allowlist to avoid clutter
Google Gemini OpenAI-compatible endpoint	`https://generativelanguage.googleapis.com/v1beta/openai`	Watch exact URL format in current docs

Beginner translation: the base URL tells Open WebUI where to send requests. The model ID tells Open WebUI what to ask for at that address.

Use Open WebUI as an API Endpoint

Open WebUI can also act like a model gateway for your own tools.

Basic steps:

Enable API keys if your admin settings require it.
Open your user settings.
Go to Account.
Generate an API key.
Store it like a password.
Call Open WebUI with a bearer token.

Example chat request:

curl -X POST http://localhost:3000/api/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1",
    "messages": [
      {
        "role": "user",
        "content": "Explain Open WebUI in one paragraph."
      }
    ]
  }'

API key safety:

Rule	Why
Treat API keys like passwords	They can use the account's permissions
Use a separate account for automation	Easier to disable if a script leaks
Restrict API key permissions if available	Limits damage
Do not paste keys into WordPress posts, GitHub, Discord, or screenshots	Leaked keys get abused

Backups

Your Open WebUI data is more important than the container. The container can be recreated. Your chats, users, uploaded files, database, settings, and vector data need backup.

Common Docker volume layout:

Data	Typical location inside container
Open WebUI database	`/app/backend/data/webui.db`
Uploads	`/app/backend/data/uploads`
Vector database	`/app/backend/data/vector_db`
Cache/log data	`/app/backend/data/cache`, `/app/backend/data/audit.log`

If you used the common Docker volume:

-v open-webui:/app/backend/data

then the Docker volume is usually named open-webui.

This Bash example is limited to one container named open-webui, with the existing named volume open-webui mounted at /app/backend/data and no other writers. Verify that all application data is local before using it. External databases, vector stores and object storage require coordinated backups instead. Preserve the deployment configuration, previous image and persistent secret separately in protected storage. Set BACKUP_IMAGE to a reviewed, already-downloaded helper image containing sh and tar; no image is fetched during downtime. Use a trusted native Linux Docker host and a private home directory with sufficient local capacity.

(
set -euo pipefail
umask 077
: "${BACKUP_IMAGE:?Set an approved local helper image tag or digest}"
docker image inspect "$BACKUP_IMAGE" >/dev/null
actual="$(docker inspect --format '{{range .Mounts}}{{if eq .Destination "/app/backend/data"}}{{.Type}}:{{.Name}}{{end}}{{end}}' open-webui)"
test "$actual" = volume:open-webui
docker volume inspect open-webui >/dev/null
backup_dir="$(mktemp -d "$HOME/open-webui-backup.XXXXXXXX")"
printf 'Backup destination: %s\n' "$backup_dir"
docker stop open-webui
test "$(docker inspect --format '{{.State.Running}}' open-webui)" = false
docker run --rm --network none \
  --mount type=volume,src=open-webui,dst=/data,readonly \
  --mount "type=bind,src=$backup_dir,dst=/backup" \
  "$BACKUP_IMAGE" sh -c 'umask 077; tar czf /backup/data.tgz -C /data .'
docker start open-webui
)

The block stops on errors. A failed stop prevents archiving; a failed archive leaves WebUI stopped for investigation. Do not add an unconditional restart trap. The new private directory prevents same-day overwrites; the archive may be root-owned and must remain protected. Test a restore, then encrypt/copy the backup off-host.

Stops Open WebUI so the database is not changing during backup.
Mounts the open-webui volume read-only.
Creates data.tgz in a new private directory under the administrator's home.
Starts the same container only after the archive command succeeds.

Restore test checklist:

Check	Done?
Backup file exists and is not tiny
You know where the file is stored
You copied it off the server
You tested restoring to a spare volume or test machine
You wrote down the container name and volume name

A backup you have never tested is only a hope.

Updates

Open WebUI updates usually mean replacing the container image while keeping the same data volume.

Safe beginner update flow:

Read the release notes if this is an important instance.
Back up the data volume.
Pull the new image.
Recreate the container with the same volume.
Check logs.
Open the UI.
Test one chat and one document search.

For a Docker-run deployment, first identify the running image and mounts without dumping environment secrets:

docker inspect --format '{{.Image}} {{json .Mounts}}' open-webui

Recover the original deployment definition before changing anything. Follow the release-specific update procedure with a reviewed target image and a tested pre-migration backup. Preserve the exact secret, volume, environment, network binding, proxy and GPU settings; do not replace them with a generic docker run command. Pull and verify the target before a controlled stop/recreation. If the original definition is unavailable, reconstruct and test it on an isolated clone first rather than deleting the running container.

For Compose, use the existing project directory and configuration, select the reviewed image there, and complete the backup/clone test first. The guarded sequence below must not run in a different project or against a newly generated secret:

docker compose config --quiet &&
docker compose pull &&
docker compose up -d

For a shared family or team instance, consider pinning a version instead of always using :main. Pinning means your docker-compose.yml names a specific release tag. That gives you more control, but you must remember to update intentionally.

Update safety table:

Situation	Recommended approach
Personal test box	Use disposable data; a moving tag can change between pulls
Daily family use	Back up first, then update manually
Team or production use	Pin versions and read release notes
Something breaks after update	Stop, preserve evidence, and restore the matching pre-migration data plus previous image if needed

Also set a persistent WEBUI_SECRET_KEY for serious deployments. If the secret changes unexpectedly, users may get logged out or encrypted tokens may stop decrypting correctly.

Reverse Proxy Basics

A reverse proxy sits in front of Open WebUI. Users connect to the proxy, and the proxy forwards traffic to Open WebUI.

Why use one?

Reason	What it gives you
HTTPS	Encrypted browser connection
Nice URL	`https://ai.example.com` instead of `http://192.168.1.100:3000`
Central access control	Add IP allowlists, SSO, or extra auth
Cleaner network layout	Open WebUI can listen only on localhost

Beginner mental model:

Browser -> HTTPS reverse proxy -> Open WebUI container -> model provider

The following loopback mapping and proxy fragments assume the proxy runs natively on the Docker host. In a bridge-network proxy container, 127.0.0.1 means that container, not the host. Use an explicitly shared private network and the WebUI service address instead; verify there is no publicly reachable origin port.

ports:
  - "127.0.0.1:3000:8080"

Then point the proxy to:

http://127.0.0.1:3000

Simple Caddy example:

ai.example.com {
  reverse_proxy 127.0.0.1:3000
}

Simple Nginx location example:

location / {
  proxy_pass http://127.0.0.1:3000;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  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_cache off;
}

Reverse proxy settings to remember:

Setting	Why it matters
WebSocket upgrade headers	Supports WebSocket connections; SSE streaming also needs buffering/cache controls
`proxy_buffering off`	Prevents broken or delayed streaming output
`CORS_ALLOW_ORIGIN`	Should match your real HTTPS URL when needed
`WEBUI_URL`	Helps links and OAuth callbacks use the right public URL
Secure cookies	Use when Open WebUI is served over HTTPS

For many homelabs, Caddy is the easiest reverse proxy. Nginx gives more manual control. Nginx Proxy Manager gives a web UI for people who do not want to hand-edit config files.

LAN and VPN Security

Do not confuse "local network" with "safe." A LAN can include guest Wi-Fi devices, old phones, compromised laptops, smart TVs, and visitors. If Open WebUI can reach powerful models, private documents, or API keys, protect it.

Access options:

Access style	Good for	Risk level
Localhost only	One person on the server	Lowest
LAN IP and port	Home use on trusted network	Medium
VPN/Tailscale	Remote private access	Lower than public port forwarding
Reverse proxy with HTTPS	Named domain and browser trust	Depends on auth and exposure
Public port forward	Internet access	Highest

Beginner-safe recommendation:

For one machine, use localhost.
For home devices, use LAN access only if your Wi-Fi is trusted.
For remote access, use Tailscale, WireGuard, or another VPN.
For public access, use HTTPS, strong authentication, rate limiting, and careful user permissions.
Do not expose Open WebUI directly to the internet with plain HTTP.

Tailscale-style flow:

Laptop/phone on tailnet -> encrypted VPN -> homelab server -> Open WebUI

Why VPN is beginner-friendly:

Benefit	Plain explanation
No public port required	Your router does not need to expose Open WebUI to everyone
Device-level access	Only your approved devices can connect
Works away from home	Use your home AI from a laptop or phone
Can still use HTTPS	Tailscale and proxies can provide browser-friendly HTTPS options

Minimum security checklist:

Task	Recommendation
Admin password	Use a long unique password
Signup	Keep new users pending or disable signup after setup
Admin accounts	Keep the count small
API keys	Enable only when needed
Tools/functions	Restrict to trusted admins
Documents	Share only with the users/groups that need them
Backups	Encrypt backups if they contain private chats or documents
Router	Avoid public port forwarding unless you know why
Updates	Back up first, then update
Logs	Review failed logins or strange traffic if exposed beyond localhost

A Simple First-Day Configuration Plan

If you are new, do this in order:

Confirm Open WebUI works from the server browser.
Create and save the first admin account.
Connect one model provider, such as Ollama.
Send one test chat.
Create one regular user account for yourself and keep admin separate.
Upload one small document and test a question.
Create one prompt shortcut.
Back up the Docker volume.
Decide how you will access it: localhost, LAN, VPN, or reverse proxy.
Only then invite other users.

Troubleshooting Quick Table

Problem	Likely cause	First thing to try
Other devices cannot connect	Server firewall, wrong IP, container bound to localhost	Test from server, then check `http://SERVER-IP:3000`
Model list is empty	Provider connection is wrong	Check `Admin Settings > Connections`
Ollama works on host but not in container	`localhost` inside Docker means the container	Verify the chosen host-reachable listener; a host alias alone cannot reach host loopback from a bridge container
Streaming looks broken behind proxy	Proxy buffering or WebSocket headers	Disable buffering and set upgrade headers
New user cannot chat	Account is pending or lacks permissions	Approve user and check groups
Uploaded document gives bad answers	Bad extraction, wrong knowledge base, weak model, small context	Try a text file, ask a specific question
Update did not change anything	Old container still running	Verify the selected image and existing deployment definition; back up before controlled recreation
Chats disappeared after restart	No persistent volume or wrong volume mounted	Stop and inspect the Docker volume before changing more

Evidence and Security Validation

Evidence status: this article is documentation-backed. TechGeeks reviewed current Open WebUI documentation, v0.10.2 release notes, and independent GitHub Security Lab analysis on July 15, 2026. TechGeeks did not deploy a fresh multi-user instance or independently reproduce an access-control vulnerability for this revision. The following is a reader-run acceptance and regression test, not a report of completed lab work.

Patch before testing. GitHub Security Lab documented a tool-restriction bypass in v0.6.43, and current release notes continue to include security and access-control fixes. Do not infer safety from the product being self-hosted, and do not expose an old instance while you decide whether to upgrade.

Inventory the deployment. Record the immutable image digest, database type, volume, WEBUI_SECRET_KEY handling, providers, API keys, enabled tools/functions, signup policy, groups, public URL, and reverse-proxy rules.
Create negative-test accounts. Use a pending account, an ordinary user, a group-limited user, and a separate administrator. In a private browser session, confirm each user sees only the assigned models, knowledge bases, chats, prompts, tools, and API features.
Test the API, not only the menus. From the ordinary account, directly request an unassigned resource and invoke a disabled tool through the supported API path. Both attempts must fail server-side; hiding a button is not authorization.
Plant canary content. Put a unique harmless string in a private knowledge base and another in a different user's file. Queries from unauthorized accounts must not retrieve either string. Repeat after group changes and after an update.
Test untrusted documents. Upload a benign file containing an instruction to ignore the user and call a tool. The application must not grant a document more authority than the user, and write-capable tools should require an explicit approval or remain unavailable.
Trace egress. Send a local-model chat while observing DNS and outbound connections. Repeat with web search, remote embeddings, image generation, and each plugin disabled and enabled so the privacy effect of every integration is known.
Restore, then upgrade. Restore the complete data volume and secret to a separate test instance, sign in as both admin and user, open a chat, retrieve a document, and call an allowed tool. Upgrade the clone first and repeat all negative tests.

Break-Glass and Data Boundaries

If authorization fails, stop public or cross-VLAN access first. Disable the affected tool or provider, revoke exposed API and OAuth tokens, preserve container, proxy, authentication, and audit logs, and keep the data volume unchanged for investigation. Do not erase the instance before determining which users, resources, and outbound services were reachable.

A rollback requires the previous image digest and a database copy from before migration. Recreating an older container against a database already changed by a newer release may not be supported. Keep the original backup read-only, restore to a new volume, and verify login and retrieval before switching traffic. Preserve the same secret when restoring encrypted tokens; rotate external credentials if the secret or backup may have leaked.

Uploads, chats, generated memories, logs, and vector indexes can contain personal data, copyrighted documents, source code, and secrets. Collect only what users are authorized to provide, define retention and deletion expectations, encrypt off-host backups, and review the privacy and data-use terms of every remote model, embedding, speech, image, and search provider. Open WebUI access control does not grant legal permission to process the content.

What This Evidence Does Not Prove

Passing role and group tests on v0.10.2 does not prove future releases or every API endpoint preserve the same authorization behavior.
A private knowledge-base setting does not prove retrieved chunks cannot cross a boundary through a plugin, shared model, administrator action, backup, log, or software defect.
HTTPS protects traffic in transit; it does not secure an overprivileged tool, weak account, exposed origin, compromised browser, or remote provider.
A successful backup archive does not prove recovery. Only a clean restore that exercises login, chats, files, retrieval, and tools validates the recovery path.
A local Ollama connection does not prove the entire workflow is local when web search, remote embeddings, image generation, speech, pipelines, or cloud models are enabled.

References

Sources fact-checked on 2026-07-15:

Open WebUI Docs - Home: https://docs.openwebui.com/
Open WebUI Docs - Sharing Open WebUI: https://docs.openwebui.com/getting-started/sharing/
Open WebUI Docs - Roles: https://docs.openwebui.com/features/authentication-access/rbac/roles/
Open WebUI Docs - Groups: https://docs.openwebui.com/features/authentication-access/rbac/groups/
Open WebUI Docs - Permissions: https://docs.openwebui.com/features/authentication-access/rbac/permissions/
Open WebUI Docs - Models: https://docs.openwebui.com/features/workspace/models/
Open WebUI Docs - Knowledge: https://docs.openwebui.com/features/workspace/knowledge/
Open WebUI Docs - Retrieval Augmented Generation: https://docs.openwebui.com/features/chat-conversations/rag/
Open WebUI Docs - File Management: https://docs.openwebui.com/features/chat-conversations/data-controls/files/
Open WebUI Docs - Prompts: https://docs.openwebui.com/features/workspace/prompts/
Open WebUI Docs - OpenAI-Compatible Provider Setup: https://docs.openwebui.com/getting-started/quick-start/connect-a-provider/starting-with-openai-compatible/
Open WebUI Docs - API Keys: https://docs.openwebui.com/features/authentication-access/api-keys/
Open WebUI Docs - API Endpoints: https://docs.openwebui.com/reference/api-endpoints/
Open WebUI Docs - Backups: https://docs.openwebui.com/tutorials/maintenance/backups/
Open WebUI Docs - Updating Open WebUI: https://docs.openwebui.com/getting-started/updating/
Open WebUI Docs - HTTPS and Reverse Proxies: https://docs.openwebui.com/reference/https/
Open WebUI Docs - HTTPS using Nginx: https://docs.openwebui.com/reference/https/nginx/
Open WebUI Docs - HTTPS using Tailscale: https://docs.openwebui.com/reference/https/tailscale/
Open WebUI Docs - Hardening Open WebUI: https://docs.openwebui.com/getting-started/advanced-topics/hardening/
Open WebUI Docs - Connection Errors: https://docs.openwebui.com/troubleshooting/connection-error/
Open WebUI v0.10.2 release notes: https://github.com/open-webui/open-webui/releases/tag/v0.10.2
Open WebUI security advisories: https://github.com/open-webui/open-webui/security
GitHub Security Lab, GHSL-2026-002 tool-restriction bypass analysis: https://securitylab.github.com/advisories/GHSL-2026-002_Open_WebUI/
OWASP GenAI Security Project, prompt-injection risk: https://genai.owasp.org/llmrisk/llm01-prompt-injection/

Categories: Homelab, Local AI, and Open WebUI

Tags: Homelab Local AI Ollama Open WebUI RAG Reverse Proxy VPN