By the end of this guide, you will have a MiroTalk P2P server running, and Tymeslot will create a separate room on it for every new booking.
Prerequisites
A server with Docker installed. A small VPS is enough, because a peer-to-peer server only connects participants and does not carry their video
A domain name pointing at the server, so you can serve MiroTalk over HTTPS. Browsers only allow camera and microphone access on HTTPS pages
Inbound TCP ports 80 and 443 open for the reverse proxy you set up in Step 2. MiroTalk itself listens on port 3000
MiroTalk P2P, not MiroTalk SFU
This guide covers MiroTalk P2P (also written as MiroTalkP2P or mirotalk-p2p). MiroTalk SFU is a separate product, built for large group calls that run through a central media server. Tymeslot works 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 in Tymeslot later:
Expected result: after the container starts, open
http://your-server:3000
in a browser. You should see the MiroTalk P2P landing page.
Never keep the default API key
The API key protects MiroTalk's REST API, which Tymeslot uses to create rooms. MiroTalk ships with a publicly known default key, so anyone could use the API on a server that keeps it. 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 only allow camera and microphone access over HTTPS, so calls do not work over plain HTTP.
Put a reverse proxy in front of MiroTalk's port 3000. Caddy obtains and renews TLS certificates for you:
After reloading Caddy, open
https://meet.yourdomain.com
. The MiroTalk landing page should load over HTTPS.
Nginx is also supported
Caddy is the quickest option because it handles certificates itself. If you prefer Nginx, set it up as a standard reverse proxy to port 3000 and manage certificates with Certbot.
3
Test MiroTalk Manually
Verify MiroTalk works independently before connecting it to Tymeslot:
Navigate to
https://meet.yourdomain.com
Enter any room name and join the room
The browser should ask for camera and microphone permissions
Allow them. The video room should open
If the room loads and the camera permission prompt appears, MiroTalk is working. Move on to Step 4.
Room loads but no audio or video?
If participants join but cannot see or hear each other, their browsers could not connect directly, usually because of a strict firewall or NAT on one side. Test from two different networks, and see TURN Server Setup below.
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.
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 gets its own MiroTalk room link.
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 introduces participants to each other
(WebRTC signalling); it does not relay video or audio. Video travels directly between participants'
browsers, so signalling traffic stays small and a basic VPS is enough. Bandwidth and resource needs
only grow noticeably if you run your own TURN server on the same machine.
TURN Server Setup (Optional)
Peer-to-peer WebRTC works for most home and mobile connections. Participants on strict corporate
or institutional networks may have direct connections blocked by a firewall or NAT. A TURN server
relays their audio and video instead.
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, point MiroTalk at it with the TURN_SERVER_URL,
TURN_SERVER_USERNAME
and
TURN_SERVER_CREDENTIAL
environment variables, and restart the container.
Do you need a TURN server?
Most setups do not. Add one only if particular participants keep failing to connect, typically people on strict corporate or university networks. A TURN server routes their video through your server, which raises your bandwidth use.
Without a TURN server, peer-to-peer WebRTC fails on restrictive networks. The call appears to connect, because signalling succeeds, but no audio or video comes through. A TURN server fixes this for those participants.
❓
Frequently Asked Questions
Why can't participants connect to each other in MiroTalk?
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. Joining the room (signalling)
succeeds, but no audio or video comes through.
The fix is 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, such as a separate VPS or a machine with another provider.
Two things must reach it: Tymeslot, which calls MiroTalk's API at its
Server URL
to create each booking's room, and your participants' browsers, which open the room.
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?
Tymeslot calls the MiroTalk API when a booking is confirmed to create that booking's room link. If
rooms are not found, first check that the Server URL
of your MiroTalk integration points to the right MiroTalk server, with the correct scheme and port.
Test connection
on the integration checks the address and the API key together.
Also verify that the API key stored in Tymeslot matches the
API_KEY_SECRET
value
your MiroTalk container was started with. With a mismatch, MiroTalk refuses to create rooms, and
bookings arrive without a working 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 and a different room URL structure. Pointed at a MiroTalk SFU server,
Tymeslot either fails to create rooms or produces links that do not work.
For large groups, choose another video provider that Tymeslot supports.
How many participants can join a MiroTalk P2P room?
MiroTalk P2P works well for 2 to 4 participants. Because it is peer-to-peer, each participant
sends their video and audio directly to every other participant. With 4 participants, each person
uploads 3 streams at once, and bandwidth and CPU use grow with every extra participant.
Beyond 4 participants, call quality and reliability drop. Larger groups are better served by a
platform that routes streams through a central media server, such as Jitsi Meet, Google Meet,
Zoom or Microsoft Teams, all of which Tymeslot supports.
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. Connects over OAuth. Use a paid plan (Pro, Business or Enterprise): Zoom applies its free-plan limits, including meeting length, to meetings created this way.
