Frequently Asked Questions

MiroTalk is an open-source, self-hosted suite of WebRTC-based applications for real-time video conferencing, live broadcasting, and communication. It includes multiple products designed for different use cases — from one-on-one calls to large-scale meetings and live streaming.

• 🏆 MiroTalk SFU — Group video conferencing (large meetings, webinars)
• 🚀 MiroTalk P2P — Peer-to-peer video calls (small groups)
• ✨ MiroTalk C2C — Client-to-client cam-2-cam communication
• 🎲 MiroTalk RND — Random one-to-one video matching
• 📡 MiroTalk BRO — One-to-many live broadcasting
• 🟢 MiroTalk CME — Instant click-to-call video calls
• 🛠 MiroTalk WEB — Meeting room scheduler and manager
• ⚙️ MiroTalk ADMIN — Centralized dashboard to manage all instances

See the ecosystem overview for how the products fit together, or the story behind MiroTalk.

WebRTC (Web Real-Time Communication) is an open-source technology that enables real-time audio, video, and data communication directly in web browsers without requiring plugins or additional software. MiroTalk is built entirely on top of WebRTC.

• Mesh (P2P): Each participant connects directly to every other participant. Low latency but bandwidth and CPU usage grow with more participants. Best for 2–4 users.
• SFU (Selective Forwarding Unit): A central server receives all streams and selectively forwards them to participants. Reduced bandwidth per participant, ideal for 5+ users.
• MCU (Multipoint Control Unit): The server mixes all streams into a single composite stream. Most resource-intensive on the server side.

See Compare architectures for a detailed side-by-side comparison.

MiroTalk is open source and self-hosted, so you control your servers, data, branding, and costs. Hosted services such as Zoom, Google Meet, and Whereby run on the provider's infrastructure.

• MiroTalk vs Zoom, Google Meet, Teams, Whereby & Jitsi: overview of all alternatives
• MiroTalk vs Zoom
• MiroTalk vs Jitsi Meet
• MiroTalk vs Whereby Embedded

For large group calls and scalability, choose SFU. For lightweight, low-latency small calls, choose P2P. For random one-to-one matching, choose RND.

Not sure yet? Use the interactive product chooser or see the ecosystem overview.

Product pages: SFU, P2P, C2C, RND, BRO, CME, WEB, ADMIN.

MiroTalk SFU supports both vertical and horizontal scaling:

Vertical Scaling (Single Server):

• 4-core CPU: ~400 users
• 8-core CPU: ~800 users
• 16-core CPU: ~1600 users
• Formula: numWorkers × ~100 users

Horizontal Scaling (Multiple Servers):

• Multiple SFU servers behind a load balancer (Nginx/HAProxy)
• Uses consistent hashing on room parameters for sticky sessions
• Example: 3 servers × 800 users = 2400+ total users

Yes. MiroTalk BRO supports both P2P and SFU broadcasting modes.

• P2P (default) uses direct peer-to-peer WebRTC connections and works best for small audiences.
• SFU routes media through a built-in mediasoup server and is better suited for larger broadcasts and 100+ viewers, depending on server capacity and network setup.

For large-scale broadcasts, use MiroTalk BRO in SFU mode. See the MiroTalk BRO page for details.

MiroTalk WEB is a browser-based meeting room scheduler that lets you organize and manage meetings. It integrates links to all MiroTalk products, uses a MongoDB backend for storing meeting/room data, and optionally supports email verification. Default port: 9000. See the MiroTalk WEB page for details.

MiroTalk ADMIN is a centralized dashboard for managing all your MiroTalk instances. It supports:

• Starting, stopping, and restarting services
• Updating all products
• Editing configurations
• Managing via SSH, Docker, or PM2

See the MiroTalk ADMIN page for details.

MiroTalk supports multiple deployment methods:

1. Manual (Node.js): Clone the repo, configure .env and config.js, run with npm start. Recommended OS: Ubuntu 22.04 LTS.
2. Docker / Docker Compose: Pre-built images on Docker Hub. Recommended for production.
3. PM2 Process Manager: Keeps services running with auto-restart on failure.
4. Cloudron: One-click deployment with automatic updates and backups.
5. Bash Scripts: Automated install/uninstall/update scripts available for each product.

Yes. For a clean Ubuntu 22.04 / 24.04 LTS server with root access and a domain pointing to its public IPv4, ready-made install, update and uninstall scripts are available for:

• MiroTalk: SFU, P2P, C2C, RND, BRO, WEB, CME
• Extras: Coturn, Whisper, RustDesk

Example (MiroTalk SFU):

wget -qO sfu-install.sh https://docs.mirotalk.com/scripts/sfu/sfu-install.sh \
  && chmod +x sfu-install.sh \
  && ./sfu-install.sh

When prompted, enter your domain or subdomain and wait for the installation to finish. RustDesk is the exception: no domain is needed, since the server public IP is detected automatically. See the Setup Guide for all scripts.

• OS: Ubuntu 22.04 LTS (recommended)
• Runtime: Node.js LTS + npm
• SFU additional: Ports 40000-40100 (TCP & UDP) for media traffic
• Reverse proxy: Nginx or Apache with SSL (Let's Encrypt via Certbot)
• TURN server: Recommended for production (coturn)

Default ports:

Each MiroTalk product provides a docker-compose.yml template. For SFU, note that network_mode: 'host' is required for optimal WebRTC performance. Pull the pre-built images from Docker Hub, configure your .env file, and run:

docker-compose up -d

Refer to the Docker Compose utility page for details.

Yes. MiroTalk supports Cloudron for one-click deployment with automatic updates, backups, and integrated user management. See the Cloudron guide for setup instructions.

Configure Nginx or Apache as a reverse proxy to:

• Run MiroTalk on any port while accessing it without a port number
• Enable SSL/TLS encryption (via Let's Encrypt / Certbot)
• Support WebSocket connections (required for signaling)
• Enable HTTP/2 for better performance

Each product's self-hosting guide includes sample Nginx configuration.

• STUN (Session Traversal Utilities for NAT): Discovers your public IP and port to help establish direct peer-to-peer connections. It does not relay media traffic.
• TURN (Traversal Using Relays Around NAT): Acts as an intermediary to relay media traffic when a direct connection fails (e.g., behind restrictive firewalls or symmetric NATs).

For production deployments, a TURN server is recommended to ensure connectivity for all users. See the STUN & TURN guide for more details.

Coturn is the recommended open-source STUN/TURN server:

1. Install coturn on your server (Docker or manual installation)
2. Obtain an SSL certificate (Let's Encrypt / Certbot)
3. Configure /etc/turnserver.conf with your domain, credentials, and ports
4. Secure it by blocking private IPs, using strong credentials, and running as a dedicated user

Ports used:

• STUN: 3478 (UDP/TCP)
• TURNS: 5349 (TLS-encrypted)

All MiroTalk products use two main configuration files:

1. config.js — Non-sensitive settings: application behavior, features, branding, API settings.
2. .env — Sensitive credentials: API keys, secrets, database URLs. Stored in .gitignore.

Refer to each product's configurations page for available options.

Key .env settings for MiroTalk SFU:

ENVIRONMENT=production
SFU_ANNOUNCED_IP=Your_Server_IP_or_Domain
SFU_MIN_PORT=40000
SFU_MAX_PORT=40100
SFU_NUM_WORKERS=<CPU_core_count>
SFU_SERVER=true
API_KEY_SECRET=your_secret

Ensure firewall rules allow:

• Port 3010/TCP (HTTP/signaling)
• Ports 40000-40100 (TCP & UDP, RTC media)

Yes. All MiroTalk products expose a REST API with endpoints such as:

• /api/v1/stats — Get active rooms and user count
• /api/v1/meetings — List active meetings
• Swagger docs at /api/v1/docs

Authentication uses an API_KEY_SECRET header. Code examples are provided in JavaScript, PHP, Python, and Bash.

MiroTalk supports multiple integration methods:

Simple iframe:

<iframe
  allow="camera; microphone; speaker-selection; display-capture; fullscreen; clipboard-read; clipboard-write; web-share; autoplay; picture-in-picture; screen-wake-lock"
  src="https://your-domain.com/newroom"
  style="width: 100vw; height: 100vh; border: 0px;">
</iframe>

IframeAPI: Full programmatic control with JavaScript.

Widget.js: A support-style widget with drag, online status, and custom headers.

Configurable parameters include: room, name, avatar, audio, video, screen, chat, hide, notify, token.

See each product's integration page for details.

Yes, MiroTalk SFU supports RTMP streaming to platforms like YouTube, Twitch, and others. Two server options are available:

1. Node Media Server — With admin dashboard and API
2. Nginx RTMP — Lightweight option

Both require FFmpeg. See the RTMP guide for setup.

Yes. MiroTalk SFU supports consent-based remote control powered by RustDesk. MiroTalk only brokers the handshake (RustDesk ID + one-time password); the remote session itself runs through the RustDesk clients and your own self-hosted RustDesk server. No MiroTalk code changes are needed.

Setup overview:

1. Deploy the RustDesk server (hbbs + hbbr) with Docker, or use the automated rustdesk-install.sh script (no domain required).
2. Open the firewall ports: 21115-21119/tcp and 21116/udp (plus 21114/tcp for Pro).
3. Configure every RustDesk client (presenter and participant) with the same ID/Relay server and public key (id_ed25519.pub).
4. Enable it in the SFU .env and restart MiroTalk:

REMOTE_CONTROL_ENABLED=true
REMOTE_CONTROL_DOWNLOAD_URL=https://your-domain/rustdesk-download

Usage: the presenter opens the participants menu and selects Remote control, the participant accepts and shares their RustDesk ID + one-time password, then the presenter clicks Open RustDesk and enters the password.

Keep the RustDesk data volume, because deleting it changes the key and breaks all configured clients. See the RustDesk + SFU Remote Control guide.

Yes, as an experimental feature. The built-in SIP phone panel (Settings → SIP phone) lets you register SIP users inside a room and place extension-to-extension calls. It is compatible with most SIP servers exposing WSS (WebSocket Secure) transport, such as Kamailio, Asterisk, FreeSWITCH, and OpenSIPS. A Docker-based Kamailio demo is included in the SFU repository. See the SIP phone guide.

Host Protection adds authentication to your MiroTalk rooms:

• HOST_PROTECTED=true — Require login to create rooms
• HOST_USER_AUTH=true — Require login for all participants
• JWT tokens for direct room access (configurable expiration, default: 1 hour)

See the host protection guides for P2P and SFU.

Yes. MiroTalk can send HTTP POST notifications to a configured endpoint on events such as:

• join — A user joins a room
• disconnect — A user leaves a room

The payload includes event type and relevant data in JSON format. See the webhook guides for P2P and SFU.

Yes, rebranding is available with a Regular or Extended license:

• HTML Injection mode: Customize text and labels via config.js
• Full customization: Edit frontend files directly (landing page, room pages, Open Graph tags)

See the rebranding guides for P2P and SFU.

Yes. Both the Regular and Extended licenses allow you to keep your source code private.

Yes, when purchasing MiroTalk ULTIMATE, which includes all MiroTalk projects. Purchases of individual products cover only that product.

MiroTalk offers three licensing tiers:

Pricing by product:

See the Licensing Options page for full details.

MiroTalk SFU supports room passwords via the roomPassword URL parameter:

https://YOUR-DOMAIN-NAME/join?room=test&roomPassword=MySecret123

Set roomPassword=0 to disable password protection. When a password is set, participants must enter it before joining the room.

See the join room guides for SFU for details.

Yes. Use the duration URL parameter when joining a room:

https://YOUR-DOMAIN-NAME/join?room=test&duration=01:00:00

• Format: HH:MM:SS (e.g., 01:30:00 for 1 hour 30 minutes)
• Set to unlimited for no time limit

When the duration expires, the session ends automatically. Available in both SFU and P2P.

Both SFU and P2P support a full set of URL parameters for customizing the join experience:

See the join room guides for SFU and P2P.

MiroTalk SFU supports horizontal scaling using multiple servers behind a load balancer (Nginx or HAProxy) with consistent hashing on the room parameter for sticky sessions.

Architecture:

            Load Balancer (Nginx/HAProxy)
                       |
        ┌──────────────┼──────────────┐
        |              |              |
     SFU #1         SFU #2         SFU #3
    ~800 users     ~800 users     ~800 users

Key configuration (Nginx):

upstream mirotalk_backend {
    hash $arg_room consistent;  # Same room → same server
    server 1.1.1.1:3010 max_fails=3 fail_timeout=30s;
    server 2.2.2.2:3010 max_fails=3 fail_timeout=30s;
}

Hash strategy matters:

• hash $arg_room consistent — Hashes only the room query param. Recommended.
• hash $uri consistent — Hashes only the path. Fails for query-string URLs.
• hash $request_uri consistent — Hashes the full URI. Users with different names in the same room may land on different servers.

See the Scalability guide for full details.

Each participant requires 2 ports (one for audio, one for video). The default port range 40000-40100 provides ~50 ports, supporting approximately 50 concurrent participants across all rooms on that server.

For larger deployments, expand the range:

SFU_MIN_PORT=40000
SFU_MAX_PORT=49999

Ensure your firewall allows the full range on both TCP and UDP.

When updating MiroTalk, custom files (branding, views) may be overwritten. Three strategies to preserve your changes:

Option 1: git stash (small edits)

git stash push -m "My branding changes"
git pull
git stash pop

Option 2: Custom branch (ongoing customizations)

git checkout -b custom-branding
# Commit your changes, then on update:
git checkout main && git pull origin main
git checkout custom-branding && git merge main

Option 3: Docker volumes (Docker deployments)

volumes:
  - ./custom/views:/app/public/views

Also check for changes in .env and config.js after each update. See the update guides for SFU and P2P.

Use PM2 (Process Manager) with auto-startup:

npm install -g pm2
pm2 start app/src/server.js --name mirotalk
pm2 startup
pm2 save

pm2 startup generates a system service that automatically restarts your MiroTalk processes on boot. Each product's self-hosting guide includes PM2 setup instructions.

Yes. The in-room UI of MiroTalk SFU and MiroTalk P2P can be shown in many languages, and MiroTalk CME has its own built-in translations.

SFU and P2P include English, Spanish, French, German, Italian, Portuguese, Russian, Ukrainian, Polish, Chinese, Japanese, Korean, Arabic, Hindi, Turkish, Vietnamese, Thai, Indonesian, Hungarian, Serbian, and more. P2P switches Arabic, Urdu, and Persian to right-to-left automatically.

Choose how translations are applied with the translation mode:

• google (default): uses Google Translate and ignores the native files.
• auto: uses the native language file when available, otherwise Google Translate.
• native: uses native files only. Missing translations stay in English.

Set the default language and mode as follows:

• SFU: UI_LANGUAGE and UI_TRANSLATION_MODE in .env.
• P2P: brand.app.language and brand.app.translationMode in app/src/config.js.

Users can also change the language and the mode in a room from Settings > Language. The choice is saved in the browser.

To add a language, copy en.json to <code>.json, translate the values, and register it in LANG_DISPLAY. Run npm run lang to keep the files in sync after UI changes.

MiroTalk CME detects the browser language automatically, remembers it in localStorage, and lets users switch language from the settings panel.

See the SFU, P2P, and CME i18n guides for details.

Yes. MiroTalk WEB uses MongoDB to store meeting and room data. Two deployment options:

Local (Docker):

npm run mongo:up    # Start MongoDB container
npm run mongo:down  # Stop MongoDB container

Cloud (MongoDB Atlas):

Update the credentials in .env:

MONGO_URL=mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOST}:${MONGO_PORT}
MONGO_DATABASE=mirotalk

See the MiroTalk WEB self-hosting guide for setup.

Yes. Email verification is disabled by default. To enable it, set EMAIL_VERIFICATION=true in .env and configure SMTP settings:

EMAIL_VERIFICATION=true
EMAIL_HOST=yourEmailHost
EMAIL_PORT=yourEmailPort
EMAIL_USERNAME=yourEmailUsername
EMAIL_PASSWORD=yourEmailPassword
EMAIL_FROM=yourEmailFrom

See the MiroTalk WEB self-hosting guide for details.

Key hardening recommendations for your coturn server:

• Block private IP ranges using denied-peer-ip (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Enable TLS with strong cipher lists on port 5349
• Use strong credentials with lt-cred-mech
• Set no-multicast-peers and no-loopback-peers
• Limit quotas with user-quota and total-quota
• Run as a dedicated user (avoid running as root in production)

See the Coturn Security Configuration Guide for in-depth recommendations.

1. Browser permissions: Ensure the browser has granted camera and microphone access.
2. HTTPS: WebRTC requires a secure context (https:// or localhost). Make sure your server has a valid SSL certificate.
3. TURN server: If connections fail behind firewalls or NATs, configure a TURN server (coturn recommended).
4. Firewall rules: Ensure the required ports are open (signaling port + media port range for SFU).
5. Browser compatibility: Use a modern browser (Chrome, Firefox, Edge, Safari).

This almost always means the media ports are unreachable. In SFU, the reverse proxy (Nginx, Nginx Proxy Manager, Traefik, Cloudflare) only carries signaling on port 3010. Audio/video goes directly between the browser and the SFU on the SFU_MIN_PORT-SFU_MAX_PORT range.

1. SFU_ANNOUNCED_IP: Set it to the server public IPv4 (or a non-proxied domain), not a Docker/LAN IP.
2. Open the ports: 40000-40100 TCP and UDP in the host firewall, cloud security group, and router.
3. Docker networking: Use network_mode: 'host' (Linux) or publish 3010/tcp and 40000-40100/tcp+udp with ports:. The range must match .env.
4. Reverse proxy: Terminate SSL at the proxy and forward to http://<host>:3010 with WebSockets enabled. Set TRUST_PROXY=true and SERVER_HOST_URL=https://your.domain. Don't proxy the media ports.
5. Cloudflare: Don't proxy the SFU_ANNOUNCED_IP domain (use DNS-only), because Cloudflare doesn't forward WebRTC media.
6. TURN: Not required for SFU to work. Add coturn only for users behind restrictive firewalls.

See the SFU self-hosting guide for full Docker examples.

Manual installation:

git pull
npm ci

Docker:

docker-compose pull
docker-compose up -d

Scripts: Use the provided update scripts (e.g., sfu-update.sh, p2p-update.sh).

MiroTalk ADMIN: Use the centralized dashboard to update all instances at once.

Use ngrok to create a secure tunnel from your local machine to a public HTTPS URL:

ngrok http 3000

This is useful for development, webhook testing, and sharing demos. See the Ngrok guide for setup.