covan
Health Warn
- License — License: AGPL-3.0
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 6 GitHub stars
Code Pass
- Code scan — Scanned 12 files during light audit, no dangerous patterns found
Permissions Pass
- Permissions — No dangerous permissions requested
No AI report is available for this listing yet.
A shared AI agent for your team. Everyone trains it together; everyone talks to it privately. Self-hostable, AGPL-3.0.
Covan
A shared AI agent for your team. Everyone trains it together; everyone talks to
it privately.
Half a minute, uncut: start from a template, let the persona write itself from
the name, and the agent is live in a chat that belongs to you alone.
https://github.com/user-attachments/assets/6ac7bc61-2588-4949-918a-e66ccbc2db56
What is Covan?
Most team AI tools are built for engineers: a Slack bot, a sandbox, a
deployment pipeline. Covan is built for the rest of the company.
Your team uploads what it knows — process docs, contracts, research — and that
becomes one agent's memory. Everyone talks to that agent in their own private
session, so the designer's questions and the finance lead's questions never mix.
Give it a persona ("you are our senior product manager") and it answers like
one.
Features
- Shared brain, private rooms. One agent, trained collectively; every
conversation isolated per person by Postgres row level security, not by a
check in the API. - Knowledge bundles. Group documents by subject and attach or detach them
from an agent, instead of one undifferentiated pile. - Grounded answers. Retrieval over your documents —
pgvector, with a
similarity floor so an off-topic question doesn't drag in the nearest
irrelevant passage — and the documents that grounded a reply are stored with
it, so citations survive a reload. - Routines. Scheduled work that runs while nobody is watching: point one at
an RSS feed or a page, say what to do with it, and get the result by email or
Slack. - Collaborative sessions. Bring the team into one conversation, or one
brainstorm board, when the question is shared. - Bring your own endpoint. Set
OPENAI_BASE_URLand completions go to
Ollama, vLLM, LiteLLM or OpenRouter instead of OpenAI. Embeddings and
transcription still don't — the embedding column isvector(1536), so that
half is a migration rather than a variable, anddocs/self-hosting.mdsays so plainly. - Two runtimes, one source. The same code runs on Cloudflare Workers with R2
in production and on Node with the filesystem underdocker compose.

Every figure in that answer is in the uploaded document, and the chip under it
says which one. That is the whole difference between this and a chat window: not
that it answers, but that you can check it.
How this differs from qm
yc-software/qm (MIT) is the obvious
alternative and a good project. It describes itself as a multiplayer agent
harness for work: an isolated agent workspace per employee, shared channels
and projects, Slack and web, and a pluggable choice of model. If your team is
mostly engineers, that is very likely what you want, and it is better to say so
than to pretend the comparison isn't there.
Covan is not a harness. It is one agent that knows what your team wrote down,
and a small surface around it — upload, ask, schedule. The bet is that a
five-person agency, a clinic, or a finance team does not want to operate agent
infrastructure; it wants a colleague who has read everything. That is why the
whole product is one docker compose up and one API key, and why the only
interface is a web app: there is no CLI, and nobody has to be the person who
runs it.
Status
Covan runs, and it was extracted from a working private product rather than
written as a demo. It is nonetheless young as an open-source project: the API is
unversioned and nothing is promised about compatibility between commits. Readdocs/self-hosting.md before you put it in front of
anyone outside your team.
Quick start
No accounts, no cloud setup. You need Docker and an OpenAI API key.
git clone https://github.com/covan-ai/covan
cd covan
cp .env.docker.example .env # set OPENAI_API_KEY
docker compose pull # optional: published images instead of a build
docker compose up
Then open http://localhost:3000 and create an account — any email and
password; there is no mail server in the stack, so confirmation is off.
docker compose pull is worth the extra line. Without it the first run compiles
the frontend on your machine, which is a few minutes; with it, both Covan images
come fromghcr.io/covan-ai prebuilt for
amd64 and arm64. Either way the stack pulls half a dozen supporting images —
Postgres, GoTrue, PostgREST, Kong — so give the first start a minute.
Pin a release with COVAN_VERSION=0.1.0 in .env — no leading v, since the
image tags are semver — or track the branch with COVAN_VERSION=edge. The
default is latest, which follows releases.
Stop with docker compose down; add -v to throw away the database and the
uploaded documents too.
For a production deployment — Cloudflare Workers, Supabase and Vercel, or a
single Docker host — see docs/self-hosting.md.
Architecture
flowchart LR
WEB["Web app<br/>TanStack Start · React"]
API["API<br/>Hono · Workers or Node"]
DB[("Postgres<br/>RLS · pgvector")]
STORE[["Documents<br/>R2 or filesystem"]]
LLM["OpenAI"]
WEB -->|"bearer token"| API
API -->|"request-scoped client<br/>auth.uid() → RLS"| DB
API --> STORE
API --> LLM
Authorization lives in Postgres, not in the API. Each request carries the
caller's token into a request-scoped Supabase client, so row level security
decides what that user can see. The API cannot accidentally widen access by
forgetting a where clause.
Storage and scheduling sit behind interfaces, so the same source runs on
Cloudflare Workers with R2 in production and on Node with the filesystem in the
Docker stack.
See docs/architecture.md for detail.
Documentation
docs/ is the whole of it. The same files are rendered at
https://covan.app/docs if you would rather read them there.
| Page | What it answers |
|---|---|
| Quickstart | From an empty account to an answer that names the file it came from |
| Core concepts | Workspace, agent, bundle, session, routine — what each is and how they nest |
| Knowledge bundles | Uploading, grouping, attaching, and why a question finds the passage it does |
| Routines | Scheduled work, what it can reach, and what it does with the secret you give it |
| Your team | Invitations, what a role actually gates, shared sessions, deletion |
| Self-hosting | Running it on your own machine, and deploying it somewhere real |
| Architecture | How a request reaches a row, and the two seams that serve both runtimes |
Repository layout
| Path | What it is |
|---|---|
src/ |
TanStack Start frontend — file-based routes, shadcn/ui |
worker/ |
Hono API; src/index.ts is the Worker, src/node.ts Node |
supabase/migrations/ |
Numbered SQL, applied in order |
docker/ |
Compose support files (Kong config, DB init hooks) |
docs/ |
The documentation above, in markdown |
Development
Node 22 or newer, and Bun. Node 22 is a floor, not a
preference: @supabase/supabase-js builds a realtime client that needs a globalWebSocket, which arrived in Node 22, and the frontend imports it during
server-side rendering — so on Node 20 every server-rendered page returns an
error shell while the build stays green.
bun install
cd worker && bun install && cd ..
cp .env.example .env
cp worker/.dev.vars.example worker/.dev.vars
Frontend, from the repo root:
bun run dev # vite dev server
bun run test
bun run lint
API, from worker/:
bun run dev # wrangler dev
bun run test
bun run typecheck
bun run dry # wrangler deploy --dry-run
You still need backing services for bun run dev. The simplest way to get them
is docker compose up db auth rest realtime kong migrate and point .env andworker/.dev.vars at http://localhost:8000.
AGENTS.md is the short version of the rules that matter here; DESIGN.md is
the binding visual contract for new UI.
Contributing
See CONTRIBUTING.md — it includes the contributor license
agreement. Report vulnerabilities privately: SECURITY.md, not a
public issue. Behaviour expectations are inCODE_OF_CONDUCT.md.
What stays open
The product is the open part, and it stays that way. Agents, retrieval over your
own documents, routines, chat, workspaces and sharing are all here, with no
feature flags, no plan tiers and no licence keys — a self-hosted Covan is the
whole thing, not a trial of it. Nothing that works today will move behind a
paywall later.
There is a hosted Covan, and what it sells is not features: it is somebody else
running the database, the backups and the upgrades. If paid capabilities do
appear, they will be additions aimed at large organisations — single sign-on,
audit logs, fine-grained permissions, compliance exports — plus the operational
things a service can offer and a repository cannot: hosting, support, an SLA.
License
Copyright (C) 2026 Mahmut Efe Dara.
AGPL-3.0. You can run, modify and self-host Covan freely, including
inside your company. If you offer a modified Covan to others as a network
service, you must publish your changes under the same license.
Covan is free software: you can redistribute it and/or modify it under the terms
of version 3 of the GNU Affero General Public License as published by the Free
Software Foundation. It is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the license for details.
Reviews (0)
Sign in to leave a review.
Leave a reviewNo results found