A chat client you can place almost anywhere
NextChat packages a familiar model-chat experience as a browser app, PWA, and desktop client. It speaks to OpenAI, Anthropic, Google, DeepSeek, Azure, several Chinese providers, and endpoints that follow the expected API shapes. Conversation rendering covers Markdown, LaTeX, Mermaid diagrams, and highlighted code. Prompt templates, shareable artifacts, image generation settings, plugins, and optional MCP support move it beyond a bare chat box.
The attraction is control without having to design another chat interface. A developer can connect a paid API, point BASE_URL at a compatible local or hosted model, and keep ordinary conversation data in browser storage. The interface is translated into many languages, and the repository supplies one-click hosted deployment buttons plus Docker and local-development instructions. For a personal model console or a small internal trial, that is a practical package.
Its limits become clearer when several people share the same deployment. The open-source access mechanism documented in the README is CODE, a comma-separated list of page passwords. That can keep a casual visitor out, but it is not individual identity, role assignment, or an audit trail. Those controls appear in the separately described enterprise edition. Treat the community version as a client application with a simple gate, not as a finished company chat service.
Provider choice comes with configuration work
The shortest setup needs one model API key. From there, the environment list gets long because each provider can bring a key, base URL, API version, deployment name, or model mapping. CUSTOM_MODELS can add, remove, and rename models, including Azure deployment aliases. This flexibility is useful when an organization has a proxy or a mixed model fleet, though it also creates more configuration to test after an update.
Privacy claims need the same careful reading. Chat history is local in the browser by default, which avoids placing every conversation in NextChat's own database. Requests still go to the model provider or custom endpoint selected by the operator. Optional Upstash synchronization moves records to another service. A privacy review therefore has to cover the chosen endpoint, browser access, synchronization settings, and any plugins, rather than stopping at the phrase "stored locally."
MCP is available, but it is a build-time choice. The README requires ENABLE_MCP=true before building or when launching the Docker image. That detail matters for teams expecting to toggle tools after deployment. MCP clients can expose actions beyond ordinary text generation, so enable only the servers users need and check their permission boundaries separately.
What happened when we ran it
We cloned commit defdcdb into a clean, unprivileged Node 22 container with three CPUs, 8 GB of RAM, and no secrets. The repository contained 425 files and about 43,498 lines of source, with a 7.8 MB checkout. Yarn installed 2,413 packages in 216 seconds, occupying 847 MB. The build then completed successfully in 118 seconds.
The test step did not finish within the 900-second limit. Its command launched Jest with --watch, printed the standalone Next build settings, and said no tests were found for files changed since the last commit. We stopped it at the limit. That result does not show a test failure, and it does not prove the suite passes. It shows that the invoked default test path is unsuitable for an unattended clean-checkout run. The repository does have a test directory and seven CI workflow files, so operators should identify and pin the non-watch CI command.
Security reports change the deployment advice
Two open issues filed against v2.16.1 describe risky proxy behavior. One reports an unauthenticated server-side request path through a caller-controlled x-base-url header. Another reports that a substring check could attach the server's OpenAI key to a hostile URL containing the expected domain text. These are reports, not findings from our sandbox run, but their subject directly affects any public deployment that stores provider secrets. Review the current proxy code and mitigations before exposing it.
Desktop users have a separate warning. A July 2026 Windows issue says uninstalling NextChat from D:\Program Files\NextChat began deleting sibling applications in D:\Program Files. The reporter stopped it after losing several programs. Until that report is resolved and the affected installer is identified, install into a dedicated directory and back up anything nearby before uninstalling.
The repository was pushed on August 11, 2026, while issue discussion continued later in August. That combination shows ongoing activity even though the latest tagged release, v2.16.1, dates to July 2025. GitHub listed 851 open issues and pull requests, a large mixed queue that includes support requests, feature proposals, and code contributions. A stale tag alone does not make the project abandoned, but it does mean release-only users may be far behind repository changes.
Who should choose it
NextChat works best when one technically capable owner controls deployment, provider keys, and upgrades. It offers more polish and provider breadth than a home-built chat screen, while remaining lighter than a full multi-user AI platform. Browser-local history is a genuine advantage for that use case.
A company needing named users, retention policy, central audit records, or dependable tool permissions should start with Open WebUI, LibreChat, or a commercial deployment built for those controls. NextChat can still serve as an individual client in that environment, but the shared-password community edition should not be mistaken for an identity layer. The current security reports also make a public, secret-bearing proxy deployment hard to recommend without a code-level review.