Neo Chat: a self-hostable AI workspace where the browser holds the data

The problem Neo Chat solves, and for whom

Most hosted chat interfaces treat your conversation history as their data. Neo Chat takes the opposite position: the README states that conversations and workspace files stay in browser storage by default, and that encrypted sync through WebDAV or S3/MinIO is optional rather than required. That single decision defines the audience. This is a tool for an engineer or a small team who already pays for model access, wants to attach their own files, and would rather not hand a provider a permanent transcript of their work.

The feature list is broad on purpose. The README groups it as multi-model chat, an Agent mode for multi-step tool workflows, and Deep Research with reviewable plans, cited reports and manual resume. Around that sit file attachments, knowledge-base retrieval, local search, memory, reusable assistant presets, voice, editable artifacts, Markdown, math, diagrams and interactive charts. Text Skills, OpenAPI plugins and remote MCP servers are the extension surface, with an optional Docker bridge for local MCP tools.

That breadth is the honest framing of the trade-off. Neo Chat is not a thin wrapper around one API. It is a workspace, and a workspace asks you to make decisions about storage, keys, rate limiting and deployment topology before it behaves well in production.

How the pieces fit: Next.js, browser storage, and foreground runs

The repository is a Next.js application written in TypeScript, with Zustand for client state and React for the interface. package.json lists @anthropic-ai/sdk, @google/genai and @modelcontextprotocol/sdk among the dependencies, which matches the README's claim of Google, OpenAI, Anthropic and OpenAI-compatible endpoints. Model calls are proxied through the app's own API routes: the README notes that requests send the necessary content to the model providers and services you use, usually through those routes.

The data flow follows from that. Your browser holds the conversation and workspace files. When you send a message, the app forwards what is needed to the provider you configured. Anything that needs to persist beyond the browser goes through one of two optional paths: a ZIP backup and restore, or end-to-end encrypted sync over WebDAV or S3/MinIO. The README is explicit that backups exclude credentials and external service data, and that Research extensions such as custom templates, steering and report Q&A are browser-local and excluded from both ZIP backups and encrypted sync. If you rely on those Research features, treat them as disposable.

Server-side state is deliberately pluggable. The docker-compose.yml file defaults RATE_LIMIT_STORE, DOCUMENT_PARSE_JOB_STORE and PLUGIN_REGISTRY_STORE to memory, with Upstash as the alternative. The .env.example comments explain the consequence: hosted rate limiting falls back to process memory when Upstash is unavailable, while document jobs, plugin registration, sharing and multi-instance deployments still require Upstash for consistent or durable behavior. Deep Research's specialized arXiv, PubMed, EPO OPS and SEC EDGAR adapters also use that same Upstash pair for cross-instance rate coordination. In-memory stores are fine on one process and quietly wrong on two.

Installing Neo Chat and sending a first message

The README requires Node.js 24 and pnpm 10.30.3 via Corepack for a local checkout. Clone the repository, install with the frozen lockfile, and start the dev server:

git clone https://github.com/u14app/neo-chat.git
cd neo-chat
corepack pnpm install --frozen-lockfile
corepack pnpm dev

The README says to open localhost:3000, add a model provider and API key in Settings, then start a conversation. That is the whole first-run path. Most options live in the app; deployment-wide defaults come from copying .env.example to .env.local and following the environment variable reference in docs/environment-variables.md.

If you would rather not check out the source, the README gives an official image. This example binds to loopback and sets an access password:

docker run --rm -p 127.0.0.1:3000:3000 \
  -e ACCESS_PASSWORD='replace-with-a-strong-password' \
  -e BYOK_ALLOW_EPHEMERAL_KEY=true \
  ghcr.io/u14app/neo-chat:latest

You should then see the app at localhost:3000 asking for that access password. The README warns that this local example uses ephemeral credential-encryption keys, and that you should configure stable BYOK keys before production use to avoid key rollover across restarts and replicas. For a Compose setup with the environment variables laid out already, docker-compose.yml defines a neo-chat service on port 3000 plus an mcp-bridge service behind the mcp profile, and its healthcheck polls /api/health expecting a 200 or 401.

Cloudflare Workers is a third target: the README says to run `corepack pnpm build:worker` and then `corepack pnpm deploy:worker`, and notes that the deploy script preserves dashboard variables with --keep-vars.

Where Neo Chat stops being the right tool

The foreground execution model is the sharpest limitation. The README states that Agent and Research runs are orchestrated in the foreground, that closing the page interrupts execution, and that saved runs require explicit resume. A long research job is therefore tied to an open tab. If your workflow assumes a server-side queue that survives a closed laptop, this design will frustrate you, and the README does not document automatic resumption.

The access model is the second boundary. The README says plainly that the deployment password is an access gate, not a multi-user account system. There is no per-user isolation described. A team that wants separate accounts, roles or audit trails per person is looking at the wrong project.

The third is the local-first claim itself. The README pre-empts the common misreading: local-first storage does not mean inference runs offline. Your prompts and file content still travel to whichever providers and services you configure. If your requirement is that no data leaves the machine, Neo Chat's storage default does not satisfy it.

Finally, the ephemeral key fallback. A single hosted process without BYOK_PRIVATE_KEY_PEM falls back to a temporary process key, which the README ties to key rollover across restarts and replicas. That is a working default for a laptop and a data-loss-shaped default for anything else.

Neo Chat compared with Open WebUI

Open WebUI is the obvious comparison point for anyone shopping for a self-hosted chat front end, and the difference is where state lives. Open WebUI is built around a server-side backend with a database, so conversations belong to the deployment and follow the user across devices and browsers by construction. Neo Chat inverts that: the README says conversations and workspace files stay in browser storage by default, with WebDAV or S3/MinIO sync as an opt-in layer that is end-to-end encrypted.

The practical consequences run in both directions. Neo Chat's default means a browser profile wipe can take your history with it unless you have a ZIP backup or sync configured, and it means a shared deployment does not automatically pool everyone's chats. In exchange, the server holds less. If you want a single workspace that any device can join by logging in, a server-side database is the simpler architecture and Neo Chat's sync layer is extra machinery you would be adding on purpose.

The extension models also differ in emphasis. Neo Chat's README lists Text Skills, OpenAPI plugins, remote MCP servers and an optional Docker bridge for local MCP tools, and the repository ships docs/plugin-development.md and docs/mcp-stdio-bridge.md. Whether that surface is richer or thinner than Open WebUI's is not something the repository settles, and it is worth checking against your own list of tools before choosing.

Licence, maintenance and the cost of upgrading

Neo Chat is MIT licensed, and package.json marks the package private with "license": "MIT". MIT is permissive: you can run it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with substantial portions. That is a statement about the licence text, not legal advice, and the usual caveat applies to bundled third-party dependencies, which carry their own terms. The repository ships a SECURITY.md and a CODE_OF_CONDUCT.md, so vulnerability reports have a stated channel.

Maintenance is visible. The last push to main was on 2026-09-13, and the release list shows v2.5.0 on 2026-09-11, v2.4.0 on 2026-08-01 and v2.3.0 on 2026-07-19, with package.json at version 2.5.2. The repository is not archived. That is a recent cadence, and the project also publishes a CHANGELOG.md and a ROADMAP.md, which is where upgrade notes belong.

Upgrade cost concentrates in two places. Environment variables are the first: the .env.example in this repository documents defaults for DEPLOYMENT_MODE, ALLOW_INSECURE_LOCAL_PRODUCTION, TRUST_PROXY_HEADERS, the three store variables and the BYOK pair, and those are the settings most likely to shift between releases. The Docker image is the second: the Dockerfile builds a Next.js standalone output and runs it as a non-root nextjs user on port 3000, so pinning a tag rather than tracking latest is the low-effort way to keep a rollout predictable. The Dockerfile also accepts a NEXT_DEPLOYMENT_ID build argument, and .env.example notes that replicas in one rollout should share the same value.

Editorial conclusion

Adopt Neo Chat if you want a single-user or small-team workspace where conversations stay in browser storage, you bring your own provider keys, and you are comfortable running Node 24 or the official Docker image. Do not adopt it as a multi-tenant product: the README states the deployment password is an access gate, not a multi-user account system, and agent or research runs are orchestrated in the foreground, so closing the page interrupts execution. Before you commit, verify two things in your own deployment: that BYOK_PRIVATE_KEY_PEM and BYOK_KEY_ID are set to stable values rather than the ephemeral fallback, and that RATE_LIMIT_STORE, DOCUMENT_PARSE_JOB_STORE and PLUGIN_REGISTRY_STORE point at Upstash if you plan to run more than one instance.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. u14app/neo-chat on GitHub