Open WebUI

Admin Settings > Database offers one-click config JSON export/import and a raw webui.db download, but the documented full restore is to copy the whole /app/backend/data volume to the new host and carry over WEBUI_SECRET_KEY, which the default Docker image generates into /app/backend/.webui_secret_key outside the volume; there is no single in-app import that restores a full instance. Export is immediate and needs no provider approval.

• Database.svelte (export/import UI)
• start.sh secret key file
• docker-compose.yaml
• Docs: Backups
• Docs: Database migration

All agent state (chats with tool calls, memories, models/system prompts, prompts, tools and functions as Python source, skills, automations, notes, channels, calendar, config, API keys, uploads and the Chroma vector DB) lives in the owner's data volume, which the documented migration route copies whole; the documented route also covers keeping WEBUI_SECRET_KEY, which decrypts the stored OAuth sessions. Uploaded source files and extracted text sit beside the vector index, and tool/MCP OAuth uses dynamic registration or owner-entered clients with the instance's own callback, not a provider broker.

• DB path in DATA_DIR
• Uploads and vector DB paths
• Chroma path
• File model keeps path and extracted text
• OAuth client registration and callback
• Docs: Database migration

Without a LICENSE_KEY (default empty) no licence server is contacted and no openwebui.com account is needed; the GitHub update check and Hugging Face model refresh are non-fatal and can be disabled with OFFLINE_MODE. The right to run rests on the non-OSI 'Open WebUI License' (BSD-3 plus a branding clause), which does not state that the grant is perpetual or irrevocable and calls branding changes a 'material breach'. Under G12 an irrevocable right to run is not established, so the pass is withheld.

• LICENSE
• Licence check only when LICENSE_KEY set
• LICENSE_KEY default and endpoints
• OFFLINE_MODE and update check flags
• Docs: Offline mode
• Docs: License

Ollama and any OpenAI-compatible endpoint are first-class connections, and embeddings (SentenceTransformers), speech-to-text (faster-whisper), text-to-speech (local transformers) and image generation (ComfyUI, AUTOMATIC1111) all have local engines. Tools run in the runtime, native tool calling works with any model that supports it, and a prompt-based 'legacy' mode covers models without native tool calling. No capability is tied to one vendor's hosted model.

• Ollama/OpenAI connection config
• Legacy prompt-based tool calling
• Local embedding default
• Audio engines
• Image engines

In the default self-hosted install, all state is in a SQLite database, local uploads and a local vector store inside the owner's Docker volume, so a current copy is always in the owner's hands whatever the provider does.

• DB path
• Volume mount
• Local storage provider default

State is stored in plain SQLite, with the schema defined by public SQLAlchemy models and alembic migrations, plus raw upload files and a Chroma store; tools and functions are stored as Python source. The only encrypted fields (OAuth session tokens, and valves if opted in) use keys derived from the owner-held WEBUI_SECRET_KEY.

• SQLite default
• Tool source column
• OAuth session encryption
• Migrations
• Docs: Chat data privacy and encryption

Model identity, per-model tools and system prompts, and effective config values (DB overrides env when ENABLE_PERSISTENT_CONFIG is on) are visible to the admin. No view shows the fully assembled context: the default task and tool-calling templates appear in the UI only as 'Leave empty to use the default prompt', several injected wrappers (memory context, skills list, conversation summary, Pyodide prompt) are hardcoded, and the DEBUG payload log is written before the model-level system prompt is applied. One shortfall is counted: assembled context content is not fully visible.

• Memory context wrapper
• Injected wrappers
• Empty-default templates
• Placeholder in admin UI
• System prompt applied late
• Persistent config precedence
• Docs: Logging

In the default self-hosted install the provider holds nothing: the image disables Scarf/anonymised telemetry, OpenTelemetry is off, the licence server is contacted only with a licence key, and community sharing to openwebui.com happens only when a user clicks share. The openwebui.com privacy policy covers only the provider's own website and community service.

• Dockerfile telemetry env
• OTEL default off
• Community share on click
• Open WebUI privacy policy
• Docs: FAQ

The source shows no paid placement, sponsored tools or remote announcements: there are no default models or tool servers, banners come only from local config, and web search is off by default. The enterprise/sponsor notice for instances above 50 users appears only in the admin user list and is not injected into the agent.

• DEFAULT_MODELS none
• Local banners
• Admin upsell notice

The audit log is off by default (AUDIT_LOG_LEVEL=NONE), and even when enabled it excludes /chat, /chats and /folders by default, truncates bodies to 2048 bytes, and never sees automation runs, which bypass the HTTP middleware. Chat history does keep tool-call names and arguments, but actions inside Python tools and other side effects are not recorded separately, and there is no mechanism to alert the owner when recording fails. Counted shortfalls: unrecorded entry paths, and silent recording failure (G12).

• Audit defaults
• Audit middleware
• Automations run via synthetic request
• Tool calls stored in messages

Audit log entries and chat records are plain JSON lines and database rows with no hash chaining, signatures or external anchor, so they can be changed without a trace.

• Audit writer
• Logger sink

Chat history and the audit log are written by server middleware; the model's built-in tools can only search and view chats, not change them. However, Tools and Functions run as arbitrary Python inside the server process with full access to webui.db and audit.log, and the code-execution paths are not documented as isolated from the record. The protection is not documented as a guarantee.

• Built-in tools list
• In-process exec of plugins
• Docs: Plugins warning

All components needed to run are public source that may be modified, and third parties can maintain forks; the branding clause restricts only rebranding above 50 users. Default Docker images are built by a public GitHub Actions workflow that emits an SBOM, but no signing, provenance attestation or reproducible-build procedure lets the owner tie the default ghcr.io image to the source.

• LICENSE
• Docker build workflow
• Docs: License

There is no agent identity: actions run under local user accounts, with JWTs or sk- API keys issued by the instance, and automations and subagents use short-lived JWTs for the owning user. Nothing lets a third party check that an action comes from the owner's agent.

• Auth tokens
• Automation JWT

Only the prompt library has version history, with diff and restore. Model definitions and their system prompts, config, memories, tools, skills and permissions are single rows with only an updated_at timestamp and no record of what changed or who changed it. For the agent's state as a whole, the product offers no way to see or attribute changes.

• Prompt history model
• Model table
• Config table
• Memory table

The admin can edit the RAG template, the task templates (title, tags, follow-up, query, autocomplete, image, tool calling, voice), the code-interpreter and compaction templates, and per-model, per-user and per-chat system prompts. Several injected instructions are hardcoded and editable only in source: memory wrappers and the memory-review prompt, the Pyodide environment prompt, skill wrappers, the conversation-summary wrapper, the emoji and MOA templates, and the built-in tool descriptions.

• Task template settings
• Hardcoded memory text
• Pyodide prompt
• Skill wrappers
• Emoji/MOA defaults

Settings > Personalization lists every memory item with edit and delete controls, plus delete-all. The other stores the agent reads across sessions (chats, notes, knowledge, calendar, automations) are itemised in the UI with edit and delete controls.

• Memory API
• Personalization UI

The owner can add Python tools, OpenAPI tool servers and MCP servers with no provider review, and every built-in tool category can be switched off per model; many also have global switches.

• Built-in tool toggles
• Tool server config
• Tool creation

Most protections are owner-configurable: code-execution engine, safe mode, pip installs for plugins, file limits, and local web fetch. The built-in web-fetch blocklist (cloud metadata endpoints and reserved ranges) is always merged with the owner's list and cannot be removed without editing source.

• DEFAULT_WEB_FETCH_FILTER_LIST merged
• Enforcement

The self-hosted instance changes only when the owner pulls a new image; the docs recommend pinning :vX.Y.Z tags, and Watchtower auto-updates are optional. The only remote data the code fetches from the provider is licence data, and only when LICENSE_KEY is set; there are no remote behaviour flags. Models are the owner's own connections.

• Docs: Updating
• Docs: Quick start
• Licence data fetch

Per-user and per-group permissions and per-tool access grants exist, but admins bypass them, and in a one-person business the owner is the admin. Web fetch and web search can be domain-filtered, but Python tools and MCP servers have no egress limits (on/off only). The model can create, update and toggle automations, which then run with tool approval forced to 'full', so the agent can route around the approval setting. Spend is treated as met under G11 (no payment capability). Counted shortfalls: on/off-only limits for tool egress, and a self-modification bypass path.

• Admin bypass
• Automation tools
• Approval forced full for automations
• Web search domain filter

A tool approval mode ('ask' or 'full') exists behind ENABLE_TOOL_PERMISSIONS (default off). It applies to all tools at once rather than per tool or action class, and automations and channel messages always run with 'full', bypassing it.

• ENABLE_TOOL_PERMISSIONS default
• Approval mode resolution
• Gate handling

The stop button halts the current chat's tasks, and admins can stop tasks one by one, but there is no single stop-all. Scheduled automations need a separate step (the global ENABLE_AUTOMATIONS switch or per-automation toggles).

• Stop tasks endpoints
• Per-chat stop
• Automations switch

No telemetry or content leaves by default, and sharing to openwebui.com is only per click. However, non-content outbound calls are on by default and not opt-in: the GitHub release check (ENABLE_VERSION_UPDATE_CHECK=true) and Hugging Face model auto-update at startup (RAG_EMBEDDING_MODEL_AUTO_UPDATE=true). Both can be turned off, for example with OFFLINE_MODE. There are no provider data terms for self-hosted use.

• Update check
• Update check default
• HF auto-update
• Telemetry off
• Docs: FAQ

Connection API keys are listed and removable under Admin > Connections, user API keys can be viewed and deleted, and tool/MCP OAuth sessions can be revoked per provider. All credentials are stored in the owner's own database; the provider holds none.

• Connection keys
• User API keys
• OAuth session revoke

No provider-side copy exists by default, so deletion means removing the owner's Docker volume and container, which also holds the secret key file. There is no one-step in-app deletion of the whole instance, no documented full-deletion procedure, and no confirmation; in-app deletion covers individual chats, memories and non-primary users.

• User deletion limits
• Docs: Updating (volume)
• Docs: FAQ