ChatChat (okisdev/ChatChat): A Self-Hosted Multi-Provider AI Chat Front End

What ChatChat solves, and for whom

Most people who use more than one AI provider end up with a browser tab per vendor. ChatChat's stated goal is to collapse that into one interface: the README calls it "your own unified chat and search to AI platform, with a simple and easy to use interface." The repository is a Next.js 14 application written in TypeScript, styled with Tailwind CSS and shadcn UI components, with internationalization handled by next-intl and locale files under locales/. The README is available in English, Traditional Chinese, Simplified Chinese and Japanese, so the target user is not only an English-speaking developer.

The intended audience is someone who already holds API keys and wants a self-hosted front end rather than a hosted subscription. That is why the README lists "Ease self-hosted" as a feature alongside provider support. If you are a single user with one OpenAI key, the value is thin; if you juggle Anthropic, Google and OpenAI keys across projects, one interface with one conversation history is the point.

How ChatChat routes a message to a provider

The dependency list shows the architecture. ChatChat does not implement provider protocols itself; it depends on the Vercel AI SDK ("ai": "^3.1.17") plus provider-specific packages: @ai-sdk/anthropic, @ai-sdk/google and @ai-sdk/openai. Alongside those sit first-party SDKs such as @anthropic-ai/sdk, openai, cohere-ai, groq-sdk, @mistralai/mistralai, @huggingface/inference, @google/generative-ai and @aws-sdk/client-bedrock-runtime. The application layer is the app/ directory, with shared logic in lib/, hooks/, utils/ and config/, and a middleware.ts at the root.

The data flow is conventional for a Next.js app of this shape. The browser renders the chat UI; requests hit Next.js route handlers; those handlers read the API key from the server environment and call the selected provider. Keys are therefore server-side values, which is why the env file separates them from the NEXT_PUBLIC_ACCESS_* variables. Those public variables are switches, not secrets: they control which providers the UI offers, while the corresponding secret key stays on the server. Search is a parallel path with its own credentials for Google, Tavily and You, so a search-enabled answer combines a search API call with a model call.

Installing ChatChat and sending a first message

The README points to docs.okis.dev/docs/chat for usage and deployment, and offers two one-click buttons, one for Vercel and one for Railway. The repository also ships a Dockerfile and a docker-compose.yml, which is the route to take if you want the app on your own hardware. The Dockerfile builds with pnpm: it installs pnpm@latest, runs pnpm install, then pnpm build, and the production stage runs pnpm start on port 3000.

Start by copying the environment template. The .env.example file groups variables by provider, and the pattern is consistent: a NEXT_PUBLIC_ACCESS_* flag plus the matching key.

cp .env.example .env

Then fill in only the providers you intend to use. The OpenAI block in .env.example looks like this:

NEXT_PUBLIC_ACCESS_OPENAI=
OPENAI_API_KEY=
OPENAI_API_ENDPOINT=

An Anthropic setup follows the same shape, with NEXT_PUBLIC_ACCESS_ANTHROPIC and ANTHROPIC_API_KEY. For local development, the package.json scripts are the standard Next.js set:

pnpm dev

The dev server prints a local URL, typically http://localhost:3000, and the chat interface should load with the providers you enabled. For a container deployment, docker-compose.yml exposes port 3000 and passes the same variables as environment entries, all of them blank by default, so you must supply values yourself. Note that the compose file lists AWS_ACCESS_KEY, AWS_SECRET_KEY and AWS_REGION as well as Azure variables, but the env file marks Amazon and Azure as "not supported so far". Treat those entries as placeholders rather than working integrations.

Where ChatChat's provider story is thinner than it looks

The README's feature list says ChatChat supports "major AI Providers (Anthropic, OpenAI, Cohere, Google Gemini, etc.)", and the dependency list backs that up with SDKs for Mistral, Groq, Hugging Face and Bedrock. The env file tells a more cautious story. Amazon carries the comment "not supported so far" and Azure carries the same note, even though both are wired into docker-compose.yml and the Dockerfile's ENV block. A reader who sees AWS_REGION in the compose file could reasonably assume Bedrock works; the env file says otherwise.

The practical consequence is that provider support is a moving target you should verify per provider, not assume from the topic tags. The GitHub topics include azure, but the env file contradicts that. There is also no documented rollback path if an upgrade breaks a provider integration: the README does not describe version pinning or a migration procedure. The Dockerfile installs pnpm@latest at build time, which means two builds of the same commit can resolve different pnpm versions, and the production image copies node_modules from the build stage rather than reinstalling, so the image is only as reproducible as the lockfile allows.

ChatChat compared with a hosted chat client

The obvious alternative is a hosted client such as the vendor's own ChatGPT or Claude interface, or a desktop client that stores keys locally. The difference is where the key lives and who operates the server. With a hosted client, the vendor holds the account and you accept its model lineup; with ChatChat, you run the Next.js app, supply every key, and the model list is whatever you enabled. That is the trade: you gain provider mixing and control over the deployment, and you take on hosting, upgrades and key management.

A second alternative is a provider-agnostic SDK used directly in your own application, for example the same Vercel AI SDK that ChatChat depends on. That path gives you no UI at all. ChatChat is the middle option: more control than a hosted client, less work than building a chat interface on the SDK yourself. It is the wrong tool if your requirement is a supported product with an SLA, since this is a self-hosted project under AGPL-3.0 with no such guarantee in the README.

Maintenance, releases and the AGPL-3.0 licence

The last push to the default branch was on 2026-09-11, three days before this writing, so the repository is not dormant. The release history is sparser than the commit activity: the most recent tagged release is 0.1.9 from 2024-07-03, with 0.1.8 and 0.1.7 tagged the same day. package.json still carries "version": "0.1.9". If you track tags rather than the main branch, you are effectively tracking a codebase from mid-2024, and the gap between tag and branch is the upgrade cost you should budget for. Renovate is configured in the repository (renovate.json), which suggests dependency updates are automated, but that is a configuration file, not a statement about release cadence.

The licence is AGPL-3.0, and the README links to LICENSE. The AGPL's network clause matters for a web application: if you modify ChatChat and let users interact with it over a network, the licence's terms about offering source to those users are the part to read. This is not legal advice, and the details depend on whether you distribute modifications or only run an unmodified copy internally. If your organization restricts AGPL dependencies, check that policy before deploying.

Editorial conclusion

Adopt ChatChat if you want a single self-hosted interface across several model providers and you are comfortable running a Next.js app with your own API keys. Do not adopt it if you need a supported enterprise deployment, a stable plugin API, or a provider matrix that matches the README exactly. Before committing, check the docs at docs.okis.dev/docs/chat for the current install steps, and confirm which NEXT_PUBLIC_ACCESS_* providers you actually need to expose.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. okisdev/ChatChat on GitHub
3. Project website
4. README
5. Releases