swuecho/chat: a self-hosted ChatGPT, Claude and Ollama front end for teams

What swuecho/chat solves, and for whom

Most chat front ends assume one person and one API key. swuecho/chat assumes a group. The README describes a web app with user management and rate limiting, and the deployment guide is written around a server you control. The first registered user becomes administrator, which means the intended flow is: you stand it up, you register, and you then create accounts for everyone else. That single line says a lot about the target audience. This is not a consumer app with sign-up flows and billing. It is an internal tool for a team that already has OpenAI, Claude or Ollama credentials and wants to put a shared interface in front of them.

The provider list is deliberately mixed. OpenAI and Claude are named in the README rules, the repository description adds Gemini and Ollama, and the documentation links a specific discussion thread for Ollama host configuration. A team that wants one place to compare a hosted model against a local one can do that here without running two applications. The rate limit default, 100 ChatGPT calls per 10 minutes via OPENAI_RATELIMIT, is the other signal: this is built for shared use where one person's runaway script should not drain the whole budget.

How conversations, context and snapshots actually work

The context rule is explicit and short. The first message is treated as a system message, and by default the latest 4 messages are attached as context. That is a small window. If you are used to tools that silently send a long transcript, this will feel different, and it is a real constraint for long technical discussions where a decision was made twenty messages ago. The trade-off is predictable token spend and a bounded request size, which matters when several people share one key.

Alongside ordinary chat, the project has a snapshot concept. The README describes generating shareable static pages from conversations, similar to ShareGPT, with the option to continue the conversation from that point. There is a separate document titled Snapshots vs ChatBots, which suggests the two modes are distinct enough to need explaining. Snapshots also support full-text search, and the README is specific that this search is for English. That qualifier is worth taking at face value: if your team writes in another language, the searchable snapshot directory is less useful than the feature list implies.

On the server side, the Dockerfile shows a two-stage build: a Node 22 Alpine stage runs npm ci and npm run build for the web front end, and a Go 1.24 Alpine stage compiles the API with CGO_ENABLED=0 and copies the built front end into ./static/. The runtime image is Alpine 3.20 with a non-root appuser, a healthcheck that wgets http://localhost:8080/api/health, and a zoneinfo.zip with ZONEINFO set, which is how timezone handling works in a scratch-like image without system tzdata.

Installing swuecho/chat with Docker Compose

The repository ships a docker-compose.yaml that runs the application and a Postgres 14 database together. The image is ghcr.io/swuecho/chat:latest, and the compose file itself notes that a tag such as v0.0.3 is better for stability than latest. The application listens on port 8080, and the comment in the file says to visit http://your_host:8080.

The environment block is where the real work is. At least one provider key is required, and the file warns not to put quotes around the key values:

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

Those PG_ values point at the bundled db service, which uses POSTGRES_USER postgres and POSTGRES_PASSWORD thisisapassword. The compose file also mentions DATABASE_URL as an alternative to the five PG_ variables. Start it with the usual command from the repository root:

docker compose up -d

After that, the healthcheck defined in the Dockerfile polls /api/health every 30 seconds, so you can confirm the container is up rather than guessing. The first account you register becomes the administrator. One warning from the compose comments deserves repeating: it advises setting OPENAI_RATELIMIT to zero if your server is on a public network, and raising it in the admin panel only for trusted users.

The OpenAI-compatible gateway and its audit trail

The feature that separates swuecho/chat from a plain chat UI is the built-in gateway. The README describes an OpenAI-compatible gateway called through virtual API keys, with streaming pass-through, rate limiting, request auditing, and request/response samples kept for a limited time. There is a dedicated document, OpenAI-Compatible Gateway, linked in English. This is the part that lets existing tools point at your instance instead of at a provider directly, with the instance acting as the accounting and access-control layer.

Two things are worth flagging. First, the README says the virtual keys are revocable, which is the property that makes per-person keys practical: you can cut off one client without rotating the key everyone else uses. Second, the time-limited retention of request and response samples is a data-handling decision, not just a debugging feature. The README does not state the retention period. If prompt content is sensitive, that gap is something to resolve from the gateway document before enabling the feature broadly, because the samples are stored by design.

Where swuecho/chat is the wrong tool

The four-message default context is the clearest limitation. For code review, long document analysis or multi-step debugging, a window that small forces you to re-state context manually. You can work around it, but the default tells you what the project optimises for: many short, cheap, parallel conversations rather than deep ones.

Snapshot full-text search being English-only is the second. A team that archives conversations in another language gets the snapshot pages but not the search that makes them worth archiving.

Third, the README does not document rollback, and the compose file pins nothing by default. Running latest means an upgrade can change behaviour under you, and the project's documentation gives no procedure for going back to a previous version beyond the comment suggesting you use a tag. If you need a documented upgrade and rollback path, swuecho/chat does not provide one that I can point to.

Finally, the project's own positioning is as a team app, not a platform. If you want per-user billing, SSO or an SLA, none of that appears in the README or the linked documents. The mobile app is a Flutter codebase under mobile/, referenced from the README, but the README link points at a local path rather than a repository document, so treat mobile as a separate thing to evaluate on its own.

Alternatives and the difference in approach

The README's acknowledgments name ChatGPT-Web (Chanzhaoyu/chatgpt-web) as the source of the web front end, and a node implementation from a pull request in that repository as the basis for the API. That lineage is useful when choosing between them. ChatGPT-Web is a chat interface first; swuecho/chat adds the server-side concerns on top: accounts, a shared rate limit, a Postgres-backed store and the gateway with virtual keys. If your problem is one person wanting a nicer ChatGPT page, the ancestor is the smaller dependency. If your problem is twenty people sharing keys and you need to know who spent what, the fork is the one with the mechanism for it.

Against hosted team chat products the difference is control and cost model. Here you supply the provider keys and the Postgres instance, and the rate limit is a number in an environment variable rather than a plan tier. The price is operational: you own backups, upgrades and the public-network exposure question the compose file raises.

Maintenance, licensing and what to check before you commit

The repository is not archived, and the last push was on 2026-09-04. Releases are less frequent than commits: v0.70.0 on 2026-05-30, v0.60.1 on 2026-01-09, v0.50.3 on 2025-09-16. That pattern suggests steady work between tagged releases rather than a project shipping continuously. Plan upgrades around tags, not around latest, which is what the compose comment already recommends.

The licence is MIT, stated in the README and present as a LICENSE file at the top level. MIT is permissive: you can run it internally, modify it and redistribute it, provided the copyright notice and permission notice are kept. That is a summary of the licence text, not legal advice; if you are embedding it in a product, read the file.

Before adopting, verify three things in the project's own documents. The Ollama host configuration, which the README points to a discussion thread for rather than a doc page. The gateway document, for the sample retention period and the exact virtual key semantics. And the deployment guide, for anything your environment needs that the compose file does not cover, such as a reverse proxy or TLS termination, which the compose file does not mention.

Editorial conclusion

Adopt swuecho/chat if you need a shared, self-hosted chat front end where one administrator hands out accounts and virtual API keys, and you are willing to run Postgres and set the provider environment variables yourself. Do not adopt it if you want a managed service, a documented public API contract beyond the gateway, or a project whose release cadence you can predict: the last push was on 2026-09-04, but releases are spaced months apart. Verify first that the Ollama host configuration in the linked discussion matches your setup, and that the gateway documentation covers the audit and sample-retention behaviour your organisation needs before you point production traffic at it.

Frequently asked questions

Official sources

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