By the end of this guide, you will have a self-hosted MiroTalk P2P video server running, and Tymeslot will generate a unique MiroTalk room link for every new booking — with no third-party video infrastructure involved.
Prerequisites
A server with Docker installed — any VPS with 1 GB RAM or more is sufficient for signaling-only (peer-to-peer) load
A domain name or public IP address accessible from the internet — HTTPS is required for WebRTC to work in modern browsers
Firewall rules allowing inbound TCP port 3000 (MiroTalk web server) and inbound UDP ports 40000–57000
(WebRTC media streams) — both are required for calls to work
MiroTalk P2P — not MiroTalk SFU
This guide covers MiroTalk P2P (also written as MiroTalkP2P or mirotalk-p2p). Do not confuse it with MiroTalk SFU, which is a separate product designed for large group calls with a central media relay. Tymeslot integrates with P2P only.
1
Deploy MiroTalk P2P with Docker
Run the following command on your server. Replace
your-strong-random-key
with a strong secret — you will enter this key into Tymeslot later:
Expected result: after the container starts, open
http://your-server:3000
in a browser — you should see the MiroTalk P2P landing page.
The API key is not optional
Without an API key, anyone on the internet can create rooms on your MiroTalk instance. Always set
API_KEY_SECRET
to a strong random value before exposing MiroTalk to the internet.
2
Set Up a Reverse Proxy with HTTPS
Browsers require HTTPS to access the camera and microphone — WebRTC will not work over plain HTTP.
Set up a reverse proxy in front of MiroTalk's port 3000. Caddy handles TLS certificates automatically:
After reloading Caddy, open
https://meet.yourdomain.com
— the MiroTalk landing page should load over a secure connection.
Nginx is also supported
Caddy is the quickest option because it provisions TLS certificates automatically. If you prefer Nginx, configure it as a standard reverse proxy to port 3000 and use Certbot to manage certificates.
3
Test MiroTalk Manually
Verify MiroTalk works independently before connecting it to Tymeslot:
Navigate to
https://meet.yourdomain.com
Enter any room name and click Join
The browser should prompt for camera and microphone permissions
Grant permissions — the video room should open
If the room loads and the camera permission prompt appears, MiroTalk is working correctly. Move on to Step 4.
Room loads but no audio or video?
If the room connects but participants cannot see or hear each other, UDP ports 40000–57000 are blocked by your server's firewall. These ports carry WebRTC media streams. Open them in your firewall or security group rules before proceeding.
4
Connect MiroTalk in Tymeslot
Now register your MiroTalk instance with Tymeslot:
Go to Dashboard → Integrations → Video.
Click Connect a video provider
and choose MiroTalk P2P
under Self-hosted.
Give the integration a name if you want something other than the default.
In Server URL, enter your MiroTalk URL, for example
https://meet.yourdomain.com
In API Key, enter the key you set in
API_KEY_SECRET
Click Add Integration.
The provider picker. Choose MiroTalk P2P
under Self-hosted to enter your server URL and API key.
Expected result: the integration appears in your list of video integrations under the name you gave it (My MiroTalk
by default), with your server's host beside it. Tymeslot will now generate room links using your instance for every booking.
5
Enable MiroTalk on Meeting Types
MiroTalk is enabled per meeting type. Repeat for each meeting type where you want self-hosted video:
Go to Dashboard → Meeting Types and pick a meeting type.
On the Location & Calendar
tab, click Add location, or Edit
on an existing one, and set Type
to Video call.
Under Video providers, tick your MiroTalk P2P integration.
Click Save location.
Expected result: each new booking that uses this location will include a unique MiroTalk room URL. No manual room management is required — Tymeslot generates a fresh room link per booking.
You can tick several providers on the same location, for example MiroTalk alongside Google Meet or Zoom. The person booking then chooses which one the room is created on. See
Meeting Locations
for everything a meeting type's locations can do.
Resource Requirements
Because MiroTalk P2P is peer-to-peer, your server only handles WebRTC signaling — it does not relay
video or audio streams. Signaling traffic is minimal. A basic VPS with 1 GB RAM comfortably handles
hundreds of concurrent meetings. Video bandwidth goes directly between participants' browsers,
not through your server. Resource requirements only increase significantly if you later add a
TURN server for corporate network traversal.
TURN Server Setup (Optional)
Peer-to-peer WebRTC works for most home and mobile connections. However, participants on strict
corporate or institutional networks may have their P2P connections blocked by firewalls or NAT.
A TURN server relays media traffic for those users.
Coturn is the standard open-source TURN server:
apt install coturn
# Edit /etc/turnserver.conf — set your domain and credentials
# Then restart: systemctl restart coturn
After installing Coturn, add the TURN server credentials to MiroTalk's environment config and restart the container.
Do you need a TURN server?
Most users do not. Only add a TURN server if specific participants consistently fail to connect — typically users on strict corporate or university networks. A TURN server does route video traffic through your server, which increases bandwidth costs.
Without a TURN server, peer-to-peer WebRTC fails on restrictive networks. The call appears to connect (signaling succeeds) but no audio or video appears. Add a TURN server to cover these users.
❓
Frequently Asked Questions
Participants can't connect to each other in MiroTalk — why?
MiroTalk P2P uses WebRTC, which establishes a direct connection between participants' browsers.
This works for most home and mobile networks, but fails when participants are behind strict NAT or
corporate firewalls that block direct peer-to-peer UDP traffic. The signaling step (joining the room)
succeeds, but no audio or video appears.
The solution is to deploy a TURN server (such as Coturn) alongside MiroTalk. A TURN server relays
media traffic for participants who cannot establish a direct connection. See the
TURN Server Setup
section above for setup instructions.
Do I need to run MiroTalk on the same server as Tymeslot?
No. MiroTalk can run on any server — a separate VPS, a different cloud provider, or even a machine
on a different network. The only requirement is that your Tymeslot instance can reach MiroTalk's
HTTP API to generate room URLs at booking time. The Server URL
you enter for your MiroTalk integration must be reachable from the Tymeslot server,
not from participants' browsers.
Self-hosting Tymeslot on that same network is the exception.
A host that resolves to a private address is refused by default, as protection against
server-side request forgery. Set
ALLOW_PRIVATE_IPS_FOR_VIDEO=true
on your Tymeslot deployment to permit a meeting server on an internal network. This applies to
self-hosted installs only. On the managed service at tymeslot.app our servers have no route
to your network, so a private address cannot work there whatever you configure.
MiroTalk rooms show as 'not found' — what's wrong?
Room URLs are generated dynamically at booking time. Tymeslot calls the MiroTalk API with a unique
room ID for each confirmed booking. If rooms appear not found, first confirm that
MIROTALK_URL
in your
Tymeslot configuration points to the correct MiroTalk instance (including the correct scheme and port).
Also verify that the API key stored in Tymeslot matches the
API_KEY_SECRET
value
your MiroTalk container was started with. A mismatch causes room creation to fail silently, resulting
in a broken or missing room link.
Can I use MiroTalk SFU instead of MiroTalk P2P?
No. Tymeslot integrates with MiroTalk P2P only. MiroTalk SFU is a separate product
with a different API surface and a different room URL structure. Pointing Tymeslot at a MiroTalk SFU
instance will not work — room generation calls will either fail or produce invalid URLs.
If you need to support large groups, consider running MiroTalk P2P with a TURN server for reliability,
or evaluate a different conferencing solution that Tymeslot supports.
How many participants can join a MiroTalk P2P room?
MiroTalk P2P works well for 2–4 participants. Because the architecture is peer-to-peer, each
participant must send their video and audio stream directly to every other participant. With
4 participants, each person is uploading 3 streams simultaneously — bandwidth and CPU usage
grows with the number of peers.
For group calls with more than 4 participants, the quality and reliability of a pure P2P setup
degrades. MiroTalk SFU (a separate product) or a dedicated conferencing platform is better suited
for larger groups, as a central media relay handles stream distribution.
Verification Checklist
Book a test appointment on a meeting type with a MiroTalk video call location (choosing MiroTalk if you are offered a choice), then confirm each of the following:
On Dashboard
→ Meetings, the booking shows a Join Meeting
button that links to a room on your MiroTalk server
The booking confirmation email contains the same MiroTalk room link
Opening the room link in a browser loads the MiroTalk P2P interface and prompts for camera and microphone permissions
Joining the room from two separate browser tabs shows live video in both
Auto-create Google Meet rooms for every confirmed booking via the Calendar API. Attendees receive the link by email and can join without a Google account.
Auto-create Microsoft Teams meetings for every confirmed booking. Covers the Graph permissions Tymeslot asks for, when a tenant admin has to consent, and what happens when an account cannot host meetings.
Auto-create Zoom meetings for every confirmed booking. Works with Zoom Pro, Business, and Enterprise accounts via OAuth — free Zoom accounts cannot create meetings programmatically.
