The field
Meeting-bot APIs put a bot in the call and give you a server-side API — the only shape that works org-wide (IT deploys it once; every meeting can be captured, governed, audited):- Vexa (this project) — Apache-2.0, self-hosted, bot + real-time STT + speaker attribution + the agent/knowledge layer, running inside your perimeter with no egress: a bundled STT unit (GPU or CPU) means the audio path never calls out.
- Attendee — a source-available meeting-bot API (Django/Postgres/Redis) under the Elastic License 2.0, not an open-source license: ELv2 states “You may not provide the software to third parties as a hosted or managed service.” They also run a hosted cloud. Good software; the licence is the difference.
- MeetingBaaS — its bot,
meet-teams-bot, carries the same Elastic License 2.0 (© Spoke SAS) with the same limitation quoted above. The MIT repos around it — the MCP server, transcript viewer, speaking-bot examples — are satellites of the API, not the bot. They also run a hosted service. - Hosted bot APIs (e.g. Recall.ai) — mature and convenient, but your meetings transit their cloud; nothing to self-host.
Vexa vs. the alternatives
Jitsi is built and offline-proven, but not yet transcript-proven: live-room acceptance is open
(#570) and #883
reports a witness run on self-hosted Jitsi where audio recorded but the transcript came back empty.
Meet, Teams and Zoom are production. See Status.
Operability is the row most often argued with a number and no source, so here are ours. The
control plane is GPU-free and ships in three sizes: Lite (one app container, 13 supervised
programs inside it, plus two sidecars), compose (11 services by default, with Postgres, Valkey
and MinIO), and Helm (7 Deployments and 2 StatefulSets, requesting 1.55 vCPU / 4 GiB in
total before a meeting runs — 1.15 vCPU / 3 GiB if you bring your own datastores). Those counts are
commands, not claims:
docker compose config --services and helm template produce them on a clean
clone. make probe then runs the whole journey — spawn → join → transcribe → live-view → stop — in
nine stages with a per-stage verdict, against any of the three. What we do not ship: a backup or
DR procedure, an automated upgrade path, or a published hardware minimum for Lite and Kubernetes.
Those are real operator costs and they are enumerated, with the rest, on
Architecture review.
Or pay none of it. The hosted service is one authenticated POST /bots —
nothing to install, nothing to operate, no figure in this paragraph applies. Self-host when the
audio must stay inside your perimeter, or when you want the agent plane, which the hosted service
does not run.
Three operability figures circulate in this field, and we went looking for the source of each
without finding one. Recall.ai publishes that a self-hosted solution
requires 45-48% more time to operate.
Attendee’s README publishes that self-hosting
reduces costs by 10x compared to closed source vendors.
Skribby publishes that Vexa
requires significant DevOps expertise to set up.
No source accompanies any of the three. We are not answering them with a percentage of our own — we
have not run that study, and what is above is an inventory of what there is to run, not a
measurement of your hours.
Self-hosting is work. The question worth asking any vendor, this one included, is whether they will
tell you how much before you commit, in a form you can check without asking them.
Bring your own models covers both halves of the STT contract: the endpoint
(TRANSCRIPTION_SERVICE_URL) and the model id (TRANSCRIPTION_MODEL) — so backends that
validate the id (Groq, vLLM, OpenAI-compatible gateways) work end-to-end, not just backends that
ignore it. See Configuration.
No egress is the claim we can defend, and it is narrower than “air-gapped”. On Docker Compose
and Lite both halves of that STT contract are plumbed and the transcription unit ships in-tree
with GPU and CPU variants (deploy/transcription),
so the whole audio path can run with nothing leaving your network. On Kubernetes the chart does
not yet expose TRANSCRIPTION_MODEL as a value — you set it on the meeting-api and terminal
Deployments via extraEnv until it lands, which the chart’s own
known boundaries state. We have
not run an install on a genuinely disconnected network, so we do not claim one: what a procurement
review can hold us to is self-hosted with no egress, not a certified air gap.
Licence — Attendee is not the only ELv2 entrant here. MeetingBaaS’s bot carries the same licence
(above), so both licence rows describe it too. What that difference costs you depends entirely on
what you intend to do with the software, which is the next section.
What the licence difference actually means
A licence name is not an argument. Here is what each one lets you do. Apache-2.0 (Vexa) is OSI-approved. It grants a “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” copyright licence — and a patent licence on the same terms — to use, modify, sublicense and distribute the work (§2–§3). There is no field-of-use restriction: run it for anyone, build a product on it and sell that product, keep your changes private, grow without the terms changing. The obligations are mechanical — include a copy of the licence, keep the notices, mark the files you changed (§4). Elastic License 2.0 (Attendee, MeetingBaaS) is source-available, not OSI-approved. You may read, modify and run it. Its first limitation is the one that decides most cases:You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.Two more are easy to miss: you may not “move, change, disable, or circumvent the license key functionality”, and you may not “alter, remove, or obscure any licensing, copyright, or other notices of the licensor”. Which of those bites depends on what you are building:
If you self-host for your own company and nothing else, the licence is not your deciding factor —
including when we say it is. It starts deciding the moment the software reaches someone who is not
your own employee.
One forward-looking note, stated neutrally: licence changes are in practice one-way, so choosing a
dependency means inheriting its terms for the life of the integration. And this page is a reading of
the two licence files linked above, not legal advice — if you are embedding or reselling, that is a
question for your own counsel.
When to choose what — honestly
- Choose Attendee if you want only a capture API with the most conventional stack possible, you’re happy wiring your own transcription provider, and the knowledge/agent layer is something you’d rather build yourself — and you are not reselling it or embedding it in a service you offer to others, which ELv2 does not permit. It’s good software and the comparison keeps us honest.
- Choose a hosted API if your compliance posture allows a vendor cloud and you want zero operations. That’s a real trade — it’s just not the one this project exists for.
- Choose a local notetaker for personal note-taking on your own laptop with no IT involvement.
- Choose Vexa when the requirement is organizational and sovereign: every meeting platform, real-time attributed transcripts through an API you host, your STT and LLM endpoints, scaling from one Linux box to an OpenShift cluster inside your walls — and, when you want it, the agent layer that compounds those transcripts into a knowledge base your team owns.
make all prints a key when the stack comes up.
The deeper positioning discussion — why capture sits upstream of every “chat with your docs” tool —
is in Concepts. For the regulated-enterprise posture (no egress, procurement artifacts,
OSPS Baseline), see Security & compliance. If you are the one who has to
sign off on the dependency — where audio goes, what it costs to run, how it fails, what is not
certified — that is Architecture review.