# LibreChat: the compose file pulls librechat-dev:latest and the newest tag is a release candidate > A self-hosted chat interface in TypeScript with agents, MCP, skills, code artifacts, and a long list of model providers. The mechanics worth knowing before you deploy it: the compose file tracks a floating dev image, four Node HTTP timeout variables are documented as imprecise, and the Dockerfile copies five workspace manifests by hand. **danny-avila/LibreChat** — LibreChat is a self-hostable, ChatGPT-style chat interface that unifies many AI providers with model switching, agents, MCP tools and a sandboxed code interpreter. - Repository: https://github.com/danny-avila/LibreChat - Website: https://librechat.ai/ - Stars: 45,122 · Forks: 9,245 - Language: TypeScript - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/danny-avila-librechat ## The newest tag is a release candidate and the compose file tracks latest The three most recent releases are candidates for the same version: v0.8.8-rc4 on 2026-09-23, v0.8.8-rc3 on 2026-09-15, and v0.8.8-rc2 on 2026-09-03, spaced about eight to ten days apart, with no final 0.8.8 among them. The version appears in three places and all three agree, leading v included: the version field in package.json is the string v0.8.8-rc4, and the first line of the Dockerfile is a comment reading v0.8.8-rc4. The deployment path uses none of them. The api service in docker-compose.yml pulls `registry.librechat.ai/librechat-ai/librechat-dev:latest`, a floating tag on an image whose own name says dev. So an upgrade is a pull, and what arrives is whatever that tag pointed at that day. For anyone self-hosting, that single string is the most consequential line in the repository, and it sits in a file the file itself tells you not to edit. ## The compose file tells you not to edit it, and names its example with a different extension The first two lines of docker-compose.yml are an instruction and a naming trap: ``` # Do not edit this file directly. Use a 'docker-compose.override.yaml' file if you can. # Refer to `docker-compose.override.yaml.example’ for some sample configurations. ``` Both names end in .yaml. The file actually present in the repository is `docker-compose.override.yml.example`, and the compose file beside it is `docker-compose.yml`. The root holds four compose files altogether, `docker-compose.yml`, `deploy-compose.yml`, `docker-compose.langfuse-fanout.yml`, and `deploy-compose.langfuse-fanout.yml`, plus `rag.yml` and a `redis-config/` directory, so the first decision a self-hoster faces is which of them to use. The package.json scripts settle part of it, with start:deployed and stop:deployed both pointing at deploy-compose.yml rather than docker-compose.yml. The rule against editing the file directly is sound, since an override keeps local changes out of the way of upgrades, but the extension mismatch means the file the comment points at is not the file that is there. ## HOST is localhost in the example env and 0.0.0.0 in the compose file The same variable carries opposite meanings in the two files a self-hoster touches first. `.env.example` sets `HOST=localhost` with `PORT=3080`, above a comment telling you to refer to the reference documentation for assistance configuring the environment. docker-compose.yml overrides the binding in the api service: ``` - HOST=0.0.0.0 - MONGO_URI=mongodb://mongodb:27017/LibreChat - MEILI_HOST=http://meilisearch:7700 - LIBRECHAT_TEMP_CREDENTIALS_PATH=/app/data/.env.temp ``` The port is published as `${PORT}:${PORT}`, the container runs as `user: "${UID}:${GID}"` with `restart: always`, and five volumes reach back into your working directory: `.env` onto `/app/.env`, plus images, uploads, logs, and skill, with a named volume for `/app/data` where the temporary credentials file is written. The consequence is that whether your instance listens only on the loopback interface or on every interface is decided by which file supplied the value, and a 0.0.0.0 binding with nothing in front of it puts the login surface on the network. ## The four HTTP timeout variables are documented as imprecise The `.env.example` file carries four commented-out Node HTTP server timeouts, and the comments above them say more than the values do: ``` # HTTP_KEEP_ALIVE_TIMEOUT_MS=70000 # HTTP_KEEP_ALIVE_TIMEOUT_BUFFER_MS=5000 # HTTP_HEADERS_TIMEOUT_MS=80000 # HTTP_REQUEST_TIMEOUT_MS=300000 ``` The notes say they are optional and that Node.js defaults apply when unset. They say that behind an ALB you should set the application keep-alive timeout above the ALB idle timeout. They say that Bun accepts the values but does not enforce them. Most usefully they say that header and request timeout expiry is only detected on a 30 second connection sweep, so values below 30000 take effect late and are not enforced at the precision configured, and that the header timeout is clamped to the request timeout when the latter is lower, while keep-alive is socket-driven and remains exact at any value. So one of the four behaves as its name suggests and three do not, and the file tells you that in advance rather than letting you find it under load. ## npm ci gets two attempts, a 1500 second timeout, and a 6GB default heap The Dockerfile treats the package registry as slow and unreliable, and encodes that in three build arguments: ``` ARG NODE_MAX_OLD_SPACE_SIZE=6144 ARG NPM_CI_TIMEOUT_SECONDS=1500 ARG NPM_CI_ATTEMPTS=2 ``` The install step wraps the install in a loop of `until timeout "$NPM_CI_TIMEOUT_SECONDS" npm ci --no-audit`, captures the exit status, and exits with it once the attempt counter reaches NPM_CI_ATTEMPTS, and the npm fetch retry settings are raised to match, with fetch-retry-maxtimeout at 600000 and fetch-retries at 5. The image also preloads jemalloc through `ENV LD_PRELOAD=/usr/lib/libjemalloc.so.2`, installs python3, py3-pip and uv, and copies uv in from a pinned astral-sh image for what the comment calls extended MCP support. The consequence for anyone whose build fails is that the tuning surface is these three arguments rather than the source, and that the defaults are aimed at a slow link rather than at a broken lockfile. ## The Dockerfile copies five workspace manifests by hand package.json declares three workspaces, `api`, `client`, and `packages/*`, and the Dockerfile copies the root manifest and lockfile plus five individual package.json files before the install runs: ``` COPY --chown=node:node package.json package-lock.json ./ COPY --chown=node:node api/package.json ./api/package.json COPY --chown=node:node client/package.json ./client/package.json COPY --chown=node:node packages/data-provider/package.json ./packages/data-provider/package.json COPY --chown=node:node packages/data-schemas/package.json ./packages/data-schemas/package.json COPY --chown=node:node packages/api/package.json ./packages/api/package.json ``` The purpose is layer caching, since the manifests are copied before the sources so the install layer survives a change to application code. The cost is that the enumerated list and the `packages/*` glob have to be kept in agreement by hand. A new package under packages/ has no manifest present at install time unless the Dockerfile is edited, so adding a workspace is a build file change and not only a directory, and the failure appears at install time rather than in review. The repository also ships a second build path in Dockerfile.multi, alongside helm/, otel/, e2e/, turbo.json, and its own agent configuration in `.claude/`, `.codex`, AGENTS.md, and CONTEXT.md. ## Two agent surfaces are marked highly experimental in the same release candidate The v0.8.8-rc4 notes are where the churn sits, and two items are labelled rather than presented as settled. Attached workspaces are marked highly experimental and are described as isolating workspaces by conversation, loading repository instructions, and using bounded queue waits and command timeouts; the features list repeats the label, saying agents can inspect, search, edit, and run commands in managed or personal workspaces. Agent Plugins are experimental and bundle deployment Skills and MCP servers into startup-loaded packages. Both widen what runs on your machine, one by executing commands and one by loading code at start. Set beside them are Skills as reusable `SKILL.md` instruction bundles, Subagents as isolated child runs with their own context windows, a Trace Viewer showing ordered steps with roles, agent identity, tool rounds, previews and cost, and a public Agents API served as an OpenAPI specification with a Swagger UI. The reliability work in the same notes, per-request headers, OAuth refresh coordinated across replicas, and credentials preserved through provider outages, is the clearest sign that multi-replica deployment is a supported target. ## Conclusion LibreChat is a reasonable base for a team that wants a self-hosted chat interface with several model providers, agents, MCP tools, and per-user accounts under the MIT License, and the repository hands you a compose file, an env template, and install scripts rather than leaving you to assemble a deployment. Two things to settle before you rely on it. Decide how you will pin versions, because the compose file pulls librechat-dev:latest and the three newest releases are all candidates for the same 0.8.8, so an upgrade is whatever that tag points to on the day you pull. And read the timeout comments before putting a load balancer in front, because the project itself says the header and request values are only noticed on a thirty second sweep and are not enforced at the precision the names suggest. Anything labelled highly experimental, attached workspaces and agent plugins, deserves its own look rather than a line in an upgrade note. ## FAQ ### What is LibreChat? It is a self-hostable chat interface in TypeScript under the MIT License, described as an enhanced ChatGPT clone, with a user interface inspired by ChatGPT, model selection across Anthropic, AWS Bedrock, OpenAI, Azure OpenAI, Google, Vertex AI, and the OpenAI Responses API, plus agents, MCP support, skills, code artifacts, image generation, and web search. ### Is LibreChat the same as ChatGPT? It is described as an enhanced ChatGPT clone with an interface inspired by ChatGPT, but it is not a hosted service. It is a self-hosted application that connects to whichever providers you configure, and its feature list also names local and remote providers including Ollama, AMD Lemonade, groq, Cohere, Mistral AI, Apple MLX, koboldcpp, together.ai, OpenRouter, Helicone, Perplexity, ShuttleAI, Deepseek, and Qwen. ### Is LibreChat free? The repository is MIT licensed and the project describes itself as open source for self-hosting, with the compose file, the Dockerfile, and an .env.example in the repository. The env example points to the reference documentation for assistance with configuring the environment, and package.json ships scripts for creating, inviting, listing, banning, and deleting users. ### How do I install LibreChat? The repository ships a docker-compose.yml whose api service runs registry.librechat.ai/librechat-ai/librechat-dev:latest and depends on mongodb and rag_api, with an .env.example supplying HOST, PORT, and MONGO_URI. The compose file states you should not edit it directly and should use a docker-compose.override file instead, referring to a bundled example for sample configurations. ### How do I use MCP with LibreChat? Model Context Protocol support is listed for tools under agents and tools integration, agents can use MCP servers, tools, file search, and code execution, and Agent Plugins can bundle deployment Skills and MCP servers into startup-loaded packages, which is marked experimental. The v0.8.8-rc4 notes also cover per-request headers without hiding tools, OAuth refresh coordinated across replicas, and preserving credentials through provider outages. ## Sources - [Official documentation](https://librechat.ai/) - [Official README](https://github.com/danny-avila/LibreChat#readme) - [Project repository](https://github.com/danny-avila/LibreChat) - [Release notes](https://github.com/danny-avila/LibreChat/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/danny-avila-librechat