TL;DR: Open WebUI v0.11.0 (released July 27, 2026) is the biggest release since Pipelines: a visually rebuilt interface, remappable keyboard shortcuts, chat forking, per-user usage dashboards, LDAP group sync, and a long list of security fixes that make staying on v0.10.x a bad idea. Upgrade to the current patch release (v0.11.3, August 31, 2026), not v0.11.0 itself. Back up your data volume first — Open WebUI database migrations are one-way.

	Upgrade to v0.11.3 now	Wait on v0.10.x	Skip Open WebUI entirely
Best for	Almost everyone, especially multi-user instances	Instances with custom functions/plugins you haven’t tested against v0.11	Solo terminal users happy with Ollama’s built-in agent
What you get	Rebuilt UI, shortcuts, usage stats, ~30 security fixes, big performance wins	Nothing new — and known security issues fixed in v0.11 stay open	Zero maintenance, no browser
The catch	One-way DB migration; a handful of defaults changed	Unpatched auth/permission bugs on a network-exposed service	No RAG, no multi-user, no web access

Honest take: If your instance has more than one user or is reachable from anything other than localhost, the security fixes alone decide this — upgrade this week, straight to v0.11.3.

Open WebUI has had the same core complaint hanging over it since we reviewed it in May 2026: the feature set is unmatched, but the interface got denser with every release, and settings were scattered across three different menus. v0.11.0 is the release that finally addressed that — 574 commits’ worth, per the release notes — while quietly shipping the largest batch of security hardening in the project’s history.

This guide is written against Open WebUI v0.11.3 (August 31, 2026), the current patch release, deployed via the official Docker image with Ollama as the backend. Open WebUI ships under the Open WebUI License — a BSD-3-based license with a branding-protection clause added in 2025. It’s source-available and free to self-host; deployments with 50 or fewer users can even remove branding, but it’s no longer plain MIT and isn’t OSI-approved. If strict OSI licensing matters to you, know that going in.

The interface rebuild, in practice

The release notes call it “visually rebuilt from the ground up,” which usually means a coat of paint. This one isn’t. The changes that matter day-to-day:

• Narrower conversation column, reorganized settings. Chat settings and admin settings are now grouped coherently instead of split across the chat view, a personal settings modal, and the admin panel. If you’ve ever spent five minutes hunting for where a toggle lives — this was the #1 usability complaint, and it’s fixed.
• Chat previews in the sidebar. Hovering a chat shows a compact preview of recent messages. With 200+ archived chats, this is the difference between finding a conversation and re-asking the question.
• Folder pages with unread indicators. Folders are now real pages with pagination, sorting by title or last-updated, and unread-chat dots. Automations can file their output into a folder automatically, so scheduled runs stop cluttering the main chat list.
• Local timestamps. Messages finally show times in your device’s locale format instead of the server’s.

Remappable keyboard shortcuts

Most shortcuts are now rebindable per account, with conflict warnings and a reset-to-defaults option. There’s also a global toggle to disable configurable shortcuts entirely — useful if Open WebUI’s bindings fight with your browser extensions (Vimium users know the pain). Settings → Interface → Keyboard Shortcuts. Bindings are saved per account, so your remaps don’t leak into other users’ sessions on a shared instance.

The model picker

For anyone running 30+ Ollama models, the picker matters more than any cosmetic change. v0.11 makes the model list lighter (profile images are no longer embedded in the list payload, and the list is fetched in fewer round trips), adds a model privacy toggle directly in the model list menu, and introduces a MODEL_ORDER_LIST environment variable so your preferred display order survives container restarts even without persistent config. Search-and-toggle pickers also arrived for Tools, Skills, Knowledge, Voice, Filters, and Actions.

Usage stats, notifications, and the multi-user story

Two v0.11 features push Open WebUI further ahead of every other self-hosted chat frontend for households and small teams:

Personal usage dashboard. Each user gets a Usage tab: token-activity heatmaps, current and longest streaks, lifetime and peak token counts, most-used models and tools. It’s per-user, not a global admin billing dashboard — admins who want org-wide accounting still need an external gateway like LiteLLM in front of their endpoints. But for answering “which model do I actually use?” it’s exactly enough.

Notification targets. A dedicated settings tab for webhook destinations, with event selection (chat finished, chat failed, channel messages, calendar alerts), per-target test buttons, and an away-only mode so you’re not pinged while actively using the UI. Point it at ntfy, Gotify, or a Discord webhook and your long-running generations report in when they finish. Assistants can also send notifications themselves, and the new chat timers can re-surface a prompt at a set time — auto-dropping if you’ve already read the chat.

For admin-side multi-user management, v0.11 adds LDAP group synchronization (map LDAP groups to Open WebUI groups, sync memberships at sign-in), dedicated on/off switches for OAuth providers that don’t wipe your configuration, and a USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS permission controlling whether users can share with groups.

Variables: the sleeper feature

Two related additions that got one line each in most coverage but change how you write system prompts:

• Chat variables: a system prompt can declare custom fields — text boxes, dropdowns — that render in the chat UI. Values are saved per conversation and carried through clones and forks. Build one “translator” model with a target-language dropdown instead of six near-identical model presets.
• User variables: personal values (role, writing preferences, timezone) stored in account settings and insertable into any system prompt. One shared model definition, personalized per user.

Combined with chat forking (every response now has a fork button that branches the conversation with memory of the split point), prompt engineering inside Open WebUI got meaningfully more programmable without touching Pipelines.

Performance: the unglamorous wins

The changelog lists 40+ performance items. The ones you’ll actually feel on a home server:

Bottleneck in v0.10.x	v0.11 fix
Automation scheduling took 20+ seconds to compute recurrences, worsening yearly	Near-instant recurrence calculation
Long chats saved slower as they grew (full reload-rewrite-reread on every save)	No re-read after write; single-field tag updates
Multi-megabyte non-English documents took many seconds to upload	Encoding sampled, not full-file scanned — seconds down to under one
Model list requests re-read connection settings up to 4 times (Ollama)	Read once per request
Streaming replies slowed progressively as the answer grew	New text scanned incrementally, not the whole answer per chunk
Model/pipeline/audio uploads spiked RAM and stalled the UI	Chunked, non-blocking streamed transfers

There’s also an opt-in ENABLE_ORJSON=true for a faster JSON encoder (stricter about input, off by default) and a compiled hiredis parser for Redis-backed deployments. On a Raspberry Pi or an old NUC — the kind of hardware a lot of Ollama + Open WebUI stacks run on (see runaihome.com for the hardware side) — this release is noticeably snappier even before you touch a single new feature.

The security fixes are the real reason to upgrade

v0.11.0 ships roughly thirty distinct security fixes. Read the list and it’s clear several were live permission-bypass bugs, not theoretical hardening:

• The Ollama version endpoint now requires sign-in — previously anyone who could reach your instance could enumerate versions anonymously.
• Deactivated accounts now actually lose live (WebSocket) access.
• Image generation and web search permission checks could previously be bypassed via a legacy request format.
• Folder-sharing permissions were being silently discarded instead of enforced.
• Read-only users could read tool source code and model settings.
• Malformed math formulas could achieve code execution via a crafted chat message; they now render as plain text.
• Internal-address masking (IPv6-mapped, 6to4, Teredo, NAT64 forms) is now recognized and refused in web fetches — an SSRF class relevant to anyone with web search enabled.

We covered in the Ollama exposed-instances guide how many self-hosted AI endpoints end up accidentally internet-facing. Open WebUI instances are commonly the public face of those stacks. Running v0.10.x with these bugs published in the v0.11.0 changelog is running a known-vulnerable service.

How to upgrade (and the traps)

The upgrade itself is standard Docker image replacement. Back up first — this is the step people skip:

# 1. Back up the data volume (SQLite DB, uploads, vector store)
docker run --rm -v open-webui:/data -v $(pwd):/backup alpine \
  tar czf /backup/open-webui-backup-$(date +%F).tar.gz /data

# 2. Pull and restart
docker pull ghcr.io/open-webui/open-webui:main
docker compose pull && docker compose up -d

# 3. Confirm the version
docker exec open-webui cat /app/package.json | grep version
# → "version": "0.11.3"

Database migrations run automatically on first boot of the new version. Expected output in the logs is a series of Alembic migration lines followed by a normal startup — on a large instance (thousands of chats), give it a minute before assuming it hung.

The known trap: jumping several minor versions at once. Large version skips (v0.9.x straight to v0.11.x) are where upgrade problems get reported in the project’s issue tracker — a container looping on a migration error instead of starting. The reliable path when you’re more than one minor version behind is stepping through an intermediate image tag (v0.10.2), letting its migrations complete, then moving to v0.11.3. And because migrations are one-way, the backup in step 1 is your only path back to v0.10.x if a custom function breaks — restoring the tarball over the volume is the rollback.

Defaults worth checking after the upgrade:

• “Chats Open Sharing” is off by default. Link-sharing chats to signed-out viewers needs an explicit admin enable (shared pages get no-index tags).
• Group sharing is on by default via USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS — turn it off if your instance’s groups shouldn’t see each other’s shares.
• ENABLE_PLUGINS now exists as a kill switch that hides Tools/Functions entirely and removes their execution paths — worth setting to false on instances where you never installed any, purely as attack-surface reduction.

When NOT to upgrade yet

• You depend on community functions or tools. The plugin event model changed (functions can now react to enable/disable events, and settings support multi-select). Most v0.10 functions work unchanged, but test on a second container before migrating your daily driver: docker run -d -p 3001:8080 -v openwebui-test:/app/backend/data ghcr.io/open-webui/open-webui:main.
• You run a heavily customized reverse-proxy auth setup. PKCE now applies to all OAuth providers and terminal SSO tokens moved from headers to sessions. Sound setups keep working; fragile ones surface their fragility.
• You’re a solo, terminal-first user. Ollama’s own built-in interactive agent now covers basic chat-with-a-local-model for one person with zero extra containers. Open WebUI’s case is everything beyond that: multi-user, RAG, web search, folders, automations. If you never open a browser for your LLM, you don’t need this upgrade — you may not need Open WebUI at all. For choosing between the browser frontends themselves, our LibreChat vs Open WebUI vs Chatbot UI comparison still holds; v0.11 strengthens Open WebUI’s position on exactly the polish axis where LibreChat used to win.

Verdict

v0.11 is the rare big release that improves the product on every axis at once — usability, performance, security — with no feature regressions and no monetization strings attached. The one-way migration and changed defaults are the only real friction, and both are manageable with a backup and five minutes in the admin panel. Upgrade to v0.11.3, not v0.11.0: the two August patch releases exist for a reason.

FAQ

Does upgrading from v0.10.x to v0.11.x lose chat history or workspace documents? No — migrations carry chats, knowledge bases, notes, and settings forward automatically. But migrations are one-way: once v0.11 has touched the database, downgrading requires restoring a pre-upgrade backup of the data volume, so take one before pulling the new image.

Is Open WebUI still open source after the license change? It’s source-available and free to self-host under the Open WebUI License, a BSD-3-based license with a branding-protection clause. It is not OSI-approved open source anymore. For home labs and internal deployments up to 50 users, nothing changes in practice.

Do I need to change my Ollama setup for v0.11? No. The Ollama connection config carries over unchanged, and v0.11 actually reduces per-request overhead against Ollama (connection settings are read once instead of up to four times). One behavior change: the Ollama version endpoint on Open WebUI’s API now requires authentication.

Sources

• Open WebUI v0.11.0 release notes — full changelog, July 27, 2026
• Open WebUI releases — v0.11.1–v0.11.3 patch notes, August 2026
• Open WebUI documentation — upgrade and environment variable reference
• Open WebUI license — Open WebUI License text

What self-hosting actually costs

Real cost breakdowns for self-hosted AI: hardware floors, power, maintenance hours, and the honest comparison against paying for it. No spam, unsubscribe anytime.

Email address Subscribe