The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Vexa listing page.
Open-source meeting bots and real-time transcription — cloud or fully self-hosted.
A bot joins your Google Meet, Microsoft Teams, and Zoom calls and streams speaker-attributed transcripts in real time — through our API or one you host — then feeds sandboxed agents that build a Markdown knowledge base your team owns. Apache-2.0, air-gap-ready. (Jitsi: join + capture offline-proven, live validation pending — #883.)
vexa.ai runs Vexa 0.12 for meeting bots and transcription. Sandboxed knowledge agents are self-hosted only — self-host Vexa to run the full stack.
Every meeting-AI tool you can buy sends your conversations to their cloud and rents you access back. Vexa inverts that: run the stack yourself, point it at your own models, own what your meetings become.
No one else has all three:
Vexa is in the meeting. A real bot joins Meet, Teams and Zoom — Jitsi offline-proven, live validation pending — and streams speaker-attributed transcripts live. That bot fleet is the genuinely hard part — every "chat with your docs" tool starts after a transcript exists. Vexa produces it.
Your knowledge is files you own. Meetings compile into Markdown in a git repo — portable, diffable, greppable. Knowledge as code.
Agents work it, safely. Sandboxed coding agents read and write that repo like developers — isolated ephemeral containers, no egress, thousands in parallel, on Docker or your Kubernetes.
Only here for the transcription API? It's a complete standalone product — send a bot, read the stream, ignore the agent lane entirely.
Just want a bot in a meeting? Use the hosted service — no install. Sign in at vexa.ai/signin, copy your key from your account page, and send a bot:
New accounts get $5 of free bot credit, no card required — about 16 hours of bot time at $0.30/hr (pricing). More calls: Send a bot.
That is also how you get the agent plane, which is not part of the hosted service. Self-host on one host, then explore it in the Terminal or drive it over the API. Linux (Ubuntu 24.04) is the production target; a Mac with Docker Desktop works fine for a local evaluation — everything runs in containers either way.
Prerequisites — make, Docker engine ≥ v26 (make all checks), and transcription: a free token at
vexa.ai/account, or self-host the (GPU) transcription unit for a fully
air-gapped setup. By default POST /bots requires STT and answers 503 when it is missing
(make all warns when the credentials block in .env is empty). Capture-only is an explicit opt-out:
{"transcribe_enabled": false} on the spawn (or set TRANSCRIBE_ENABLED=false for the deployment).
Build machine:
make allpulls the published, release-validated images — no build, so a modest box is fine.make lite(the single-container all-in-one image) is lighter still. Building from this checkout instead (make dev, for contributors) wants 8 vCPUs and 16 GB RAM.
When make all finishes it prints your key and URLs:
The Terminal is the way to see what Vexa can do. Open http://localhost:13000 — you're
already signed in to a self-host account. From the
workbench you can, with no curl:
platform is google_meet · teams · zoom · jitsi; native_meeting_id is the code from the join URL. The
agent reply streams as Server-Sent Events — message-delta frames carry the text, commit frames mark
anything it recorded into your workspace.
One gateway, two domains — Meetings (capture) and Agents (work the knowledge) — both running on the same runtime: the engine that spawns every bot and every agent in its own sandboxed container.
A bot and an agent are the same runtime.v1 workload — isolated, ephemeral, reaped on idle — so the
machinery already proven by thousands of meeting bots is exactly what runs your agents. Every arrow stays
inside your network.
A CLI coding agent is just a process on Linux. The runtime makes that a multi-tenant, sandboxed execution layer safe to point at real business data — the same engine that already spawns Vexa's meeting bots in production.
runtime.v1 lifecycle, pluggable substrate — the same
dispatch runs identically across:Backend (RUNTIME_BACKEND) | A workload is… | State |
|---|---|---|
docker (default) | its own container via the Docker socket — brought up with make all | ✅ Shipped (open core) |
process | a child process, no Docker socket required | ✅ Available |
k8s | a bare Pod (kubectl run --restart=Never), scheduled across a cluster | ✅ Lifecycle + per-mount workspace isolation; Helm chart in deploy/helm |
Same control plane, same worker — only how the container is created changes. One laptop to a Kubernetes/OpenShift cluster, inside your walls.
Capture is the front door; agents make the knowledge compound. Every meeting compiles into
your workspace — a git repo of Markdown (an Open Knowledge Format
kg/ bundle) that agents (Claude Code, Codex, …) read and write like developers work a codebase.
This is Andrej Karpathy's LLM Wiki pattern, run as a team service. The idea: don't RAG over raw documents — where the model rediscovers everything from scratch on every question — have agents compile sources into structured, interlinked markdown entity pages (people, companies, projects, decisions) so knowledge compounds. Vexa builds that wiki for you from the richest source there is: your meetings. Each call is ingested into entity pages; agents keep them current between calls; every answer starts from what your team already knows — on your own servers.
Agents work any workspace; a meeting is just one trigger of four — chat, schedule (cron), event (e.g. incoming email), finished meeting. Meetings themselves are scheduled work: connect your calendar (ICS) and planned meetings appear with attendees — bots auto-join, agents prepare before the call and process after it.
Status (honest): capture, transcription, and speaker attribution are production; the agent dispatch core is built and proven live end-to-end. What's still landing is tracked in Status.
0.12 ships a new Terminal UI built to put the backend's scale — thousands of bots and agents — to work on your actual week. It opens on your meetings: coming up, live now, to review.
An agent in your meeting, with your knowledge. Open a live call: the transcript streams speaker-attributed, and the agent has the live conversation and your workspace in context. Ask mid-call "what did we promise them last time?" — or research a person, company, or contract the moment it comes up, grounded in your wiki.
Knowledge built on meetings — and between them. Every planned meeting gets an agent that prepares the brief before (who's coming, history, open threads — it interviews you for what it can't know) and processes the transcript after. Arrive prepared, leave with the wiki updated.
Sharing. Invite colleagues into a workspace — same wiki, attributed. Share a meeting with its attendees — they get the real-time feed, not a recording link after the fact.
Collaborative, AI-augmented meetings. Prep a shared workspace together; during the call, humans edit the brief while agents stream the transcript in and work the knowledge — one room, human and AI participants on the same files.
Each is a complete path to one outcome over the Agent API. Full guides at docs.vexa.ai.
💬 Chat with your workspace — ask an agent that has every meeting, email, and note as context; trusted chat can also record a decision (a git commit).
🌅 Brief me every morning — an unattended agent on a cron schedule that commits to your workspace.
📝 Report after every meeting — dispatch a one-shot agent when a call ends (or a routine that sweeps recent meetings).
📧 Triage incoming email (safely) — an event-triggered agent that gets the mailbox read-only and can only propose actions as cards; a human approves before anything is written or sent.
During the call — stream the live transcript with
GET /agent/meeting/streamand ask your agent about it in the chat. Vexa runs no model of its own during a meeting: there is one intelligence and it is your agent. See Status.
Two ways to run Vexa, one codebase:
1. Personal / dev — Docker on your Mac, Linux, or Windows machine.
Single container (make lite — the all-in-one Vexa Lite image) or the full Compose stack
(make all). Reuse your Claude subscription: workers run the official claude CLI against
your own Pro/Max credential, which is a covered, credit-metered use under Anthropic's terms for a
personal deployment — your subscription, your turns, your machine. See
Model credentials & licensing for the exact
terms mapping (Anthropic's Agent SDK plan-usage article
is the primary source). You get the full service — bots, transcripts, agents, Terminal — on the
subscription you already pay for.
2. Cloud — Helm on Kubernetes / OpenShift, scalable to thousands of users.
The chart in deploy/helm deploys the same control plane with
RUNTIME_BACKEND=k8s: every bot and every agent is its own Kubernetes workload (a bare Pod
per dispatch), so capacity is your cluster's scheduler, not a bigger box — built multi-tenant and
multiuser from the start. One compliance rule when you go multiuser: other users' turns must run
on an API key (Commercial Terms), never a personal subscription credential — the
licensing page spells out the boundary, and
Settings → Models enforces per-user/global credential resolution. K8s backend status is tracked
honestly in Status.
make all brings up the full stack via Docker Compose on one Linux host — each service in its own
container, bound to loopback:
| Service | Role |
|---|---|
gateway :18056 | the one front door — auth, scopes, routing |
terminal :13000 | the web workbench (proxies /ws → gateway) |
| meeting-api | bots, transcripts, recordings |
| agent-api | the agent control plane — dispatch, chat, routines, events |
| runtime | spawns bot + agent containers on demand |
| admin-api · redis · postgres · minio | keys · bus + scheduler · metadata · object storage (recordings + workspaces) |
RUNTIME_BACKEND=docker (default) or k8s (a Pod per dispatch).make all runs GPU-free; stand up the STT service
(faster-whisper, OpenAI-compatible) from deploy/transcription on any GPU box and point .env at it.
Or use a free hosted token at vexa.ai/account while testing.make all (pulls) · make dev (builds from this checkout) · make lite ·
make probe (full-journey smoke) · make down · make help. Expose the Terminal via a TLS reverse proxy for
production; full guide in the docs.The crowded "AI second brain / self-hosted knowledge base" space is full of excellent tools for reasoning over documents you already have. None of them join a live meeting — they consume transcripts other tools produced. That's the whole point: capture is the moat, and it sits upstream of where a document-RAG tool's architecture even starts.
Against the tools developers actually weigh for meeting capture:
| Capability | Vexa | Hosted APIs (e.g. Recall.ai) | DIY (Whisper + your own bot) |
|---|---|---|---|
| Self-hosted / own your data | ✅ | ❌ their cloud | ✅ |
| Real-time transcript API | ✅ | ✅ | 🟡 build it |
| Joins Meet + Teams + Zoom + Jitsi | ✅ 3 production · 🟡 Jitsi | 🟡 varies | ❌ enormous effort |
| Speaker attribution | ✅ | ✅ | 🟡 build it |
| Knowledge as files you own | ✅ | ❌ | 🟡 build it |
| Agents over your workspace | ✅ | ❌ | ❌ |
| Open source | ✅ Apache-2.0 | ❌ | ✅ |
Vexa is the one combination the others don't offer: a permissively-licensed (Apache-2.0) meeting-bot-API server that is self-hosted × real-time × multi-platform × knowledge-you-own. And it's complementary to the document-RAG and "second brain" tools — feed them Vexa's clean, attributed transcripts and let them do what they're good at.
The full field — including Attendee (the other meeting-bot API, source-available under the Elastic License 2.0, which does not permit providing it to third parties as a hosted or managed service) and the local-notetaker tools — is mapped honestly, trade-offs and all, in How Vexa compares.
For banks, healthcare, government, and anyone in a regulated industry, the meeting-AI question isn't "which cloud" — it's "how do we get this without a cloud." Vexa is air-gapped meeting intelligence — the sovereign alternative to Microsoft Copilot — built for exactly that buyer.
You don't compete with a notes app here — you replace Microsoft 365 Copilot and Zoom AI Companion on the axes they structurally can't move:
| Microsoft 365 Copilot / Zoom AI Companion | Vexa | |
|---|---|---|
| Deployment | Vendor cloud only | Your cloud, your VPC, or fully air-gapped |
| Models | Vendor-hosted, fixed | Bring your own — local or hosted LLMs |
| Commercial model | Rented, per-seat subscription | Owned — Apache-2.0, no per-seat tax |
| Adaptable | Generic; no custom vocabulary; vendor roadmap queue | Your engineers extend it directly — domain vocabulary, underserved languages, custom workflows |
| Meeting platforms | Teams-only / Zoom-only | Meet + Teams + Zoom (+ Jitsi, live validation pending) |
| Data control | Transits the vendor's cloud | Never leaves your perimeter |
| Extensibility | Closed black box | Open source, API-first |
What that means in practice:
Evaluate it for your org — the artifacts a security review asks for, in this repo:
| Artifact | What it answers |
|---|---|
architecture.calm.json | machine-readable architecture (FINOS CALM) — every service and data flow, drift-gated in CI |
SECURITY.md | how to report a vulnerability |
security-insights.yml | OpenSSF Security Insights manifest |
license-exceptions.json | license gating: Category-A permissive deps, exceptions explicit |
LICENSE | Apache-2.0 |
Full review page: Security & compliance in the docs.
Regulated banks and Fortune-500s run Vexa fully air-gapped on their own OpenShift and local LLMs today.
Two APIs behind the gateway, authenticated with X-API-Key. Base URL: http://localhost:18056
(self-host) or https://api.cloud.vexa.ai (hosted).
Meetings API — capture; usable standalone:
| Method | Endpoint | Description |
|---|---|---|
POST | /bots | Send a bot into a meeting (platform, native_meeting_id, bot_name, language, task, optional transcribe_enabled / recording_enabled) |
GET | /transcripts/{platform}/{native_meeting_id} | Fetch the real-time transcript (poll while live) |
GET | /bots/status | List running bots |
DELETE | /bots/{platform}/{native_meeting_id} | Stop / remove the bot |
GET | /meetings · /recordings | List meetings; list recordings (audio in your own storage) |
Agent API — the control plane, under the /agent/* prefix (identity is derived from your key, server-side):
| Method | Endpoint | Description |
|---|---|---|
POST | /agent/chat | Chat over your workspace — streams SSE (message-delta, tool-call, commit, done, error) |
POST | /agent/invocations | Dispatch a one-shot agent (e.g. a post-meeting report) |
POST | /agent/routines | Create a scheduled (cron) agent routine |
POST | /agent/events | Fire an integration event that dispatches an agent (e.g. email triage) |
GET | /agent/workspace/tree · /agent/workspace/file | Browse and read your Markdown workspace |
platform ∈ google_meet · teams · zoom · jitsi. The gateway also serves an MCP endpoint
at /mcp for agent clients (docs). Full reference:
docs.vexa.ai.
v0.12 note: live bot-control —
PUT /bots/{…}/config(change language/task mid-call) andPOST /bots/{…}/speak(TTS into the call) — plus WebSocket streaming are not yet wired in the open-core stack and return404today. So doPOST /agent/meeting/{start,process}, the removed in-product meeting copilot. Send-a-bot, stop, status, transcripts, recordings, the live transcript feed, agent chat, routines, and events are live.
Honest state of the 0.12 line (mirrors the status page — never aspirational):
| Capability | State |
|---|---|
| Bot joins Meet / Teams / Zoom | ✅ Production |
| Bot joins Jitsi Meet (meet.jit.si + self-hosted) | 🆕 Built & offline-proven; live validation pending |
| Real-time transcription (Whisper) + speaker attribution | ✅ Production — attribution is not guaranteed: the binder publishes an empty speaker rather than guessing (~4–7% of rows under heavy crosstalk) |
| Redis transcript streaming | ✅ Production |
| Recordings to your own object storage (MinIO) | ✅ Available |
| Runtime — Docker backend (container per workload) | ✅ Production |
| Agent chat / routines / events over your workspace | ✅ Built & proven live |
Workspace — git Markdown / OKF kg/ bundle | 🟡 core proven; bucket-backed store landing |
| Runtime — Kubernetes backend (Pod per dispatch) | ✅ Lifecycle + per-mount isolation; Helm in deploy/helm |
| Live transcript feed as the call runs (+ agent chat over it) | ✅ Built & proven live |
| Calendar sync (ICS) · planned meetings · scheduled auto-join | ✅ Production |
| Shared workspaces & shared meetings (invites, real-time feed) | ✅ Built & proven live |
| Agent chat during a live meeting (live transcript + workspace in context) | ✅ Built & proven live |
| WebSocket transcript multiplex | 🔵 Planned (poll today) |
| At-rest encryption (workspace · transcript · tokens) | 🔵 Planned |
| Mid-call bot config / speak | 🔵 Returns 404 in open-core |
✅ Production · 🟡 In progress · 🔵 Planned
SECURITY.md to report vulnerabilities.Vexa is built in the open. If you self-host it, extend it, or run it air-gapped somewhere interesting, we'd love to hear about it.
Apache-2.0. Own it, run it, fork it, ship it. It's an investment, not a rental.