LibreChat is a self-hosted chat application that connects to model providers and optional tools. It does not itself supply the GPU inference engine. Separating the chat application from inference makes it possible to upgrade the interface, move models, and manage persistent data independently.
This guide describes a general Docker-based deployment. Commands and configuration must be checked against the release being installed; a customized installation should not be replaced with an upstream default configuration.
Understand the services
| Component | Purpose | Persistence concern |
|---|---|---|
| LibreChat API and frontend | Authentication, conversations, provider requests | Configuration, uploads, application secrets |
| MongoDB | Application records | Consistent database backup |
| Meilisearch, if enabled | Conversation search | Index data or a tested rebuild process |
| RAG API and vector store, if enabled | Document retrieval | Source documents, metadata, embeddings |
| Model server | Inference | Models, runtime configuration, capacity |
Not every installation needs every optional service. Start with chat and one provider, then add retrieval and tools after the baseline works.
Establish a baseline
Install Docker Engine and the Compose plugin using instructions for the host OS. Obtain LibreChat from its official repository and select a release or commit deliberately.
git clone https://github.com/LibreChat-AI/LibreChat.git
cd LibreChat
cp .env.example .envReview the selected release's environment template before startup. Generate independent random application secrets, configure authentication and registration policy, and keep the environment file out of source control. Preserve encryption secrets: changing them can make stored credentials unreadable.
docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=100 apiThe default service name is commonly api; use the names in your Compose file. Avoid publishing resolved Compose configuration or logs without redacting secrets.
Configure a model and test the boundary
Mount librechat.yaml where the application expects it and configure one supported endpoint. From inside the application container, verify that the endpoint is reachable. localhost inside a container refers to that container, not the Docker host or another model machine.
Test an ordinary response, a streamed response, a long request, and an intentional provider failure. Only enable tool use after the selected model and endpoint reliably support it.
Expose only the application
For a remote installation, put the web interface behind authenticated HTTPS. Keep databases, vector stores, and management endpoints private. Decide whether registration is permitted before publishing the login page; do not assume a reverse proxy supplies application authorization.
Bind host ports only to the interfaces that need them, and verify the resulting listeners rather than relying on the intended configuration.
Upgrade without losing custom work
Back up databases, uploads, secrets, and configuration first. Review local Git changes and release migration notes, then test the new image with a recoverable copy of the data. Record both the old and new image identities.
After an upgrade, test login, an old conversation, a new response, upload access, search, and any custom route. Never use docker compose down -v as routine maintenance: it can remove persistent volumes.