One API coordinates identity, video, meetings, and workspace state.
The Node/Express server is the product control plane. Supabase owns identity and relational state, R2 holds media, workers finish asynchronous jobs, WebSockets coordinate meetings, and external providers supply billing, speech, translation, and SFU capabilities.
System map
Web, mobile, shares
Public pages, authenticated workspace, browser recorder, live meeting clients, public share player, and Expo mobile.
Express API
Authentication, tenant resolution, entitlements, validation, CSRF, rate limits, REST routes, meeting signaling, and signed delivery.
Supabase + R2
Postgres stores workspace and operational records. Supabase Auth owns users. R2 stores original media and generated derivatives.
Workers and integrations
Background processing, DNS checks, cleanup, summaries, media transforms, billing, SFU, speech, translation, email, and edge playback.
Runtime processes
API process
server.js builds Express middleware and routes, serves the product and support site, handles REST requests, accepts WebSocket upgrades, and exposes health/metrics.
Background worker
worker.js runs domain verification, expiry cleanup, media-processing dispatch/recovery, and resumable meeting-summary work with heartbeats and retries.
Edge and media workers
Cloudflare Workers authorize playback and serve media-origin responsibilities; external processing and LiveKit egress can create derivatives outside the API process.
Request lifecycle
Helmet, CORS, host checks, request IDs, logging, size limits, and route-specific rate limiters establish the boundary.
Secure cookies map to Supabase Auth. Authenticated handlers resolve active tenant membership and role before reading workspace data.
Zod schemas and route guards validate body, query, identifiers, entitlements, admin role, CSRF, and feature availability.
The route reads or writes Postgres, signs R2 access, calls Stripe/provider APIs, or publishes meeting/WebSocket state.
Structured logs, metrics, billing-event idempotency, audit rows, security events, job records, and provider status support diagnosis.
The API returns only fields appropriate for the current user, tenant, share-access cookie, host token, or superadmin permission.
Service ownership
Accounts and workspaces
- lib/supabase.js
- lib/tenant-service.js
- lib/workspace-policy.js
- lib/enterprise-identity-service.js
Plans and billing
- lib/entitlements.js
- lib/billing-service.js
- lib/appsumo-service.js
- lib/complimentary-plan-service.js
Storage and processing
- lib/r2.js
- lib/media-processing.js
- lib/background-jobs.js
- workers/media-origin
Realtime and intelligence
- lib/meeting-access.js
- lib/turn-credentials.js
- lib/meeting-summary-jobs.js
- lib/meeting-ai-provider.js
Admin and support
- lib/superadmin-service.js
- lib/superadmin-operations.js
- lib/superadmin-staff-service.js
- lib/support-knowledgebase.js
Runtime controls
- lib/env.js
- lib/db.js
- lib/rate-limiter.js
- lib/logger.js
- lib/metrics.js
- lib/errors.js
Meeting architecture
Room creation and configuration use REST. The live session uses /api/meetings/ws for admission, participant presence, mesh WebRTC signaling or SFU token delivery, chat, caption relay, recent event hydration, owner capture state, and time-limit enforcement.
The persisted meeting model complements—not replaces—the live room:
- In-memory state keeps latency-sensitive participant and signaling information close to the socket server.
meeting_rooms,meeting_participants, andmeeting_eventspreserve room identity, admission history, chat, captions, and control events where configured.- LiveKit-compatible SFU configuration replaces peer-to-peer mesh for scalable media without changing the public room contract.
- TURN credentials are short-lived and generated server-side; the shared TURN secret never reaches static configuration.
Storage and playback
R2 keys separate original uploads, processed WebM/MP4/HLS outputs, thumbnails, waveforms, duration metadata, manifests, versions, exports, and meeting egress artifacts. The API issues signed access or playback-gateway tokens; public clients never receive R2 credentials.
The playback gateway can sit in front of R2 to centralize authorization and caching. Custom domains affect public share and meet surfaces only; protected account and admin traffic stays on the primary application origin.
Deployment shape
- Hostinger VPS runs the Node API, background worker, and Caddy reverse proxy.
- GitHub Actions deploys the exact pushed GitHub ref into versioned release directories.
- Production deploys use
origin/main; staging deploys use an explicitly pushed branch or SHA and an isolated app/port. - Docker Compose owns optional meeting dependencies such as TURN and self-hosted speech services.
- Health, metrics, observability, backup, restore verification, acceptance, and staging-gate scripts live under
scripts/ops,scripts/security, anddocs/operations.