Vexa: self-hosted meeting bots that stream transcripts and hand them to sandboxed agents
Open-source meeting transcription API for Google Meet, Microsoft Teams & Zoom. Auto-join bots, real-time WebSocket transcripts, MCP server for AI agents. Self-host or use hosted SaaS.
At a glance
- What is it?
- Vexa is an Apache-2.0 Python stack that puts a bot into Google Meet, Microsoft Teams, Zoom or Jitsi, streams speaker-attributed transcripts over an API or WebSocket, and optionally compiles the result into a Markdown knowledge base worked by sandboxed agents. The capture lane is usable on its own; the agent lane is self-host only.
- Who is it for?
- Adopt Vexa if you need a bot that actually joins Meet, Teams or Zoom calls and you are willing to run the Docker Compose stack yourself, or if you want meeting transcripts to land as Markdown files inside your own network.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, 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 Vexa targets: getting a participant into the call at all
Most meeting AI products begin after a transcript exists. They ingest a file, a recording or a webhook payload and then do retrieval or summarisation over it. Vexa starts one step earlier, at the point where there is no transcript yet. The README frames this as the hard part: a real bot has to join Google Meet, Microsoft Teams and Zoom as a participant, and stream speaker-attributed text while the call is still running. The project describes that bot fleet as the genuinely hard piece and notes that every chat-with-your-docs tool starts after a transcript exists, while Vexa produces it. That is the claim to evaluate. The intended audience is engineers who want the capture layer as infrastructure rather than as a subscription: people who will run Docker Compose on their own host, point the stack at their own speech-to-text endpoint, and consume transcripts over an HTTP API or a WebSocket. A second audience appears in the same README, teams that want meetings compiled into Markdown files in a git repository and then edited by coding agents. Those two audiences overlap but do not have to. The README says the transcription API is a complete standalone product and that you can ignore the agent lane entirely.
One gateway, two domains, and a runtime that spawns both
The architecture in the README is deliberately narrow: a single API gateway routes to two domains, Meetings for capture and Agents for working the captured knowledge, and both domains run on the same runtime. That runtime is described as the engine that spawns every bot and every agent in its own sandboxed container, on Docker, Kubernetes or Process. The README states that a bot and an agent are the same runtime.v1 workload, isolated, ephemeral and reaped on idle. The practical consequence is that the container lifecycle you already need for bots is the same one that runs agents, so there is no second scheduler to operate. The data flow for the capture lane is visible in the quickstart: a POST to /bots with a platform and a native meeting id, then a GET against /transcripts/{platform}/{native_meeting_id} to read what the bot heard. The README describes the transcript as draft-then-confirmed, which implies the API distinguishes provisional text from settled text rather than emitting one final string per utterance. The agent lane is a separate endpoint, /agent/chat, which answers over Server-Sent Events; the README says message-delta frames carry the text and commit frames mark anything the agent recorded into your workspace. That commit frame is the interesting design choice, because it separates a conversational answer from a write into the repository.
Getting it running: make all, make lite, make dev
The self-host path is short. Clone the repository, run make all, and the target seeds .env, pulls the published images including the bot image, and prints your API key and URLs. The README states that make all pulls release-validated images rather than building, so a modest machine is sufficient, and that make lite runs a single-container all-in-one image which is lighter still. Building from the checkout is a separate target, make dev, aimed at contributors, and the README puts its requirement at 8 vCPUs and 16 GB RAM. Prerequisites are make and Docker engine 26 or later, which make all checks. On success the README shows three lines of output: a Terminal UI on http://localhost:13000, an API gateway on http://localhost:18056, and an API key beginning vxa_. The Terminal is described as the fast path for seeing what the stack does, with a self-host account already signed in, so you can paste a meeting URL, watch the transcript stream, and chat with the workspace without writing curl. For API use, the README sets API_KEY and API_BASE as environment variables and shows a POST to $API_BASE/bots with the X-API-Key header and a JSON body containing platform, native_meeting_id and bot_name. Accepted platform values are google_meet, teams, zoom and jitsi. The transcription dependency is explicit: POST /bots requires speech-to-text by default and answers 503 when it is missing, and make all warns when the credentials block in .env is empty. Capture-only is an opt-out, either per spawn with transcribe_enabled set to false or per deployment with TRANSCRIBE_ENABLED=false.
Where the documentation is thin and where the design costs you
The README is strong on the shape of the system and weak on the operational detail an adopter needs. It does not describe the WebSocket transcript protocol beyond naming it, so the frame types, reconnection behaviour and backpressure handling are not visible in the supplied material. It does not enumerate the agent API beyond /agent/chat, so the surface for reading or writing the knowledge repository is unclear. The runtime is described as reaped on idle, but no idle threshold, resource limit or concurrency ceiling is given, which matters because the README also mentions thousands of agents in parallel without saying what that costs in memory or how it is bounded. The capture-only opt-out is a real trade-off worth naming: setting transcribe_enabled to false on a spawn gives you a bot in the room with no transcript, which is only useful if you are testing join behaviour or recording by other means. The Jitsi path is the clearest limitation. The README states that Jitsi join and capture are offline-proven with live validation pending, and links issue 883, so Jitsi should be treated as unverified for production use until that changes. The last constraint is structural rather than technical: the hosted service runs the meeting bots and transcription, and the README says sandboxed knowledge agents are self-hosted only, so the agent plane cannot be adopted without operating the stack.
How Vexa differs from a hosted notetaker and from a plain speech-to-text pipeline
The obvious alternative is a commercial notetaker that joins your calendar, records the call and sends you a summary. The difference is not the feature list, it is where the data lives and who operates the bot. A hosted notetaker runs the bot in the vendor's cloud and returns an artefact; Vexa runs the bot in a container on your host, or on the vendor's cloud if you use the hosted service, and returns a stream you consume. The second alternative is the one most engineers already have: a speech-to-text service plus a pipeline that ingests recordings. That approach avoids the hardest part of the problem entirely, because it never has to authenticate as a participant, handle waiting rooms, or survive a platform changing its join flow. Vexa takes on that maintenance burden in exchange for live, speaker-attributed text during the call rather than a file afterwards. The third comparison is against agent frameworks that read a document store. Vexa's agent lane is narrower and more opinionated: the knowledge is Markdown in a git repository, and the README describes agents reading and writing that repository like developers inside isolated ephemeral containers with no egress. That is a specific storage decision, not a general retrieval layer, and it will not suit teams whose knowledge already lives in a wiki or a database.
Licence, maintenance and upgrade cost
Vexa is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes a patent grant. It does not impose copyleft on your own code. This is a description of the licence text, not legal advice; if you redistribute the stack or embed it in a product, have counsel review the NOTICE and attribution requirements. The maintenance picture from the supplied material is a fast-moving project. The repository shows v0.13.1 tagged the minutes line as alpha on 2026-09-07, v0.12.27 published the same day with the full MCP, flows and searchable meetings, and v0.12.26 a week earlier. The README's own badge still reads version 0.12 while the latest release is 0.13.1, which tells you the documentation lags the code. A project releasing three versions in eight days is not one to pin and forget. Budget for reading release notes before upgrading, and expect the alpha label on the minutes feature to mean its output format can change between releases. The upgrade path itself is favourable: make all pulls published images, so moving to a new release is a pull and a restart rather than a rebuild, unless you are on make dev and building from the checkout.
Editorial conclusion
Adopt Vexa if you need a bot that actually joins Meet, Teams or Zoom calls and you are willing to run the Docker Compose stack yourself, or if you want meeting transcripts to land as Markdown files inside your own network. Do not adopt it if you need a hosted service with a published SLA, if you cannot supply speech-to-text credentials, or if you expect the agent plane to be available from the cloud offering, because the README states sandboxed knowledge agents are self-hosted only. Before committing, verify three things on your own infrastructure: that make all completes and prints an API key, that POST /bots returns a transcript rather than a 503 on your STT configuration, and that the Jitsi path is still in the state the README describes, since it lists Jitsi live validation as pending and points at issue 883.
Community notes