Chat Chat: a self-hosted multi-provider AI chat front end

What Chat Chat is for, and who it is actually aimed at

Chat Chat describes itself as "your own unified chat and search to AI platform, with a simple and easy to use interface." The problem it addresses is provider sprawl. If you use OpenAI for one task, Anthropic for another and Google Gemini for a third, you normally juggle three browser tabs, three billing relationships and three sets of API keys. Chat Chat puts them behind one Next.js interface you host yourself.

The repository topics list ai, api, azure, chat, claude, gpt, gpt-3, gpt-4, okisdev and openai, and the README's feature list names Anthropic, OpenAI, Cohere and Google Gemini with an "etc." The .env.example goes further and enumerates Amazon, Anthropic, Azure, Cohere, Fireworks, Google, Groq, Hugging Face, Mistral, OpenAI and Perplexity, plus Google, Tavily and You as search engines. That gap between the feature list and the environment file is worth noticing: the README advertises four providers, while the configuration surface suggests eleven.

The audience is therefore narrower than "anyone who chats with AI." It is for a developer or small team that already holds API keys, is willing to run a Node container, and wants the conversation history to stay on infrastructure it controls rather than in a vendor's account. The README's second feature bullet is "Ease self-hosted," which tells you self-hosting is the intended mode, not an afterthought.

How the provider and search routing is put together

The stack is listed as nextjs, tailwindcss and shadcn UI, and package.json confirms the shape: Next 14.2.3, React 18, jotai for state, next-intl for localisation, and the Vercel AI SDK (ai ^3.1.17) alongside per-provider SDKs. Both layers are present. There are @ai-sdk/anthropic, @ai-sdk/google and @ai-sdk/openai packages, and there are also @anthropic-ai/sdk, @google/generative-ai, openai, cohere-ai, groq-sdk, @mistralai/mistralai, @huggingface/inference, @aws-sdk/client-bedrock-runtime and @azure/openai.

That is a lot of overlapping dependencies for one application, and it is the clearest structural signal in the repository. A unified front end needs a common streaming interface, which is what the ai package provides, but the individual SDKs suggest providers are also reachable directly. The practical consequence for an operator is bundle and install weight: pnpm install pulls all of them whether or not you configure eleven providers.

Search is a separate axis. The .env.example splits into a Providers block and a Search Engines block, with Google (GOOGLE_SEARCH_API_KEY and GOOGLE_SEARCH_ENGINE_ID), Tavily (TAVILY_SEARCH_API_KEY) and You (YOU_SEARCH_API_KEY). Each provider and each search engine also has a NEXT_PUBLIC_ACCESS_ variable. Because those are prefixed NEXT_PUBLIC_, they are exposed to the browser, so the access flags are client-visible switches rather than server-side secrets. The actual API keys are not prefixed and stay server-side. If you deploy Chat Chat publicly, the set of enabled providers is discoverable by anyone who loads the page.

Installing Chat Chat with Docker and making a first request

The README offers Vercel and Railway buttons and says more deployment methods are in the docs at docs.okis.dev/docs/chat. For a local run, the repository ships a Dockerfile and a docker-compose.yml, so the compose file is the shortest path to something running.

The compose service is named chatchat, builds from the repository Dockerfile, and maps port 3000 to 3000. It declares environment variables for every provider, all empty by default. Fill in at least one provider key before starting, otherwise the interface will have nothing to talk to.

services:
  chatchat:
    image: chatchat
    build:
      context: .
      dockerfile: ./Dockerfile
    environment:
      - OPENAI_API_KEY=
      - ANTHROPIC_API_KEY=
    restart: always
    ports:
      - 3000:3000

The Dockerfile is a two-stage build on node:lts-alpine. The base stage copies package.json and pnpm-lock.yaml, installs pnpm globally, runs pnpm install, copies the rest of the source and runs pnpm build. The production stage copies .next, public, node_modules and next.config.mjs across, exposes 3000 and starts with pnpm start. If you prefer to run it without Docker, package.json defines the same three steps.

pnpm install
pnpm dev

pnpm dev runs next dev, which is the development server. For a production run, use pnpm build followed by pnpm start. After the container is up, the interface is on http://localhost:3000. The repository does not document a default login, so treat the running instance as unauthenticated unless you put something in front of it.

Where Chat Chat gets thin: configuration, releases and upgrades

The README's Usage and Deployment sections are both a single link to external documentation. That means the repository itself does not explain how to choose a model, how conversations are stored, or what happens when a provider key is missing. You can infer the provider list from .env.example, but inference is not documentation.

Two entries in .env.example are explicitly marked "not supported so far": Amazon and Azure. Both have full blocks of variables and both appear in docker-compose.yml and the Dockerfile. So the configuration surface advertises capability the project itself says is not there. That is a real trap for anyone who fills in AWS_ACCESS_KEY and expects Bedrock to work.

The release history is also worth stating plainly. The most recent release listed is 0.1.9 on 2024-07-03, and the version field in package.json is 0.1.9. The last push to the repository was on 2026-09-11. So the code has moved since the last tagged release, but there is no tagged release covering those changes. If you pin to a release, you are pinning to something from 2024-07-03. If you track main, you are running untagged code. Neither the README nor the release list documents a migration path between versions, and the README does not document rollback.

Chat Chat compared with a desktop client like Chatbox

The obvious alternative for someone who wants one window for several providers is a local desktop client rather than a self-hosted web app. Chatbox is the common example: it runs on your machine, stores conversations locally, and talks to provider APIs directly. The difference in approach matters more than the feature lists.

A desktop client puts the trust boundary at your laptop. Nothing is exposed on a network, there is no server to patch, and no NEXT_PUBLIC_ variable can leak your provider list to a visitor. Chat Chat puts the boundary at a server you operate. That buys you shared access: several people can use one deployment with one set of keys, from any browser, without installing anything. It also means you now own uptime, TLS, and access control, none of which the README describes.

A second difference is search. Chat Chat's .env.example wires Google, Tavily and You as search backends, so the app can pull web results into a conversation. A desktop client typically leaves that to the provider's own tooling. If your goal is a shared internal interface with web search attached, Chat Chat's architecture is the closer fit. If your goal is one person chatting privately, the server is pure overhead.

Licence and the cost of staying current

Chat Chat is licensed AGPL-3.0, with the licence file at LICENSE.txt and the README pointing to ./LICENSE. AGPL-3.0 is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the licence's source-availability obligation applies to those users. Running an unmodified copy for yourself is a different situation from forking it and offering it as a service. This is a description of the licence family, not legal advice; if you plan to modify and host it publicly, read the actual terms or ask someone qualified.

The upgrade cost is harder to estimate because the repository does not document one. There is no changelog in the repository listing, no migration guide referenced in the README, and the release list stops at 0.1.9 from 2024-07-03 while commits continued to 2026-09-11. Renovate is configured (renovate.json is a top-level entry), which suggests dependency updates are automated on the maintainer's side. For you that cuts both ways: dependencies stay current, but a Next.js major bump or an AI SDK change can land on main without a tagged release to pin against. Budget for reading diffs, not for following a version number.

Editorial conclusion

Adopt Chat Chat if you want a single self-hosted interface for several providers and you are comfortable reading .env.example and docker-compose.yml to work out configuration, since the README points to external docs rather than explaining them. Do not adopt it if you need a documented upgrade path, a stable release cadence, or a provider matrix you can verify without reading package.json. Before deploying, check which NEXT_PUBLIC_ACCESS_ variables your chosen providers need, confirm whether the search engines you intend to use are wired up, and read the AGPL-3.0 terms against how you plan to expose the app.

Frequently asked questions

Official sources

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