swuecho/chat: a self-hosted multi-model chat app for teams

The problem swuecho/chat solves for small teams

Most teams end up with the same mess. One person holds the OpenAI key, another has a Claude key, someone else runs Ollama on a workstation, and there is no shared history, no quota, and no way to hand a conversation to a colleague. swuecho/chat is aimed at that situation. The repository describes it as a chat web app for teams, with user management and rate limiting, and the model list covers OpenAI and Azure, Claude, Gemini and Ollama. The first registered user becomes administrator, which tells you the deployment model: you stand it up, you register, you are in charge. The built-in gateway is the part that matters most for a team. According to the README it exposes an OpenAI-compatible endpoint that clients can call with revocable virtual API keys, so people can point their own tools at your instance instead of holding the real provider key. That is a different proposition from a single-user chat UI. It is infrastructure with a chat interface on top.

How swuecho/chat routes a message and what the gateway adds

The README states the first message in a conversation is treated as the system message, and that by default the latest four messages are attached as context. That is a small window, and it is a deliberate trade-off: less context per call means lower token cost and predictable latency, but long threads will lose earlier detail unless the setting is changed. The gateway side is more interesting. The README lists transparent streaming pass-through, per-key limits, request auditing, and request and response samples retained for a limited time. So the flow is: a client calls the gateway with a virtual key, the request is checked against the key's limit, streamed through to the configured provider, and a sample is kept for a while for review. Virtual keys are described as revocable, which is the practical answer to key rotation inside a company. One gap worth naming: the README does not document how samples are stored or how long the retention window is, so treat that as something to confirm in the gateway documentation before you put sensitive prompts through it.

Installing swuecho/chat with docker-compose

The repository ships a docker-compose.yaml that starts two services, chat and db, with Postgres 14. The chat image is ghcr.io/swuecho/chat:latest, and the file comments suggest using a tag instead for stability. At least one provider key is required. The comments warn not to put quotes around the key values.

services:
  chat:
    image: ghcr.io/swuecho/chat:latest
    ports:
      - 8080:8080
    environment:
      - OPENAI_API_KEY=thisisopenaikey
      - CLAUDE_API_KEY=thisisclaudekey
      - OPENAI_RATELIMIT=100
      - PG_HOST=db
      - PG_DB=postgres
      - PG_USER=postgres
      - PG_PASS=thisisapassword
      - PG_PORT=5432
    depends_on:
      db:
        condition: service_healthy

Bring it up with the standard compose command:

docker compose up -d

The compose file maps port 8080 to the host, and its comment says to visit http://your_host:8080. The db service has a pg_isready healthcheck, and chat waits for it to report healthy. The Dockerfile adds its own healthcheck against http://localhost:8080/api/health, so you can confirm the container is serving before you open the UI. The first account you register becomes the administrator. Replace the placeholder values for PG_PASS and the provider keys before exposing the instance to anyone, and note the README's warning about public networks: set OPENAI_RATELIMIT to zero there, and raise it per trusted user in the admin panel.

Where swuecho/chat gets in your way

The default rate limit is 100 ChatGPT calls per 10 minutes, controlled by OPENAI_RATELIMIT. That is a global setting, and the README's own advice for a public server is to set it to zero and then grant quota per user in the admin panel. If you skip that step, either everyone shares one bucket or nobody can call anything. The other constraint is search. Snapshot directories support full-text search, but the README qualifies it as English. Teams working in other languages should not expect the search box to behave the way it does for English transcripts. There is also a context ceiling of four messages by default, which will surprise anyone used to assistants that carry a long thread. Finally, the project is a server you operate. It needs Postgres, it needs outbound access to each provider, and the README does not document a backup or rollback procedure for the database. If you cannot run Postgres and a container, this is the wrong tool regardless of how well the feature list matches.

swuecho/chat compared with a plain chat UI

The obvious alternative is a single-user chat front end such as ChatGPT-Web, which the acknowledgements credit as the origin of the web client. The difference is what sits behind the interface. A plain chat UI holds one key and serves one person at a time; swuecho/chat adds accounts, an administrator role, per-key limits, auditing, and an OpenAI-compatible gateway that other tools can call. If your need is one developer talking to one model, the lighter project is less to run. If your need is twenty people sharing a budget and an audit trail, the lighter project has no answer. The other alternative is a commercial team plan from a model provider, which removes the database and the container entirely but also removes the choice of routing some traffic to a local Ollama host. swuecho/chat's value is that mix: hosted and local models in one place, under your own quotas.

Maintenance, licensing and what the README leaves open

The last push to the repository was on 2026-09-04, and the most recent release listed is v0.70.0 from 2026-05-30, following v0.60.1 in January 2026 and v0.50.3 in September 2025. The cadence is real but not fast, and the project is not archived. The licence is MIT, which is permissive and places few obligations on how you deploy or modify it; it also means no warranty, and any legal question about your own use of provider APIs is separate from this licence. Operationally, the upgrade path is the container image, and the compose file comments recommend pinning a tag rather than tracking latest. That is the sensible default here: the README does not describe database migrations between versions, so a tagged upgrade you can reverse is safer than a floating one. The mobile client is Flutter, and the repository carries a mobile directory, but the README points at a local file path for it rather than a published guide, so treat the mobile app as less documented than the web app.

Editorial conclusion

Adopt swuecho/chat if you already run Postgres, want one internal URL for several model providers, and need per-user quotas rather than a public chat product. Do not adopt it if you cannot operate a database or need a documented backup and rollback procedure, because the README does not describe one. Before rolling it out, verify that the model providers you intend to use are reachable from the container and that the OPENAI_RATELIMIT value matches your exposure, since the README warns to set it to zero on a public network and raise it per trusted user in the admin panel.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. swuecho/chat on GitHub