Cossistant: an AGPL-3.0 React support widget with a self-hosted backend
Open-source, customer support platform with fully customizable AI support agents for developers / startups shipping SaaS.
At a glance
- What is it?
- Cossistant ships headless React primitives, a Next.js binding layer and a tRPC/Hono backend behind a chat widget. The code is AGPL-3.0 for non-commercial use, and the README routes commercial deployments to a paid licence.
- Who is it for?
- Cossistant fits teams already inside React and Next.js that want to own the widget markup and the message data, and it does not fit anyone who needs a permissive licence or a hosted product with no operational work.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Cossistant targets, and who it is built for
Most chat widgets arrive as a script tag and an iframe. You get a fixed bubble in the corner, a dashboard you do not control, and message history that lives on someone else's servers. Cossistant takes the opposite position. The README describes it as an "open source chat support widget for the React ecosystem", built by developers for developers, and the packages it lists are React SDK pieces rather than a drop-in script. The stated philosophy is code-first and API-driven, with headless components and real-time messaging on top of what the README calls "complete backend infrastructure". The target reader is a developer or a small startup shipping a SaaS product who wants the support surface to look and behave like part of the app rather than a third-party overlay, and who is willing to run the server side. The topics attached to the repository (agent, ai, aiagent, nextjs, react, support) point the same way. This is not a tool for a marketing team that wants a chat box live in ten minutes with no engineering time.
Headless primitives plus a server, not a hosted script
The split is visible in the package list. @cossistant/react carries headless hooks and primitives, which means the rendering is yours and the package supplies state and behaviour. @cossistant/next carries Next.js-specific bindings and utilities, so routing, server rendering and the framework's conventions are handled in a separate layer rather than folded into the core. A third package, @cossistant/protocol, appears in the release list at 0.3.0 alongside the other two, which suggests the wire format between client and server is versioned independently of the React bindings. That is a sensible arrangement for a real-time system: the protocol can move without forcing a UI rewrite. The backend stack is spelled out in the README: Hono for the API, tRPC for the typed call layer, Drizzle ORM for data access, Better Auth for authentication, WebSockets for live delivery, and Docker with Postgres plus Redis for local infrastructure. The data flow implied by that list is ordinary and legible. The widget authenticates a visitor through Better Auth, opens a WebSocket, and messages move through the Hono API into Postgres, with Redis present for the parts of a real-time system that need shared state. tRPC and Drizzle exist to keep types aligned from the database schema up to the React hooks. The README does not document the message schema, the reconnection behaviour, or how agent assignment works, so treat those as things to read in the source rather than in the marketing copy.
Getting it running: what the README does and does not give you
The README is short on setup commands. It points to a Quickstart Guide at cossistant.com/docs/quickstart for people using Cossistant in an app, and a Contributors Guide at cossistant.com/docs/others/contributors for people working on the project itself. The repository is a Turborepo monorepo managed with Bun, and Docker is listed for Postgres and Redis, so the local path is a Bun install, a Docker compose step for the two backing services, and environment variables for the database and Redis connections. That last part is an inference from the stack list, not a documented procedure. The README does not print the compose file name, the environment variable names, or a migration command, and no config keys appear anywhere in the supplied material. The only concrete install surface it names is npm: @cossistant/react and @cossistant/next. If you are evaluating this, the honest first step is to open the Quickstart page and the repository's compose and env files, because the README alone will not get a running instance. That is a documentation gap worth weighing against the project's stated emphasis on developer experience.
The AGPL-3.0 boundary is the real adoption decision
The licence section is unusually direct. Cossistant is licensed under AGPL-3.0 "for non-commercial use", and the README asks anyone with commercial use or a deployment requiring a setup fee to contact anthony@cossistant.com for a commercial licence. Two things follow. First, AGPL-3.0 is a copyleft licence with a network clause: if you run modified code as a network service, the source obligations reach the users of that service. Second, the README frames the open licence as non-commercial, which is narrower than AGPL-3.0 on its own, since the licence text itself does not draw that line. That combination is the single most important fact for a SaaS team, and it is the kind of thing to put in front of whoever handles licensing at your company rather than deciding from a README paragraph. I am not giving legal advice here, and the README's own commercial contact is the stated route for anything beyond non-commercial use. For a hobby project, an internal tool, or an open source product that can live with copyleft, the terms are workable. For a closed-source paid product, the licence, not the code, is what you are negotiating.
Where Cossistant is the wrong tool
If you want a support widget without running infrastructure, Cossistant is the wrong shape. It expects Postgres, Redis, an API process and a WebSocket endpoint, and the README lists no managed hosting option. That means backups, migrations, uptime and scaling sit with you. The version numbers reinforce the point: the three published packages are at 0.3.0, which is pre-1.0 territory, and a pre-1.0 protocol package can change in ways that force client updates. Teams that cannot absorb a breaking change in a chat integration should wait or pin versions deliberately. There is also a framework constraint. The packages are React and Next.js specific, and the README names no Vue, Svelte or plain-JavaScript binding, so a non-React frontend would need to work against the protocol and API directly, which the README does not document as a supported path. Finally, the AI agent angle is the thinnest part of the supplied material. The repository topics mention agent and aiagent, but the README describes the product as a chat support widget with real-time messaging, and it does not explain how an AI agent is configured, prompted or handed a conversation. Anyone buying this for the AI support agent specifically is buying on the docs site, not on the README.
How this differs from an embedded hosted widget
The obvious alternative is a hosted support product where you paste a script tag and get a dashboard, a knowledge base and an inbox with no server of your own. The difference is not feature count, it is where the boundary sits. A hosted widget owns the DOM, the data and the upgrade schedule; you get configuration options and an API, and you accept that the message history is theirs and the visual layer is theirs unless they expose deep theming. Cossistant inverts that. Headless hooks mean the markup is yours, Drizzle and Postgres mean the message data is in your database, and the WebSocket and API are processes you run. You gain control over the widget's appearance, over where conversation data lives, and over how the support surface integrates with the rest of your app's auth and user model through Better Auth. You pay for it in operational work and in the licence question above. This is a genuine trade rather than a strict improvement: the hosted option is faster to ship and cheaper to run at small scale, and Cossistant is the better fit only when owning the data and the rendering is worth the infrastructure.
Maintenance cost and what to check before you commit
The maintenance surface here is larger than a script tag. You are responsible for Postgres and Redis, for the API and WebSocket processes, and for keeping three versioned packages (@cossistant/types, @cossistant/react, @cossistant/protocol) in step with each other. The release timestamps show those three published within minutes of one another at 0.3.0, which suggests they are meant to move together, so an upgrade is a coordinated change rather than a single dependency bump. The monorepo uses Turborepo and Bun, which is a reasonable setup but adds two tools your build pipeline may not already have. On licence: AGPL-3.0 is the stated licence, the README describes it as applying to non-commercial use, and commercial deployments are directed to a paid licence by email. Check that against your own distribution model before writing any integration code, because it affects whether the rest of this evaluation matters. Then verify two things that the supplied material cannot answer: whether the Quickstart at cossistant.com/docs/quickstart documents the environment variables and migration steps the README omits, and whether the AI agent behaviour promised by the repository topics is actually specified anywhere in the docs. If both come back thin, the project is a React chat widget with a self-hosted backend and an unsettled licence position, and that is the thing you would be adopting.
Editorial conclusion
Cossistant fits teams already inside React and Next.js that want to own the widget markup and the message data, and it does not fit anyone who needs a permissive licence or a hosted product with no operational work. Before adopting it, check the current published versions of @cossistant/react and @cossistant/next on npm against the 0.3.0 release notes, and read the AGPL-3.0 terms plus the commercial licence contact in the README, because the licence boundary decides more about this project's fit than any API detail.
Community notes