LibreChat Review 2026: Self-Hosted ChatGPT with Every Model

What LibreChat is and who it's for

LibreChat is an open-source, self-hosted chat interface that connects to many AI model providers. The project describes itself as an enhanced ChatGPT clone. You run it on your own server, bring your own API keys, and talk to models from OpenAI, Anthropic, and others through one web UI.

The pitch is simple: instead of paying for multiple subscriptions or juggling several chat apps, you get one place to use whichever model you want. The repository, at github.com/danny-avila/LibreChat, shows a project that has grown into a full-featured platform with agents, MCP support, and multi-user authentication.

Who is it for? Developers and small teams who already have API access to model providers and want a controllable, private chat front end. It also appeals to people who dislike the locked-in feel of proprietary chat apps. If you want to avoid sending conversations to a third-party SaaS and instead keep everything on your own infrastructure, LibreChat gives you that option.

It is not for non-technical users. Setup requires Docker, environment variables, and some comfort with configuration files. The docs assume you know what an API key is and how to edit a YAML file. If that sounds like you, read on.

Docker setup and provider config

LibreChat ships with a Docker Compose setup. The official documentation walks you through cloning the repo, copying the example environment file, and running docker-compose up. That gets you a local instance with a default configuration.

The key step is setting provider API keys. You put them in the .env file. For OpenAI, you set OPENAI_API_KEY. For Anthropic, ANTHROPIC_API_KEY. The docs list many other providers, but the pattern is the same: add your key, restart the container, and the models appear in the UI.

One thing that stands out from the docs is the flexibility in model configuration. You can define custom model endpoints, set custom model names, and even point to a local server like Ollama. That means you can use LibreChat as a front end for both cloud APIs and local models. The configuration is done through a librechat.yaml file, which gives you control over which models are shown, their display names, and their parameters.

Docker is the recommended path, but the repo also includes instructions for running without Docker if you prefer. The docs mention that you need Node.js and MongoDB for a non-Docker setup. MongoDB is a core dependency; LibreChat stores conversations and user data in it. That is worth knowing before you start, because it adds operational overhead. You are not just running a single container; you are running at least two (the app and the database), plus possibly a vector database if you want retrieval features.

For a single user on a personal server, the setup is manageable. For a team, you will want to think about backups, upgrades, and how you manage the MongoDB instance. The docs cover backup and restore, but it is still something you own.

Agents, MCP, and skills support

LibreChat has moved beyond a simple chat UI. The repository shows active development on agents, which are configurable assistants that can use tools and follow custom instructions. You can create an agent with a system prompt, give it access to specific models, and enable tools like web search or code execution.

Model Context Protocol (MCP) support is a notable feature. MCP is an open standard that lets AI applications connect to external tools and data sources. LibreChat's docs describe how to add MCP servers, which means you can plug in things like a database connector, a file system tool, or a custom API. This turns LibreChat from a chat app into something closer to an agent platform.

Skills are another layer. The docs describe skills as reusable capabilities that agents can call. For example, you might define a skill that generates a specific type of report or queries a particular service. Skills appear to be a way to package prompts and tool calls into a named function that the model can invoke when relevant.

This is where LibreChat gets interesting for power users. Instead of just chatting, you can build semi-automated workflows. The catch is that all of this requires configuration and some understanding of how agents and tools work. The docs are thorough but dense. Expect to spend time reading before you get a complex agent running.

One limitation I see from the docs is that agent behavior depends heavily on the underlying model's tool-calling ability. If you use a weaker model, the agent may not reliably invoke the right tools. That is not a LibreChat flaw; it is a reality of current AI. But it means you should pick your models carefully when building agents.

Multi-user auth and team use

LibreChat includes user authentication out of the box. The default setup uses email and password, with options to enable social logins like Google or GitHub. The docs describe role-based access control, letting you designate users as admins or regular users.

For teams, this is a big deal. You can host one LibreChat instance and let several people log in, each with their own conversation history and settings. Admins can manage users, disable sign-ups, and control which models are available to whom. The docs mention the ability to set model access limits per user or role, which is useful if you want to control costs.

Cost control is a recurring theme. Since you bring your own API keys, every conversation costs you money. LibreChat does not have built-in billing or usage quotas beyond what you configure. You can set per-user model restrictions, but you are on your own for monitoring spend. The docs suggest using provider dashboards for that. For a small team, that is fine. For a large organization, you would want a more robust solution.

Another consideration is security. Self-hosting means you are responsible for securing the server, the database, and the API keys. The docs cover basic security practices, like using HTTPS and keeping your .env file out of version control. But if you are deploying for a company, you need to think about SSO integration, audit logs, and data retention. LibreChat has some of that, but it is not a turnkey enterprise product.

I would not pick LibreChat for a large enterprise with strict compliance needs. The project moves fast, and the feature set is broad, but the operational burden is real. For a small team of technical users, it is a solid choice.

LibreChat vs Open WebUI

Open WebUI is the other major self-hosted chat interface. Both projects are open source and aim to give you a ChatGPT-like experience with your own models. The comparison comes up often, so it is worth breaking down.

Open WebUI started as a front end for Ollama, the local model runner. It has since expanded to support OpenAI-compatible APIs, but its roots are in local models. LibreChat, by contrast, has always been about connecting to many cloud providers. That difference shapes the user experience.

If you run local models exclusively, Open WebUI might feel more natural. It has tight integration with Ollama, including model management and pull from the UI. LibreChat can connect to Ollama too, but it is not the primary focus.

On the other hand, LibreChat's multi-provider support is broader. The docs list dozens of providers, including OpenAI, Anthropic, Google, and many others. Open WebUI relies on the OpenAI-compatible API standard, which covers a lot, but not everything. If you want to use Anthropic's native API with all its features, LibreChat has an edge.

Feature-wise, both projects have added agents and tools. Open WebUI has its own function and pipeline system. LibreChat has agents and MCP. The approaches differ, but both are capable. The choice may come down to which ecosystem you prefer.

Community and momentum matter too. LibreChat's GitHub repository shows over 42,000 stars, which signals a large user base. Open WebUI also has a strong following. Both are actively maintained. I would look at the issue trackers and recent releases to see which project addresses the bugs you care about.

One practical difference: LibreChat uses MongoDB, while Open WebUI can use SQLite or PostgreSQL. If you already run PostgreSQL, Open WebUI might be easier to integrate. If you are comfortable with MongoDB, LibreChat is fine.

My take: if you want a single interface for many cloud models and you like the agent/MCP direction, LibreChat is strong. If you are primarily a local-model person and want a simpler stack, Open WebUI may suit you better. Neither is objectively superior; it depends on your setup.

GitHub stars, repo health, release cadence

As of this writing, the LibreChat repository has 42,824 stars. That is a high number for a self-hosted chat project and indicates broad adoption. The repository is at github.com/danny-avila/LibreChat.

Looking at the commit history and release tags, the project is actively developed. The maintainer, Danny Avila, pushes changes frequently. Releases come out on a regular cadence, often with new features and bug fixes. The docs are updated alongside the code, which is a good sign.

Issue response time is hard to gauge from the outside, but the volume of open issues is typical for a project this size. Many issues are feature requests or user questions rather than critical bugs. The project has a Discord community where users get help, which reduces the load on the GitHub issue tracker.

One concern with fast-moving projects is stability. LibreChat's feature set changes quickly, and breaking changes can happen between versions. The docs include upgrade notes, but you should read them before pulling the latest image. If you are running a production instance, pin your version and test upgrades in a staging environment.

Overall, the repo health looks good. The project is not abandoned, the community is active, and the release cadence is steady. That is reassuring for a tool you might depend on.

Verdict: who should use LibreChat and who shouldn't

LibreChat is a powerful, flexible self-hosted chat interface. If you are a developer who wants to use multiple AI models from one place, with the ability to build agents and connect external tools via MCP, it is one of the best options available. The Docker setup is straightforward, the docs are detailed, and the community is large.

I would recommend LibreChat to:

• Developers who already have API keys for OpenAI, Anthropic, or other providers and want a unified UI.
• Small teams that need multi-user access with role-based control and are comfortable managing their own server.
• Privacy-conscious users who prefer to keep their chat history on their own infrastructure.
• Tinkerers who enjoy configuring agents and exploring MCP integrations.

I would not recommend LibreChat to:

• Non-technical users who just want a chat app. The setup and maintenance are too involved.
• Large enterprises with strict compliance and security requirements. You would need significant engineering effort to harden and integrate it.
• People who want a zero-maintenance, hosted solution. Self-hosting means you own updates, backups, and uptime.

One more thing: cost. LibreChat itself is free, but you pay for the API usage. The live pricing data shows that top-tier models like openai/o1-pro cost $150 per million input tokens and $600 per million output tokens. Even mid-range models like anthropic/claude-opus-4 are $15 per million input and $75 per million output. If you use LibreChat heavily with expensive models, the API bill can grow quickly. There is no built-in spending cap, so you need to monitor usage yourself. That is a real consideration for teams.

In the end, LibreChat delivers on its promise: a self-hosted ChatGPT with every model you want to connect. It is not a product you install and forget, but for the right user, it is a powerful tool.

How this review was researched

This review is based on publicly available information: the official LibreChat documentation at librechat.ai, the GitHub repository at github.com/danny-avila/LibreChat, and the live AI model pricing data provided for this review. No hands-on testing was performed. All factual claims about features and setup come from the documentation and repository signals.