# Keinsaas Navigator: a self-hosted AI workspace with MCP agents and visual workflows

> Navigator (the repository formerly called better-chatbot) is a Next.js and Vercel AI SDK application that bundles chat, MCP tool calling, custom agents and visual workflows into one deployable workspace. It is MIT licensed, and the interesting question is not whether it can chat, but whether its MCP and workflow layer holds up when you point it at your own tools.

**keinsaasforever/better-chatbot** — Formerly Better Chatbot. Navigator is an open-source AI workspace for agents, MCP and workflow automation.

- Repository: https://github.com/keinsaasforever/better-chatbot
- Website: https://app.keinsaas.com/
- Stars: 1,183 · Forks: 350
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/keinsaasforever-better-chatbot

## What Navigator actually solves for a team running MCP servers

Most chat interfaces treat the model as the product. Navigator treats the tool layer as the product. The README describes it as an open-source AI workspace for agents, MCP and workflow automation, and the feature list is organised around that: MCP protocol support, custom agents with their own system prompts and tool access, and visual workflows that can be published and then invoked from chat as @workflow_name tools.

The intended user is someone who already has MCP servers, or intends to write them, and wants a browser UI that can call those servers without building a front end. The README's Playwright example is the clearest illustration: a prompt tells the model to use @mcp("playwright") to open Google, click a button, type an email address, click Next and close the browser. The model decides the call sequence itself. That is a different product category from a chat app with a few built-in plugins, because the tool surface is whatever you connect.

It is not aimed at someone who wants an assistant that already knows things. There is no bundled knowledge base, no hosted index, no managed retrieval layer. You bring providers, keys, MCP servers and a PostgreSQL instance.

## The architecture: Next.js, Drizzle, Better Auth and a provider registry

The repository layout is a single Next.js application in src/, with drizzle.config.ts at the root and a docker/ directory holding a compose file. package.json confirms the runtime shape: next dev and next build for the app, drizzle-kit for schema work, vitest for unit tests and Playwright for end-to-end tests. Authentication is Better Auth, which is why .env.example asks for BETTER_AUTH_SECRET and an optional BETTER_AUTH_URL.

Model access is not hardcoded to one vendor. .env.example lists keys for Google, OpenAI, xAI, Anthropic, OpenRouter and Groq, plus OLLAMA_BASE_URL pointing at http://localhost:11434/api. There is an E2E_DEFAULT_MODEL variable whose documented format is provider/model, with openRouter/qwen3-8b:free given as the example. The repository also ships scripts named openai-compatiable:init and openai-compatiable:parse, which suggests a path for registering OpenAI-compatible endpoints beyond the named providers.

Persistence is PostgreSQL via POSTGRES_URL. Redis is optional and only matters for multi-instance deployments: the .env.example comment states that with REDIS_URL you get real-time MCP synchronisation and reduced polling, and without it synchronisation is polling-only, which it describes as fine for a single instance or development. That is an honest trade-off to have documented, and it is the first thing to think about if you plan to run more than one container behind a load balancer.

There is also FILE_BASED_MCP_CONFIG, defaulting to false, which switches where MCP server definitions live. The README does not explain the migration path between the two modes.

## Installing Navigator locally and getting a first agent to call a tool

The README offers two quick-start paths: a Docker Compose version and a local version. The package.json scripts wrap both, with docker-compose:up building from docker/compose.yml. For a local run, the sequence below follows the scripts and example environment file.

Start by creating your environment file. The repository's initial:env script is the intended way to produce it, and .env.example is the reference for what each variable means.

```bash
pnpm install
pnpm initial:env
```

Open .env.example alongside the generated file and fill in the values you need. At minimum you need BETTER_AUTH_SECRET and one provider key. PostgreSQL must be reachable at the URL you set.

```bash
BETTER_AUTH_SECRET=
OPENAI_API_KEY=****
POSTGRES_URL=postgres://your_username:your_password@localhost:5432/your_database_name
```

The .env.example notes that if you do not have PostgreSQL running locally you can start it with pnpm docker:pg. Push the schema, then start the dev server.

```bash
pnpm db:push
pnpm dev
```

Once the app is up, the workflow the README documents is: connect an MCP server, then reference it in a chat message. The README's sample prompt uses the @mcp("playwright") form, and the same section notes that the model decides how to use the server's tools and may call them repeatedly before returning a final message. Expect to see tool calls appear in the conversation rather than a single streamed answer.

If you prefer containers, the compose path is a single command, and the package.json also exposes docker-compose:logs, docker-compose:ps and docker-compose:update for day-to-day operation.

## Where Navigator gets awkward: config surface, polling and documentation gaps

The configuration surface is large. Between provider keys, OAuth settings, storage drivers, database URLs, Redis, Exa for web search and the MCP config mode, .env.example is a long file, and the truncated portions you can see hint at more. That is the cost of supporting six providers and optional infrastructure. It also means a misconfiguration often shows up as a failing tool call rather than a clear startup error.

The polling limitation is the one to take seriously. Without REDIS_URL, MCP synchronisation is polling-only. On a single instance that is acceptable. On several instances it means each process discovers tool changes on its own schedule, and the documentation does not state the polling interval. If you need deterministic tool availability across replicas, Redis is not really optional.

FILE_BASED_MCP_CONFIG is another rough edge. It defaults to false, and the README does not explain what changes when you set it to true, whether existing database-stored servers migrate, or whether the two can coexist. Teams that want MCP definitions in version control will care about this and will not find an answer in the README.

The repository also carries a roadmap section and a note that the project is evolving quickly. That is a maintenance signal, not a quality signal. The last push was on 2026-08-19, and the most recent tagged release listed is v1.26.0 from 2025-11-22. The gap between the last release tag and the last push means main is ahead of the newest release, so if you deploy from a tag you are not running what the repository's default branch contains.

## Navigator versus a plain chat UI or a desktop client

The obvious alternative is a desktop client such as a local-model chat app, or a hosted assistant like ChatGPT. The difference is architectural, not cosmetic. A desktop client owns the model and the storage on your machine; you get a working assistant immediately and you extend it through whatever plugin format that client defines. Navigator inverts this. It is a server application with a database, and its extension point is MCP, an open protocol with servers written by other people.

That inversion is the whole argument. If you want to call Microsoft's playwright-mcp from a chat window, a desktop client may or may not support MCP, and if it does, you are still limited to that client's UI. Navigator gives you the same protocol plus a way to publish a workflow as a callable tool, which is closer to building an internal tool catalogue than to choosing an assistant.

The cost is operational. You are running Next.js, PostgreSQL and possibly Redis. You are managing provider keys. You are responsible for upgrades. A team that just wants a chat window will find this heavier than it needs to be, and the README's own quick-start framing, deploy free with a Vercel button and free-tier database and storage, is aimed at people who accept that trade.

## Licence and the real upgrade cost

The repository is MIT licensed, and package.json carries the same identifier. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. This is not legal advice, and the licence text in LICENSE is the authority, but the practical implication is that wrapping Navigator into an internal product does not create a copyleft obligation.

Upgrade cost is where the trade-off sits. The project ships frequently, the README says so directly, and the changelog lives in CHANGELOG.md. Because the app owns its database schema through Drizzle, upgrades can involve schema changes. The package.json provides db:generate, db:migrate, db:push and db:reset, and db:reset runs drizzle-kit drop followed by drizzle-kit push, which destroys data. Treat that script as a development tool only.

The docker-compose:update script is the intended container upgrade path: it runs git pull and then brings the compose stack up again. It does not run migrations for you, so a schema change between versions is something you handle with db:migrate before the new container starts serving traffic. The README does not document a rollback procedure, so plan your database backups around that gap.

## Conclusion

Adopt Navigator if you already run MCP servers or want a chat UI that can call them, and you are comfortable operating a Next.js app with PostgreSQL and your own provider keys. Do not adopt it if you want a zero-setup desktop client or a single-vendor assistant, because the multi-provider configuration is yours to maintain. Verify first that your MCP servers work under the tool choice modes you need, and check the docker/compose.yml and .env.example against your own database and Redis setup before you commit to a deployment.

## FAQ

### Is there a better chatbot than ChatGPT?

Navigator does not position itself as a replacement for a specific assistant. The README describes it as an open-source AI workspace that integrates OpenAI, Anthropic, Google, xAI, Ollama and other providers, so the comparison depends on which provider keys you configure.

### What is actually the best AI chatbot?

The README makes no ranking claim. It lists multi-AI support, MCP tools, image generation, custom agents, visual workflows, collaboration and a realtime voice assistant as the features Navigator combines.

### What are the top 10 best AI chatbots?

The repository does not publish a ranking of chatbots. It names the assistants that inspired it, ChatGPT, Claude, Grok and Gemini, and states that it combines features from leading AI services into one platform.

### Is better chatbot or ChatGPT the better choice?

Navigator is self-hosted and MIT licensed, so you supply the provider keys, database and hosting, while ChatGPT is a hosted service. The README's quick-start path asks only for one AI provider API key, with database, file storage and hosting on free tiers.

### Is better chatbot or Gemini the better choice?

Navigator supports Google's Gemini as one of several providers through GOOGLE_GENERATIVE_AI_API_KEY in .env.example, so the two are not mutually exclusive. The README does not compare Navigator against Gemini as a product.

## Sources

- [keinsaasforever/better-chatbot on GitHub](https://github.com/keinsaasforever/better-chatbot)
- [License: MIT](https://github.com/keinsaasforever/better-chatbot/blob/main/LICENSE)
- [Project website](https://app.keinsaas.com/)
- [README](https://github.com/keinsaasforever/better-chatbot/blob/main/README.md)
- [Releases](https://github.com/keinsaasforever/better-chatbot/releases)

---

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