# ChatGPTNextWeb/NextChat: the desktop app is on another repository

> A TypeScript, MIT-licensed cross-platform chat client for Claude, DeepSeek, GPT-4 and Gemini Pro, where conversations are kept in the browser. Two things surprise a reader: the desktop builds are published from a different repository, and the local knowledge base everyone asks for is the one roadmap item still unchecked.

**ChatGPTNextWeb/NextChat** — Light and Fast AI Assistant. Support: Web | iOS | MacOS | Android | Linux | Windows.

- Repository: https://github.com/ChatGPTNextWeb/NextChat
- Website: https://nextchat.club
- Stars: 88,829 · Forks: 58,960
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/chatgptnextweb-nextchat

## The desktop downloads come from a different repository

The badges and download links in the README do not point back at this repository. Desktop builds for Windows, macOS, and Linux are fetched from the releases page of Yidadaa/ChatGPT-Next-Web, a different project name from the ChatGPTNextWeb/NextChat repository this README belongs to. The web and SaaS links are separate again, pointing at app.nextchat.club and nextchat.club. Consequence for the reader: the name you clone and the name you download from are not the same, and the desktop client is versioned on a schedule you cannot read from this repository's tags. Before you file a bug about a desktop crash, check which of the two repositories the binary actually came from, because the code you cloned may not be the code that produced the installer. The same split shows up in the iOS story, where the App Store build is live but the source lives in a third repository that the README describes as coming soon, so across web, desktop, and mobile there are three different places a build comes from and only one of them is this repository.

## Ten environment variables decide what the client will do

The docker-compose file lists the full configuration surface, and the names do more work than the documentation admits. The chatgpt-next-web service passes OPENAI_API_KEY, GOOGLE_API_KEY, CODE, BASE_URL, OPENAI_ORG_ID, HIDE_USER_API_KEY, DISABLE_GPT4, ENABLE_BALANCE_QUERY, DISABLE_FAST_LINK, and OPENAI_SB.

```yaml
      - OPENAI_API_KEY=$OPENAI_API_KEY
      - GOOGLE_API_KEY=$GOOGLE_API_KEY
      - CODE=$CODE
      - BASE_URL=$BASE_URL
      - OPENAI_ORG_ID=$OPENAI_ORG_ID
      - HIDE_USER_API_KEY=$HIDE_USER_API_KEY
      - DISABLE_GPT4=$DISABLE_GPT4
      - ENABLE_BALANCE_QUERY=$ENABLE_BALANCE_QUERY
      - DISABLE_FAST_LINK=$DISABLE_FAST_LINK
      - OPENAI_SB=$OPENAI_SB
```

Consequence for the reader: several of these invert the privacy story the README advertises. Setting OPENAI_API_KEY on a server moves the key off the browser and onto a host you operate, and HIDE_USER_API_KEY exists to hide keys you would rather users type themselves. DISABLE_GPT4 and DISABLE_FAST_LINK remove options rather than add them, so a deployment that leaves them unset is not the same as one that sets them deliberately.

## The two compose services differ by a single variable

docker-compose.yml declares two services that look like duplicates and are not. The chatgpt-next-web service sits under the no-proxy profile, and the chatgpt-next-web-proxy service sits under the proxy profile. Both map port 3000 and both take the same API key variables, but the proxy service adds PROXY_URL and the no-proxy service does not. Consequence for the reader: the profiles are the switch that decides whether your outbound model calls go through a proxy, and because both services claim the same container port you can only run one at a time. A reader who copies the file and does not set a profile gets neither service started, which is a quiet failure rather than an error message.

## The container build points yarn at a regional mirror

The Dockerfile hardcodes a package registry before it installs anything.

```dockerfile
RUN yarn config set registry 'https://registry.npmmirror.com/'
RUN yarn install
```

That line rewrites the registry for every dependency in the image, on top of a base of node:18-alpine. Consequence for the reader: your build's dependency sources are chosen by the project rather than by you, and if that mirror is slow, unreachable, or untrusted from where you build, the failure appears during image construction with nothing in the Dockerfile to explain it. Anyone building this outside the region the mirror serves should expect to edit that line, and should know they are making that decision about every transitive package, not just the direct dependencies.

## MCP support is compiled in only if you set a flag first

The Model Context Protocol support is not on by default in a build you already have. A note in the README says that before building you should set the environment variable ENABLE_MCP, and the Dockerfile both declares an empty ENABLE_MCP and creates the MCP directory with wide permissions before copying a default config into place as mcp_config.json. The client also depends on the Model Context Protocol SDK in package.json.

```bash
ENABLE_MCP=true
```

Consequence for the reader: the ordering matters more than usual, because the flag is read at build time, so setting it on a running container does nothing and you rebuild to get it. The directory is created with permissions 777, which is convenient for a container that has to write a config at startup and is a detail worth knowing before you put anything sensitive in that path.

## A local knowledge base is the one roadmap item left open

The roadmap in the README is almost entirely checked boxes. System prompts, user-editable prompts, prompt templates, sharing as an image, the tauri desktop app, self-hosted models, artifacts, and plugins are all marked done. One item is not: local knowledge base, left as an empty checkbox. That gap lines up with what the Enterprise Edition section sells, where combining an internal knowledge base with AI capability is listed among the paid features alongside permission control and security auditing of conversation history. Consequence for the reader: the knowledge base you probably want is the one the open client does not have and the commercial edition advertises, and a self-hosted deployment of the client will not get you closer to it. Anyone evaluating this for retrieval over internal documents should price the enterprise tier before assuming the open build covers it.

## Prompt templates are compiled before the client starts

The prompt templates the README calls masks are a build artifact rather than something the running app reads. package.json defines a mask script that runs app/masks/build.ts through tsx, and the normal build runs the mask step before the Next.js build.

```json
    "mask": "npx tsx app/masks/build.ts",
    "build": "yarn mask && cross-env BUILD_MODE=standalone next build",
```

The dev script pairs a mask:watch task with next dev through concurrently, and the export build repeats the pattern with BUILD_MODE=export, as does the tauri desktop build. Consequence for the reader: a mask is compiled into the output rather than loaded at runtime, so editing one without running the mask step leaves you staring at the old text with no error to explain it. Localization is handled on a different footing entirely, shipping as runtime data in thirteen languages from English and Simplified Chinese through Korean, Czech, and Vietnamese, so translating the interface does not touch this build step even though editing a mask does.

## The iOS app is distributed while its source is still promised

Two more loose ends sit in the README. The iOS app is live on the App Store under the name NextChat AI, and the line beside it reads that the source code is coming soon, pointing at a separate NextChat-iOS repository. And the release history has drifted from the commit history: the last tagged releases are v2.16.1 from 2025-07-29, v2.16.0 from 2025-02-16, and v2.15.8 from 2024-11-11, while the repository's last push is dated 2026-08-11. Consequence for the reader: more than a year of commits sits after the newest tag, so a self-build is picking up work that no release has been cut from, and the mobile client is a binary you cannot audit from this repository. Neither fact makes the project unusable, but both mean the tag you install and the code you clone are different propositions.

## Conclusion

NextChat fits an individual who wants one lightweight client across web, desktop, and mobile pointed at several model providers, and who is content to hold their own API keys, since the whole point of the local-storage model is that the key and the history never leave the browser. It does not fit a team that needs shared permissions, an audit trail, or a private knowledge base today, because those are sold as an enterprise edition rather than shipped in the client, and the local knowledge base is still an open roadmap box. Before you adopt it, pick your deployment path deliberately, because the Docker and one-click routes hand your API key to a server you host rather than keeping it in the browser, and confirm the release you install, since the last tagged version is v2.16.1 from 2025-07-29 while commits have continued to 2026-08-11.

## FAQ

### What is NextChat?

NextChat is a light, fast AI assistant built in TypeScript under the MIT license, offering Claude, DeepSeek, GPT-4, and Gemini Pro support across web, iOS, macOS, Android, Linux, and Windows. It stores your data locally in the browser and supports Markdown with LaTeX, mermaid, and code highlighting.

### what is next chat

It is a cross-platform chat client for large language models that you can deploy yourself in about a minute on Vercel or run as a roughly 5MB desktop client. It supports prompt templates called masks, streaming responses, and automatic compression of chat history to save tokens on long conversations.

### What is netchat?

Nextchat usually means NextChat, the client described here, sometimes also written in all lowercase as nextchat. It has a SaaS option at nextchat.club and a web demo at app.nextchat.club, and it is compatible with self-hosted models such as RWKV-Runner and LocalAI.

### nextchat vs openwebui

The README does not make that comparison. What it does name is a set of self-hosted model backends it recommends, RWKV-Runner and LocalAI, and a client model where your own API key and conversation history can stay in the browser, with the enterprise features it does not ship being permissions, auditing, and a knowledge base.

## Sources

- [Official documentation](https://nextchat.club)
- [Official README](https://github.com/ChatGPTNextWeb/NextChat#readme)
- [Project repository](https://github.com/ChatGPTNextWeb/NextChat)
- [Release notes](https://github.com/ChatGPTNextWeb/NextChat/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chatgptnextweb-nextchat