Aniket Wathore publishes Bolnee-Chat, a self-hosted website RAG chatbot

Aniket Wathore has published Bolnee-Chat, an open-source retrieval-augmented chatbot for business websites, on GitHub. The self-hosted tool, which had 43 commits and one star as of August 30, lets operators crawl websites, upload files, and connect OpenAI-compatible model providers including OpenRouter, OpenAI, Groq, Ollama, and vLLM. Wathore, a solo developer based in Nanded, Maharashtra, India, positions the project as a narrow alternative to hosted chatbot vendors, offering deployment control and inspectable code.

Aniket Wathore publishes Bolnee-Chat, a self-hosted website RAG chatbot The solo developer built a narrow RAG tool for operators willing to manage their own chatbot and database across cloud APIs or local models. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: GitHub https://github.com/AniketWathore/bolnee-chat Why it matters Bolnee-Chat tests whether a solo builder can win a narrow slice of website AI by trading hosted convenience for inspectable code, provider choice and deployment control. Aniket Wathore has published Bolnee-Chat https://github.com/AniketWathore/bolnee-chat?ref=runtimewire , an open-source retrieval-augmented chatbot for business websites. He presented the project in an August 30 post https://news.ycombinator.com/item?id=49497227&ref=runtimewire . The application can run on infrastructure controlled by the operator, while data sent to a cloud model provider leaves that infrastructure. The project is an early solo effort rather than a commercial launch with established customers. Its public GitHub repository had one contributor, one star, one fork and 43 commits https://github.com/AniketWathore/bolnee-chat/commits/main/?ref=runtimewire when reviewed on August 30. That modest footprint makes the product's scope more useful than its traction as a measure of Wathore's bet: some businesses want a website bot without handing the entire workflow to a hosted chatbot vendor. Wathore's LinkedIn profile https://in.linkedin.com/in/aniket-wathore-99a9ba248?ref=runtimewire places him in Nanded, Maharashtra, India, and lists Tehra Technologies Pvt. Ltd. under his experience. His GitHub profile https://github.com/AniketWathore?ref=runtimewire lists interests in machine learning, quantitative finance and data, and his other repositories include a multi-agent workspace for coding agents and a breast-cancer detection project built around image processing and supervised learning. Bolnee-Chat fits that pattern of building applied systems across several parts of the machine-learning stack rather than wrapping a single model API. A deliberately narrow product Bolnee-Chat lets an operator create a bot, crawl a website, upload files and connect an OpenAI-compatible model provider, according to the repository README https://github.com/AniketWathore/bolnee-chat?ref=runtimewire . The documented options include OpenRouter, OpenAI, Groq, Ollama and vLLM, covering hosted APIs as well as models running on hardware controlled by the operator. The resulting chatbot is added to a website through two script blocks. Wathore built a management console for configuring the bot's name, avatar, colors, greeting, theme, default response and fallback behavior. The README says https://github.com/AniketWathore/bolnee-chat?ref=runtimewire the widget streams replies and stores a visitor identifier and chat history in the browser's local storage. It also documents conversation grouping by visitor and exports in CSV, JSON or PDF formats. The project documentation https://github.com/AniketWathore/bolnee-chat?ref=runtimewire describes SQLite storage for chatbot settings, sources, chunks and messages. It also describes a Python crawler that respects robots.txt and extracts page content, plus ingestion of PDF, TXT, Markdown and DOCX files. Bolnee-Chat uses full-text search to retrieve relevant material for a response and can return citations to the underlying sources, according to the README. That approach avoids the operational breadth of a general agent builder. Bolnee-Chat is aimed at one familiar job: answer questions using a business's website and documents, then appear as a floating chat widget. The constraint may help a solo maintainer ship a product that users can understand without constructing workflows or learning a broader automation platform. Deployment still has a bill Wathore describes Bolnee-Chat as "free forever" https://github.com/AniketWathore/bolnee-chat?ref=runtimewire and distributes it under the MIT License. The software itself can be used without a per-message fee paid to Bolnee-Chat, but a deployment still requires compute, storage and a model endpoint. Businesses connecting OpenAI, Groq or another paid API would remain responsible for those provider charges. Running Ollama or vLLM shifts the model bill into hardware and infrastructure instead. The project's value proposition is control over deployment and vendor choice. An operator can change providers, keep the SQLite database on its own infrastructure and inspect the code responsible for crawling, retrieval and chat delivery. Inputs sent to a cloud model provider still leave the operator's infrastructure. Self-hosting also leaves the operator responsible for uptime, updates, backups and security configuration. The Bolnee-Chat README https://github.com/AniketWathore/bolnee-chat?ref=runtimewire documents a DISABLE AUTH=true option for a no-login, single-tenant console and lists false as the default value, meaning authentication is enabled by default. The repository's Vercel and Cloudflare examples explicitly set DISABLE AUTH=true . That mode lowers the friction for testing and private installations, but anyone exposing the console beyond a controlled environment needs to evaluate access controls before treating it as a production deployment. The README also says model-provider credentials are encrypted with AES-256-GCM and excluded from the website embed code; that remains a project claim based on Wathore's implementation and documentation. Shipping in public The repository's visible history dates back to May 2026, with a concentrated run of product work immediately before Wathore's August 30 public post. Commits on August 29 and 30 added grouped conversations, appearance settings, persistent widget history, dark and light themes, documentation, crawler changes and fixes for messages that were not appearing in the console. That sequence shows Wathore moving from a working chatbot backend toward the less glamorous details that determine whether another person can deploy it: embed code, setup instructions, exports, visual controls and troubleshooting notes. It also shows how early Bolnee-Chat remains. The latest work includes same-day fixes to theme synchronization, message display and README image paths. The category already has mature alternatives. Chatbase https://www.chatbase.co/docs/user-guides/quick-start/your-first-agent?ref=runtimewire trains website agents on files and web pages and supplies embed code. Botpress https://botpress.com/docs/webchat/get-started/introduction/?ref=runtimewire offers a website client that ranges from a script tag to customizable React components. Dify https://www.dify.ai/rag?ref=runtimewire provides self-deployed software for broader knowledge pipelines and AI workflows, while AnythingLLM https://anythingllm.com/?ref=runtimewire emphasizes private and locally operated AI applications. Bolnee-Chat cannot claim adoption or a proven operating advantage against those products. Its opening lies in being smaller. Wathore has put the crawler, retrieval layer, dashboard, widget and provider settings into a codebase designed around a single website-chat use case and a SQLite database. For a technical operator who wants inspectable code and accepts responsibility for deployment, that simplicity may carry more weight than a longer feature list. Wathore now has the harder part in front of him. The repository establishes that Bolnee-Chat can be installed and configured. Real deployments will test whether its crawler handles messy websites, whether retrieval quality holds across larger document sets, and whether a solo maintainer can keep pace with model-provider changes. The public code gives prospective users enough access to test those questions directly, which is the strongest argument an early open-source project can make.