Self-hosted AI chat front ends in 2026: revisit Open WebUI, LibreChat and AnythingLLM before you paste another internal document into a public chatbot

Somewhere in your company today, a person is pasting a design document, a customer email or a stack trace into a public chatbot. They are rarely careless; the public tool is simply one browser tab away. Blocking that tab without offering a better option only moves the habit to a personal phone.

A self-hosted chat front end is the better option. It gives people a familiar chat screen, but the accounts, the chat history, the uploaded files and the choice of model stay under your control. In this post we revisit three active open-source projects in this space, Open WebUI, LibreChat and AnythingLLM, and look at history, licences, architecture, identity, document chat, agents and tools, storage and day-to-day operations.

This is not a ranking. No benchmark or hands-on drill was run for this post; the facts come from each project’s own GitHub repository, LICENSE files, documentation and release notes as of early November 2026. We also do not repeat the layers below the chat screen. If you are deciding how to route requests across providers, read our earlier post on AI gateways with LiteLLM, Bifrost and Agent Router. If you are running models yourself, see LLM inference serving with vLLM, SGLang and llama.cpp, and for the storage behind document search, vector search with pgvector, Qdrant, Milvus and Weaviate.

Why revisit AI chat front ends now

All three projects ship often, and each recent release changed something an operator should know about:

• Open WebUI v0.13.0 was released on 3 November 2026 (IST). It adds a tabbed workspace for files, terminals and previews, plus desktop and browser tabs that work with a connected Open Terminal. v0.12.5 came a few days earlier, on 29 October 2026.
• LibreChat v0.8.8 was released on 1 October 2026 (IST), and v0.8.9-rc1 followed on 27 October 2026 (IST). The v0.8.8 notes cover agent controls such as approving tool calls, a beta Agents API, experimental code workspaces, and security work on credential boundaries and tenant scoping. The repository has moved to the LibreChat-AI organisation.
• AnythingLLM v1.19.0 was released on 26 October 2026 (IST). It adds an optional built-in local LLM engine inside the Docker image (off by default) and, among the fixes, caps request body size to prevent an unauthenticated denial of service through the embed widget.

A chat front end is now an agent platform that can run code, call tools and reach other systems. That is a different risk profile from the simple chat screens of 2023, so old assumptions need to be revisited.

Shared concepts before you compare

Unlearn the idea that the chat front end is “just a UI”. In practice it does five jobs:

• Identity and roles. Who can log in, who is an admin, and who can see which models, prompts and knowledge bases.
• Connections to models. All three can talk to Ollama and to OpenAI-compatible APIs, which means they can sit in front of a local inference server or an AI gateway equally well.
• Document chat (RAG). Uploaded files are parsed, split, embedded and stored in a vector database. Those embeddings are a copy of your document content, so they need the same care as the documents.
• Agents and tools. Web search, code execution, MCP servers and custom tools let the model act, not only answer. Each tool is a new path out of the box.
• Storage. Users, chats, files, settings and secrets live in a database and on disk. That is now a system of record for very sensitive text.

Compare these five jobs, not the colour of the chat bubbles.

Open WebUI

Open WebUI started in October 2023 as Ollama WebUI, created by Timothy Jaeryang Baek; the old ollama-webui/ollama-webui repository address now redirects to open-webui/open-webui. It is a Python backend with a web frontend, installable with pip install open-webui or as a Docker image, and it connects to Ollama and OpenAI-compatible APIs.

What it does well

• Fast start. One container gives a working, multi-user chat with document upload and web search options. Image variants include a slim image that relies on external services for embeddings and extraction, a CUDA image and one bundled with Ollama.
• Rich identity options. The documentation covers OAuth and OIDC sign-in, LDAP, trusted header authentication and SCIM 2.0 provisioning. SCIM is described as included in the free edition with no licence key and no user limit.
• Clear role model. Three system roles: admin, user and pending. New sign-ups get DEFAULT_USER_ROLE, which defaults to pending, so an admin must approve them. Groups and permissions sit on top for finer control.
• Flexible storage. SQLite by default, PostgreSQL through DATABASE_URL. For vectors it supports many backends, including Chroma (the default), pgvector, Qdrant, Milvus, OpenSearch and others.
• Extensibility. Python Tools and Functions, OpenAPI tool servers and MCP servers.

What to check before you commit

• Licence. This is the one to read carefully. The current LICENSE is the “Open WebUI License”: BSD 3-Clause style terms plus a fourth clause that forbids altering, removing or replacing the “Open WebUI” branding. The exceptions are deployments with no more than 50 end users in any rolling 30-day period, specific written permission, or an enterprise licence. The repository history shows the project moved from MIT to BSD 3-Clause in January 2025 and added the branding clause in April 2025; older code keeps its earlier terms, as listed in LICENSE_HISTORY. Contributors must also accept a Contributor License Agreement. GitHub shows the licence as “Other”, so do not rely on the badge.
• Configuration that sticks. Many settings are marked ConfigVar. After first start, their values are saved in the database and the admin UI wins over environment variables, unless you set ENABLE_PERSISTENT_CONFIG=False. Teams that manage everything through Compose or Helm files get surprised by this.
• Scaling. The documentation warns that the default embedded Chroma uses local SQLite files and is not safe for multiple replicas. Move to PostgreSQL and an external vector database before you scale out.
• Code execution risk. The docs state plainly that Workspace Tools and Functions run arbitrary Python on your server, and that letting a user create or import tools is like giving them shell access. Keep that permission with a very small group.

LibreChat

LibreChat was created in February 2023 by Danny Avila. It is a Node.js application with a React frontend. The reference Docker Compose file runs it alongside MongoDB, Meilisearch for chat search, PostgreSQL with pgvector, and a separate RAG API service for document chat. Most behaviour is configured through a .env file and a librechat.yaml file.

What it does well

• Many providers, one screen. Native support for OpenAI, Azure OpenAI, Anthropic, AWS Bedrock, Google and Vertex AI, plus custom endpoints for any OpenAI-compatible API, including Ollama.
• Agents as a first-class feature. Agents can use MCP servers, file search, code execution and reusable Skills, and can be shared with specific users and groups. The v0.8.8 release added controls to interrupt agents and approve tool calls.
• Enterprise identity. Email login, OAuth2 and OIDC, and LDAP are listed in the README, and the documentation also covers SAML. A browser-based admin panel manages users, groups, roles and configuration overrides.
• Licence clarity. The LICENSE file is plain MIT.

What to check before you commit

• More moving parts. MongoDB, Meilisearch, PostgreSQL with pgvector and the RAG API each need backups, upgrades and monitoring.
• Secrets. The .env.example leaves CREDS_KEY, CREDS_IV, JWT_SECRET and JWT_REFRESH_SECRET blank and says LibreChat will generate temporary values; it asks you to set unique, persistent values before production. CREDS_KEY and CREDS_IV protect stored credentials, so treat them like database keys.
• Registration defaults. In .env.example, ALLOW_REGISTRATION and ALLOW_EMAIL_LOGIN are true. The source code shows that the first registered user in a single-tenant deployment becomes ADMIN. Create your admin first, then close open registration or move to SSO.
• Release labelling. On GitHub, LibreChat marks its releases, including v0.8.8, as pre-releases. Read the changelog and pin image tags rather than following a moving tag.
• Experimental features. The project itself labels code workspaces as highly experimental and agent plugins as experimental. Keep them off in production until you have tested them.

AnythingLLM

AnythingLLM is built by Mintplex Labs; the repository was created in June 2023. It is a monorepo with a React frontend, a Node.js server and a separate collector service that parses documents. It ships as a desktop app and as a Docker image, and the Docker version is the one that supports multiple users.

What it does well

• Document chat out of the box. Workspaces group documents and chats. A built-in embedder, LanceDB as the default vector database and a built-in transcription model mean a small team can start without extra services.
• Wide provider support. Ollama, LM Studio, LocalAI, generic OpenAI-compatible APIs, LiteLLM and many hosted providers are listed, and vector databases include pgvector, Qdrant, Milvus, Chroma and Weaviate.
• Agents and automation. No-code agent flows, custom agents, MCP compatibility and scheduled tasks are documented.
• Embeddable chat widget for websites, and a developer API.
• Licence clarity. The LICENSE file is MIT, copyright Mintplex Labs Inc.

What to check before you commit

• Access is off until you turn it on. The security documentation describes single-user mode, where an optional password protects the whole instance and anyone with it can change any setting and see all chats, and multi-user mode with Admin, Manager and Default roles. Enabling multi-user mode creates the first admin, and the docs warn you cannot switch back. For anything beyond one trusted person, decide this on day one. If you need OIDC or SAML, confirm the current options in the docs before you commit.
• Telemetry is on by default. The README says anonymous usage telemetry is collected through PostHog and can be turned off with DISABLE_TELEMETRY="true" or in the Privacy settings. It also lists other outbound connections that remain.
• Storage. The default database is SQLite at storage/anythingllm.db. The Prisma schema has commented instructions for switching to PostgreSQL. Mount the storage folder on the host, as the Docker guide recommends, and back it up.
• Embed widget exposure. A public widget is an unauthenticated entry point. The v1.19.0 body size cap shows why it deserves rate limits and monitoring.

Security and privacy: the part that decides the project

Whichever tool you pick, these points matter more than features:

• First user becomes admin. In Open WebUI the first account on a fresh install is automatically admin, and in LibreChat the first registered user in a single-tenant deployment becomes ADMIN. Never expose a fresh instance to a network before you have created that account. Open WebUI’s own security notes describe a race in this window, fixed in 0.9.0 and tracked as CVE-2026-45675, which is a good reason to stay current.
• Close open sign-up. Use pending approval, disable registration, or move to SSO with group-based access.
• Admins can read chats. Open WebUI documents that ENABLE_ADMIN_CHAT_ACCESS defaults to true, and that turning it off only hides chats in the product; admins can still reach data through the database or server. Tell users honestly who can read what.
• API keys. Provider keys stored in the front end are as valuable as the provider account. Prefer pointing the front end at your own AI gateway with scoped, budgeted keys, so a leak has a ceiling. Open WebUI user API keys are off by default (ENABLE_API_KEYS=False); keep them off unless needed.
• Tools and MCP. Treat every tool, Function and MCP server as code with network access. Approve them like you approve a new dependency.
• Retention. Chats, uploaded files and embeddings pile up quietly. Decide retention and deletion rules, and remember backups keep deleted data longer.
• Network exposure. Put the service behind HTTPS and your SSO or VPN. Do not publish it directly on the internet for convenience.

When to pick which

• Pick Open WebUI when you want the quickest path to a polished internal chat with strong SSO, SCIM and role controls, especially in front of Ollama or a gateway, and the branding clause is acceptable for your user count or you plan to keep the branding.
• Pick LibreChat when you need many providers side by side, agent workflows with approvals, and an MIT licence, and your team is comfortable running MongoDB and a few supporting services.
• Pick AnythingLLM when document workspaces are the main need, you want a desktop option for individuals and a Docker option for teams, and you want few external dependencies at the start.
• Pilot only one first, measure adoption and support load, then decide.

A small example

This is an invented example, not a real company. Consider a 120-person logistics software firm in Nagpur. Developers paste logs into public chatbots, and the sales team uploads customer RFP documents for summaries. The CTO wants one approved internal option within a month.

A calm plan would be: run the chosen front end on an internal subdomain behind their existing OIDC login, pointing only at the company AI gateway, which holds the provider keys and a monthly budget. Create the admin account before opening the network port. Keep new users pending or bound to SSO groups, allow tool creation only for two platform engineers, and use PostgreSQL and an external vector database from day one. Set a 180-day chat retention rule, back up nightly and test a restore every quarter. After two weeks of notice, announce that internal documents go only to the internal tool.

Practical checklist

• Write down the five jobs you need: identity, model connections, document chat, tools and storage.
• Read the LICENSE file yourself, especially the Open WebUI branding clause and its 50-user exception.
• Create the first admin before any network exposure, then close or control sign-up.
• Integrate SSO and map groups to roles.
• Point the front end at a gateway or inference server you control; keep provider keys out of user hands.
• Restrict who can add Tools, Functions or MCP servers.
• Choose production storage: PostgreSQL or MongoDB as required, and an external vector database if you will scale.
• Turn off telemetry or community features you do not want, and document outbound connections.
• Set retention, backups and a tested restore.
• Pin versions, read release notes, and schedule upgrades.

Closing thought

People paste internal documents into public chatbots because the safe path is slower. Revisit that, learn how these front ends really handle identity, data and tools, and give your team an internal option that is just as easy. Then the old habit stops on its own.