← Back Security & Architecture
Last updated: September 17, 2026
This page describes the technical architecture of MonkeyThorn Meet
so you can evaluate whether it meets your security requirements.
Encryption
| Transport encryption | TLS 1.3 for all HTTP/WebSocket connections. DTLS-SRTP for all WebRTC media. |
| End-to-end encryption | AES-GCM via WebRTC Encoded Transform (Insertable Streams). Enabled by default using a passphrase in the URL fragment (never sent to server). Requires Chrome/Edge 90+, Firefox 117+, or Safari 15.4+. |
| Key exchange | Passphrase-based. The passphrase is included in the invite link's hash fragment, which browsers do not transmit over the network. |
| Server access to media | When E2EE is active, the server relays encrypted frames it cannot decrypt. Without E2EE, the SFU has access to unencrypted media for routing purposes only: it does not store or process it. |
Infrastructure
| Hosting | AWS EC2, US East (N. Virginia). Dedicated instance: not shared with other services or tenants. |
| Media server | LiveKit: open-source WebRTC Selective Forwarding Unit (SFU). No proprietary media processing. |
| TLS certificates | Issued by Let's Encrypt, managed and renewed automatically by Caddy. |
| Recording capability | Not installed. LiveKit supports recording via its Egress service, but we do not deploy it. There is no mechanism to record calls. |
| AI/ML processing | No server-side AI/ML processing. No transcription, sentiment analysis, or model training services are deployed or connected. Client-side noise suppression (Krisp) runs locally in the browser via WebAssembly and does not send audio data to any external service. |
Data Flow
- Your browser connects to our server via HTTPS to get a session token (JWT).
- Your browser establishes a WebSocket connection to the LiveKit server for signaling.
- Media (audio/video) flows via WebRTC directly to the SFU over DTLS-SRTP.
- With E2EE enabled, media frames are encrypted in your browser before being sent. The SFU forwards the encrypted frames without decryption.
- When the call ends, room state is discarded. Call content is never written to disk. For paid accounts, connection duration is kept for billing, as listed below.
What the Server Knows
| Your IP address | Visible during the connection (required for WebRTC). Not logged beyond standard infrastructure operation. |
| Room existence | The server knows a room exists while it has active participants. Room names are random 9-character codes. |
| Participant count | The server knows how many participants are in a room (required for routing media). |
| Call duration | For paid accounts, connection duration is tracked for billing. For free tier, not tracked server-side. |
What the Server Does Not Know
- Your name (display names are not logged)
- Who you called (participant identities are not logged)
- What you said (media is not processed or stored)
- What you typed in chat (data channels are not logged)
- Your E2EE passphrase (URL fragments are never transmitted)
Third-Party Dependencies
- LiveKit (open source, Apache 2.0): Media routing
- Stripe: Payment processing only
- Redis: In-memory room state used by LiveKit (no persistent storage)
- Caddy: Reverse proxy and TLS termination
- Cloudflare: DNS, email routing, and transactional email delivery (access code emails only)
No analytics SDKs, no tracking scripts, no external fonts, no CDN
dependencies beyond what is bundled in the application.
Vulnerability Reporting
If you discover a security vulnerability, please email support@monkeythorn.com.
We will respond within 48 hours.