LibreChat deployment
Overview
This is the chat front end of my HomeAgents platform. It is LibreChat in Docker Compose, plus the configuration that makes it useful.
The main idea is simple. LibreChat knows one endpoint, my gateway, and one key. It never sees a real provider key. Tools are not on by default. They come with two profiles, Dev and Personal, and each profile can escalate to a stronger model when a task needs it.
I also cared about what happens when something is wrong. A missing secret stops the stack with a clear message, and the README explains which keys you must never lose.
Problem
I wanted a chat front end for my AI platform that works like a real assistant and not like a generic chatbot. It had to use my own model gateway, reach my own tools and keep provider keys out of the chat container.
Approach
- I deployed LibreChat with Docker Compose and wrote the configuration that turns it into a useful assistant.
- I used one YAML file to declare a single model endpoint, which is my LiteLLM gateway.
- I attached tools only through profiles, so a plain chat has no tools at all.
- I made two profiles, Dev and Personal. Each has a default version and an escalated version that switches to a premium model when I ask for it.
- I marked every secret as required, so a missing one stops the stack with a clear error.
Architecture and design decisions
- LibreChat talks to the gateway at litellm:4000/v1. It authenticates with one master key and never holds a provider key.
- The profiles attach MCP servers for memory through my qdrant-mcp server, finance through Firefly III, and Google Drive and Calendar over OAuth.
- The cheap everyday model and the expensive escalation path share one endpoint, so nothing is duplicated.
- LibreChat blocks requests to private addresses by default. I added an allow list in the settings with only the internal tool hosts it needs.
- MongoDB runs on a private internal network and is never published. LibreChat joins that network and the shared ai-platform-net network.
- Uploads, generated images and the Mongo volume are bind mounted from the data folder of the core repository.
Reliability and performance
- The required secret form makes the stack fail fast on a misconfiguration and not boot into a broken chat.
- The README warns about two things. Losing the credential encryption keys makes stored credentials useless. Losing the JWT secrets logs everyone out.
- The README also says the image tag and the YAML version must be updated together.
- The database is not reachable from outside its private network.
- The exception to the private address rule is limited to named internal tool hosts.
Outcomes
- I have a chat front end that uses one gateway and holds no provider keys.
- My assistants can use memory, finance and Google tools, but only in the profiles that need them.
- I can switch to a premium model for one chat without a second setup.
- Configuration mistakes show up as readable errors at start.
- My chat data sits in the same data folder as the rest of the platform, which keeps backups simple.
Known gaps
- Most of the application is upstream LibreChat. My part is the deployment and the configuration.
- I have no numbers for speed, memory use or how many chats it handles.
- I do not describe how I set up the Google OAuth app, and I do not claim it is suitable for several users.
- I have not shown a tested restore of the chat data.
- I do not say which licence my configuration uses.