What one InterMIND meeting is built from

Almost every product is built from the same default stack — the big proprietary SaaS defaults everyone reaches for. They're the frictionless path. At every layer where your meeting data actually lives, we took a different one: our own code, or open-source we could self-host.

This is the companion to Where one InterMIND meeting actually runs, which mapped the geography — where each service executes and what data passes through it. This post answers what a security team asks next: what is this thing built from — and can we read it, audit it, and replace it?

Not where it runs — what it's made of, layer by layer.

The defaults, and what they cost

Every product is a stack of choices. For most products, most of those choices are made by default: Google Analytics, Firebase, the Google Translate API, Auth0, React. They're the frictionless path, and for most teams that's a reasonable call. The trade-off is that each one puts a part of your stack behind a vendor you can't read, can't audit, and can't leave without a rewrite.

We made a different choice at every layer where your meeting data actually lives: our own code, or open-source software we could self-host. Where a layer doesn't touch the content of your meeting, we stay pragmatic and say so. Here's the whole picture.

The spine: the engine is our code, not a third party's

Start with the layer that matters most, because most of your meeting flows through it. Real-time transport and voice/chat translation both run on mind-sdk + the Mind API — our own engine, on OVH France. The default way to build a translated meeting is to bolt a real-time SaaS (LiveKit) onto a translation API (DeepL, Google); we run neither in the live path. No third-party translation model is in the loop. (We do use DeepL — but only for documents dropped into chat, not the live voice/chat path; see the runtime map. We covered the pipeline mechanics in Inside the four translation pipelines.)

Here's the part that isn't in the runtime map: the SDK your meeting runs on is open source under the BSD 3-Clause license — the mind-sdk client is public at gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, our Estonian IP entity. It speaks to the Mind API at api.mind.com, which we run ourselves on OVH France.

This isn't a "look, but don't touch" source-available arrangement. BSD 3-Clause is a permissive, OSI-approved license. Your security team can clone the SDK, read exactly how your audio and text are captured, framed, and streamed, and audit that integration against your own requirements. The server-side engine it talks to is ours — not a third party's black box — and a fully self-hostable engine for a tenant who needs it is on our roadmap, not something we offer today. We'll update this post the moment it ships.

Layer by layer: the default vs. what we run

Two threads run through that table. Open-source where the tool processes your data — so it can be audited, and in principle self-hosted. Open standards (Postgres, the S3 API, OIDC) where we depend on infrastructure — so nothing is locked to one vendor's pricing or compliance posture. Postgres can move to any Postgres host; storage can move to any S3 store; auth federates to the identity provider you already run. The last row sits on a third axis: the CRM holding customer records is EU-domiciled (Pipedrive, Estonian) rather than a US sales platform — not open-source, but not under US jurisdiction either.

A couple of these deserve a sentence more. PostHog is open-source and self-hostable; we run it on PostHog's EU cloud and proxy it first-party through our own origin, so the events aren't silently dropped by ad-blockers and don't transit a third-party analytics domain. Authentication never goes to a third-party auth SaaS that would sit between you and your sessions — we run the OIDC flow ourselves and federate to your existing Google or Microsoft identity. And the fonts on every page are served from our own domain; the only place Google Fonts appears in our codebase is an offline brand-asset script, never the app your users load.

Where we're pragmatic — said out loud

We don't pretend the whole stack is hand-rolled or non-US. It isn't, and a post that claimed otherwise would be contradicted by our own runtime map.

The plumbing — hosting and SSR (Vercel), the meeting server's compute (Fly.io), payments (Stripe), transactional email (Resend) — runs on US-domiciled SaaS. Stripe and Resend handle billing and invites and never see meeting content. Vercel and Fly are rented compute: our own code runs on them, and the meeting server on Fly does handle the live session and the transcript our digest reads — but that's our code on their machines, not a vendor product ingesting your meeting. All of it executes in the EU at runtime (the subject of the runtime map).

That's a deliberate, bounded trade-off: own and open-source the data plane; use the best available SaaS for the control plane. Naming it is the point — "sovereignty" means little if the exceptions aren't on the table next to the wins.

The AI steps, and the plan that shipped

The language-model steps — the AI digest (topics, decisions, action items), document summaries, the AI note-editor's generative actions, Ask AI and Mia — run on the AI gateway your organization selects: Azure OpenAI in the EU Data Zone by default, Vertex AI on the EU multi-region endpoint or Amazon Bedrock in Frankfurt by choice, each in our own tenant with zero data retention and no training on customer content — or your own OpenAI-compatible endpoint, which keeps the model on infrastructure you control. The post-meeting summary and the editor's translate action go through the translation tract, not the language model. Real-time voice, chat, notes, and documents never went near a general-purpose LLM in the first place.

That is the honest shape of this layer: the models are proprietary, and their vendors are US companies operating EU regions — the same trade-off as the plumbing above, stated next to it rather than hidden. What shipped instead of a self-hosted model of our own is the choice: an organization can turn AI off entirely (transcription and translation keep working), and it can point every AI feature at its own endpoint — vLLM in its own data centre, a deployment in its own tenant — which puts this layer on the same open-and-self-hostable axis as the rest of the data plane. Our public translation benchmark is scored by an LLM judge (Gemini, with Claude as fallback) on fixed FLORES-200 reference sentences — never anyone's meeting.

Why this matters beyond us

This isn't engineering for its own sake. The reason to build a stack this way shows up on your side of the contract:

1. Auditable. The SDK your meeting runs on is open-source code your security team can read, and the engine behind it is our own — not a third party's black box.
2. Portable. Open standards at every data layer — Postgres, S3, OIDC — mean no proprietary lock-in. What can be moved isn't tied to a single vendor.
3. Self-hostable. The open-standard data layers — Postgres, S3, OIDC — already run on infrastructure you control; a fully self-hosted translation engine is on the roadmap for the tenant who needs it.

This is the picture on 2026-06-07. We'll update it when the stack changes — a vendor swap, a layer rebuilt, the digest model replaced. The current configuration is verifiable in our open vercel.json, our nuxt.config.ts, and the BSD-3-Clause mind-sdk repository linked above.

If a layer here looks wrong, or your security review needs an answer this map doesn't give, write us. We'd rather correct a missing detail than have you find it in a code audit.

Sources: the mind-sdk repository (BSD-3-Clause), FLORES-200; stack facts verified against the deployed configuration (vercel.json, nuxt.config.ts) and the shipped code, checked August 2026.