Self Hosting Overview

Meeting BaaS v2 supports self-hosted deployments, allowing you to run the platform in your own infrastructure with configurable feature flags. This gives you full control over your deployment while maintaining compatibility with the SaaS version.

What You Get

When you self-host Meeting BaaS v2, you receive:

Container Images: Pre-built Docker images for:
- API Server (used for both API server and background jobs)
- Zoom Bots (zoom-bots-v2)
- Meet/Teams Bots (meet-teams-bots-v2)
- Video Device Plugin (custom Kubernetes device plugin for v4l2 devices)
Helm Charts: Production-ready Kubernetes Helm charts via the kubernetes-config repository
Deployment Scripts: CLI tools for easy deployment and upgrades
Documentation: Complete setup and configuration guides

Deployment Architecture

Meeting BaaS v2 is designed to run on Kubernetes with the following components:

API Server: Handles API requests, authentication, and business logic
Background Jobs: CronJobs for scheduled tasks (bot creation, data retention, calendar sync)
Bot Pods: Scalable pods that join meetings and record them
Video Device Plugin: DaemonSet that provisions virtual video devices (v4l2loopback) for bots

Component Interaction

The following diagram illustrates how the API server, bot pods, and video device plugin interact:

How It Works:

API Server receives bot creation requests and enqueues jobs to SQS
Background Jobs (CronJobs) also create bot jobs in SQS for scheduled meetings
Bot Pods (auto-scaled via KEDA) consume jobs from SQS
Video Device Plugin (DaemonSet) runs on bot pool nodes and provisions virtual video devices (/dev/video*) that bot pods require
Bot Pods use the video devices to join meetings on Zoom, Google Meet, or Microsoft Teams
Bot Pods record meetings and upload recordings to S3
API Server manages all metadata in PostgreSQL and uses Redis for deduplication

Feature Flags

The platform uses feature flags to enable/disable functionality, making it easy to deploy only what you need:

Flag	Description
`SELF_HOSTED`	Enable self-hosted mode (simplified configuration)
`ENABLE_STRIPE`	Enable Stripe billing and token system
`ENABLE_SVIX`	Enable SVIX managed webhooks
`ENABLE_CALENDAR`	Enable Google/Microsoft calendar integration
`ENABLE_MULTI_TENANT`	Enable multi-tenant mode (teams, multiple users)
`ENABLE_DASHBOARD`	Enable frontend dashboard (BFF and internal routes)
`ENABLE_TRANSCRIPTION`	Enable Gladia transcription service
`ENABLE_EMAIL`	Enable Resend email notifications

All flags default to false, making minimal deployments straightforward.

Deployment Modes

Single-Tenant (Simplest)

Perfect for organizations that need a single team with unlimited usage:

Static API key authentication
No billing system
Direct webhook callbacks (no SVIX needed)
Single team with enterprise-level limits

Multi-Tenant

For organizations that need multiple teams and user management:

Team-based access control
User invitations and management
Per-team rate limits and quotas
Optional Stripe billing integration

With Dashboard

Add the frontend dashboard for a complete UI experience:

Web-based bot management
User authentication via OAuth
Team management interface
Usage analytics and monitoring

Quick Start

Review Prerequisites: Ensure you have the required infrastructure
Set Up Repository: Clone the Helm charts and create your environment overrides
Configure: Set up environment variables and feature flags
Deploy: Use the provided deployment scripts to install the platform
Upgrade: Use CI/CD-friendly upgrade process for updates

Next Steps

Prerequisites - Infrastructure and requirements
Infrastructure Setup - Set up your Kubernetes cluster and services
Repository Setup - Configure the Helm charts repository
Configuration - Configure feature flags and environment variables
Deployment - Deploy the platform
Upgrades - Keep your deployment up to date
Troubleshooting - Common issues and solutions

On this page