Set Up MiroTalk SFU and Publish It with Localtonet

What Localtonet publishes in this architecture

MiroTalk SFU provides browser-based rooms for real-time video, audio, screen sharing, chat, file sharing, whiteboarding, recording, and related collaboration features. Its mediasoup SFU receives participant media and selectively forwards streams to other participants. That architecture has more than one network path, so publishing the application cannot be treated like exposing a simple static website.

The first path is the MiroTalk application endpoint on TCP port 3010 in the documented default setup. It serves the landing page, room interface, application requests, and signaling connections. A Localtonet HTTP tunnel can make this endpoint available at a public HTTPS URL without inbound router port forwarding to port 3010.

The second path carries real-time WebRTC media. MiroTalk's current self-hosting example assigns TCP and UDP ports 40000 through 40100 to mediasoup. The application announces a public media address through SFU_ANNOUNCED_IP, and remote browsers must be able to reach the resulting ICE candidates. A working Localtonet web URL does not make these separate media listeners reachable automatically.

Prepare the MiroTalk SFU host

Choose a machine that can remain online throughout each meeting. An SFU forwards streams to multiple recipients, so CPU load, memory use, and especially outbound bandwidth increase with participant count, enabled video, resolution, bitrate, screen sharing, recording, and other features. MiroTalk provides rough planning estimates, but they are not capacity guarantees. Representative load testing is the only reliable way to size a production deployment.

MiroTalk's current repository says the project has been tested with Node.js 22.x and uses Ubuntu 24.04 LTS in its package example. Its detailed self-hosting page lists Ubuntu 22.04 LTS and Node.js LTS. For the direct installation in this guide, use Node.js 22.x as specified by the current repository and validate your chosen Ubuntu release against the current project instructions before deploying.

Choose one application installation path

The Node.js and Docker Compose sections are alternatives. Do not complete both against the same checkout and port unless you are intentionally building separate instances. Running both normally causes port conflicts because each tries to provide MiroTalk on port 3010 and may also compete for the configured mediasoup ports.

Host and network requirements

• A Linux host with administrative access for installing required packages.
• Git and a text editor.
• Node.js 22.x and npm for the direct installation, or Docker Engine and Docker Compose for the container installation.
• Build tools and Python required by project dependencies.
• FFmpeg when using functionality that depends on it, including optional RTMP workflows.
• A public IPv4 address or domain that remote participants can reach for the documented direct mediasoup media model.
• A firewall and upstream network that can pass the selected media ports.
• A Localtonet account and a device-specific authentication token for the client that will run the tunnel.

Install the shared Ubuntu packages

MiroTalk's detailed self-hosting guide provides the following package sequence. Review administrative commands before running them on an existing machine.

export DEBIAN_FRONTEND=noninteractive

apt-get update -y

apt-get install -y \
  build-essential \
  git \
  curl \
  wget \
  unzip \
  tzdata \
  software-properties-common \
  ffmpeg

add-apt-repository -y ppa:deadsnakes/ppa
apt-get update -y
apt-get install -y python3.8 python3-pip

These packages are relevant to the source installation. A container host still needs Git if you are cloning the repository, but the application runtime and its dependencies are packaged in the selected container image.

Plan where the Localtonet client will run

The simplest arrangement runs our client on the same host as MiroTalk. It can then target a loopback address on port 3010. The client may instead run on another device that can reach the MiroTalk host over a private network. In that arrangement, use the MiroTalk host's reachable private address rather than the client device's loopback address.

Configure MiroTalk before the first installation or start

The current MiroTalk self-hosting instructions explicitly direct operators to edit .env before running npm install or npm start. Apply the same configuration-first principle to Docker. Create and review .env, app/src/config.js, and the active Compose file before pulling and starting the container.

Start by cloning the repository. Perform this once for the installation method you selected:

git clone https://github.com/miroslavpejic85/mirotalksfu.git
cd mirotalksfu

cp app/src/config.template.js app/src/config.js
cp .env.template .env

Open both active files in your editor. Do not edit only the template files because the running application uses app/src/config.js and .env.

Set the production media environment

MiroTalk's current production example includes these values:

ENVIRONMENT=production
SFU_ANNOUNCED_IP=YOUR_PUBLIC_IPV4_OR_DOMAIN
SFU_MIN_PORT=40000
SFU_MAX_PORT=40100
SFU_NUM_WORKERS=4

Replace YOUR_PUBLIC_IPV4_OR_DOMAIN with the address through which remote browsers can reach the mediasoup media listeners. Do not insert the Localtonet HTTP hostname merely because it loads the web interface. That hostname represents the HTTP tunnel endpoint and is not automatically a route to the separate TCP and UDP media ports.

MiroTalk describes the 40000 through 40100 range as roughly supporting 50 participants and provides a rough estimate of about 100 participants per worker, depending on video quality, bandwidth, and system load. These figures are planning guidance, not guaranteed limits. A deployment can encounter bandwidth, CPU, memory, firewall, or participant-network constraints before reaching an estimated count.

Review application access controls

Inspect app/src/config.js and the security-related values in .env before public access. MiroTalk includes host protection, OIDC authentication, JWT credentials, room passwords, lobby controls, and spam mitigation. The exact active options and configuration keys can change with the project, so this guide does not invent settings that are not established by the supplied current evidence.

Decide who may create rooms, who may join them, and how administrative or host functions are protected. Test permitted and rejected access before sharing the public URL. A tunnel supplies connectivity. It does not replace MiroTalk's participant authorization or meeting controls.

Select and verify the origin scheme on port 3010

The repository quick start tells users to open https://localhost:3010. The current detailed production guide verifies the service at http://YOUR.DOMAIN.NAME:3010. These examples demonstrate two possible local origin schemes and must not be treated as interchangeable.

This tutorial selects MiroTalk's documented production origin form, plain HTTP on port 3010, for the Localtonet upstream connection. The Localtonet public side remains HTTPS. Bind port 3010 only where the Localtonet client can reach it, then target that HTTP origin from the tunnel.

The supplied MiroTalk evidence does not establish an additional mandatory public-origin variable specifically for a Localtonet URL. Do not invent one. After publishing, verify that the application does not redirect the public URL to localhost or to a private hostname and that room signaling remains connected. If your current MiroTalk release exposes an allowed-origin, trusted-proxy, external-URL, or proxy-header option, configure it according to that release's current documentation and retest.

Install and start MiroTalk with Node.js 22.x

Complete this section only if you selected the direct Node.js path. The configuration files must already exist and have been reviewed as described above.

Install Node.js 22 through Node Version Manager

MiroTalk's current repository directs users to install Node.js 22.x and npm with Node Version Manager. Install NVM through its current official installation method rather than copying an unverified bootstrap URL into a privileged shell. Open a new shell or load NVM according to its installer, then select Node.js 22:

nvm install 22
nvm use 22

node --version
npm --version

Confirm that node --version reports a 22.x release. If it does not, stop and correct the active runtime before installing dependencies.

npm ci

npm start

The repository's short quick start uses npm install, while the detailed self-hosting guide uses npm ci. This guide follows the detailed npm ci workflow for the checked-out repository and its lock file.

MiroTalk also documents an alternative listen-port invocation:

SERVER_LISTEN_PORT=3011 npm start

Continue with port 3010 unless you deliberately change it. If you select another port, use that same value for local verification and the Localtonet target. Changing the application port does not change the separate media-port requirements.

Install and start MiroTalk with Docker Compose

Complete this section only if you selected Docker. Do not also start the Node.js workflow on the same ports. Docker packages the application runtime, but it does not remove the need to configure the announced address, media listeners, firewall, or application controls.

Install and identify the available Compose command

MiroTalk's current self-hosting guide shows Ubuntu packages and uses the legacy hyphenated command:

sudo apt install -y docker.io
sudo apt install -y docker-compose

docker --version
docker-compose --version

Some current Docker installations provide Compose as the docker compose

docker compose version

Use one supported command form consistently. The examples below retain docker-composedocker-composedocker compose

cp docker-compose.template.yml docker-compose.yml

docker-compose pull

docker-compose up

After the first run succeeds, stop the foreground process normally and start it in the background:

docker-compose up -d

MiroTalk's documented Compose example uses network_mode: 'host', a restart policy of unless-stopped, and read-only mounts for .env, app, and public. Host networking allows the container to use the host's network stack. Do not replace it with arbitrary port mappings without understanding how the application and every mediasoup listener will be reached.

Verify MiroTalk locally before creating a tunnel

Local verification separates application failures from tunnel failures. A public tunnel cannot repair a process that exited, a syntax error in app/src/config.js, an invalid environment file, or an application that is not listening on the expected port.

Publish the MiroTalk web interface with Localtonet

Once MiroTalk works from the device that will run our client, create the HTTP tunnel. The Localtonet client establishes an outbound connection to a relay server. The Localtonet-only web workflow therefore does not require public inbound access to port 3010, router port forwarding for that port, a public IP address for the web origin, firewall changes for the web origin, or VPN setup.

HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types. All three publish the configured content at a public HTTPS address. Choose only a process type and option currently available in your dashboard. Plan and feature availability can vary, and exact custom-domain DNS instructions should come from the current dashboard rather than an article.

Refer to the Localtonet HTTP tunnel documentation while configuring the current dashboard. The exact labels displayed by the client or dashboard can change, but the required sequence remains: run and authenticate the client, choose the connected device and available relay, create the correct HTTP target, start the tunnel, and test the assigned URL.

Configure firewall, NAT, STUN, and TURN separately

The web tunnel and the media firewall serve different purposes. Do not open port 3010 publicly merely because MiroTalk's direct-server firewall example includes it. Localtonet reaches that origin through the client connection, so public inbound access to port 3010 is unnecessary for the Localtonet-only web path.

Localtonet web interface with direct public media

In this split design, port 3010 stays private while the mediasoup range remains directly reachable. If UFW is active and the range-based media configuration uses 40000 through 40100, the relevant MiroTalk media rules are:

ufw status
ufw allow 40000:40100/tcp
ufw allow 40000:40100/udp

Apply firewall rules only after confirming the correct interfaces, upstream firewall, administrative access, and organizational policy. A cloud firewall, router, carrier network, or NAT device can still block traffic even when the host firewall allows it.

Direct-public-server deployment

If you intentionally expose MiroTalk directly instead of using Localtonet for the web interface, MiroTalk's example also allows TCP port 3010:

ufw status
ufw allow 3010/tcp
ufw allow 40000:40100/tcp
ufw allow 40000:40100/udp

This is a different deployment model. A public browser service should normally use a proper hostname and HTTPS termination rather than asking users to visit an unencrypted port-based URL. Do not combine the direct rule with the Localtonet workflow unless there is a deliberate reason to maintain both access paths.

Optional WebRTCServer mode

MiroTalk documents an optional mode that uses one listening port for each worker:

SFU_SERVER=true

Each worker receives a WebRTCServer port beginning at 40000. This can reduce the exposed range and simplify firewall management. It does not remove the need for a reachable announced address or suitable NAT behavior, and it does not turn those media connections into HTTP tunnel traffic.

Why reachable SFU ports may still be insufficient

WebRTC uses ICE to choose a connection path. A participant behind ordinary NAT may be able to reach the SFU's announced public address directly. More restrictive participant networks can block UDP, permit only selected outbound ports, use symmetric NAT behavior, or interfere with direct ICE candidates. In those cases, an open SFU firewall does not guarantee that every browser can establish media.

STUN helps a WebRTC endpoint discover its public-facing network mapping. It does not relay media when a direct path is impossible. TURN provides a relay candidate and can carry media for participants that cannot use the available direct candidates. TURN therefore improves connectivity for restrictive networks, but it also becomes part of the media path and must be sized, secured, monitored, and made reachable.

Perform a meaningful external media test

• Open the Localtonet HTTPS URL from two independent devices.
• Place the devices on separate external networks, such as fixed broadband and a mobile connection.
• Confirm that each participant can join under the configured access policy.
• Confirm bidirectional audio, not just local microphone indication.
• Confirm bidirectional video, not just a local camera preview.
• Test screen sharing if it is required by the deployment.
• Repeat from a restrictive corporate, school, or guest network if those users are in scope.
• Inspect the active ICE candidate type with browser WebRTC diagnostics when direct tests work but restrictive networks fail.

Operate, troubleshoot, back up, and update the deployment

Operate the Node.js process with PM2

A foreground npm start process is useful for initial validation but stops when its terminal session ends. MiroTalk documents PM2 as an optional process manager:

npm install -g pm2
pm2 start app/src/Server.js --name mirotalksfu
pm2 save
pm2 startup

Read the output of pm2 startup. It may print an additional system-specific command that must be run with the displayed environment and permissions.

Routine PM2 operations include:

pm2 status
pm2 logs mirotalksfu
pm2 restart mirotalksfu
pm2 stop mirotalksfu
pm2 start mirotalksfu
pm2 save

Use pm2 status after a reboot and after every configuration change. Review logs before restarting repeatedly because a crash loop usually reflects a dependency, syntax, environment, permission, or port-binding problem.

Operate the Docker deployment

docker-compose ps
docker-compose logs
docker-compose logs -f
docker-compose restart
docker-compose stop
docker-compose up -d
docker-compose down

stop stops the containers while retaining the Compose deployment. down removes the Compose-managed containers and network resources, so use it only when that lifecycle action is intended. If your installation uses the Compose plugin, use the corresponding docker compose

The local page does not open

• Confirm that the selected Node.js process or Docker container is running.
• Review the startup output or logs for configuration and syntax errors.
• Confirm that you edited .env and app/src/config.js, not only their templates.
• Confirm that port 3010 is not occupied by another process.
• Use the correct origin scheme. An HTTP request sent to an HTTPS listener, or the reverse, will fail.
• For Docker, confirm that the active Compose file mounts the files you edited and uses the expected network mode.

The local origin works but the Localtonet URL fails

• Test the origin from the device that runs the Localtonet client.
• Verify that the client is connected with the intended device token.
• Confirm that the tunnel was started after it was created.
• Check the target scheme, IP address, and port together.
• If using HTTPS upstream, validate certificate trust and hostname matching.
• Check for redirects to localhost, a private IP address, or an unexpected scheme.
• Confirm that MiroTalk remains active while testing the tunnel.

The page loads but room signaling fails

This differs from a media-only failure. Confirm that the application is not rejecting the public origin, that access controls allow the test user, and that the browser remains connected to the application's signaling channel. Review MiroTalk logs and browser developer tools for rejected requests, redirect loops, authorization failures, and disconnected browser connections.

The room opens but there is no audio or video

• Confirm that SFU_ANNOUNCED_IP is reachable from the participant networks.
• Confirm that the announced value is not merely the Localtonet HTTP hostname.
• Verify that the active media range matches the host and upstream firewall rules.
• Check both UDP and TCP media reachability for the documented range-based setup.
• If SFU_SERVER=true is active, verify each required per-worker port beginning at 40000.
• Confirm that Docker networking has not changed which addresses and ports are reachable.
• Test with two separate external clients.
• Investigate TURN when failures occur only on restrictive NAT or filtered networks.

Camera or microphone permission is unavailable remotely

Open the application through the assigned Localtonet HTTPS URL rather than a plain HTTP public address. Browsers generally require a secure context for camera and microphone access on non-localhost origins. Also inspect the browser's site permissions and the operating system's privacy settings.

The tunnel disconnects

A Localtonet tunnel is available only while the selected client is connected and the tunnel is running. Check whether the host slept, rebooted, lost network connectivity, stopped our client, or stopped the tunnel. Then confirm that MiroTalk is still listening on its local port. Process supervision for MiroTalk does not automatically supervise the Localtonet client, and the reverse is also true.

Back up before changing or updating the installation

At minimum, preserve the active files that contain deployment-specific configuration:

• .env
• app/src/config.js
• docker-compose.yml for Docker deployments
• Any locally customized application, public, branding, certificate, or integration files
• The currently deployed source revision or container image identifier needed for rollback

Store backups outside the active checkout and protect any credentials they contain. A backup copied into the same directory can be overwritten, removed, or accidentally committed.

Update and rollback safely

MiroTalk publishes a dedicated updating guide, but the supplied evidence does not include its current exact command sequence. Release-specific migrations can change, so do not assume that a generic source pull or container pull is sufficient for every version.

Use this controlled update procedure:

1. Record the current source revision or container image identifier.
2. Back up all active configuration and customization files.
3. Read the MiroTalk changelog and updating instructions for the target release.
4. Schedule a maintenance period and stop new meetings.
5. Apply the documented update commands for the selected Node.js or Docker path.
6. Compare new templates with your active files rather than overwriting your configuration blindly.
7. Restart the process or Compose deployment and inspect logs.
8. Repeat local application, access-control, public URL, and two-client media tests.
9. If validation fails, restore the saved files and previous source revision or image according to your prepared rollback method.

For a Docker release whose current instructions confirm that pulling the configured image is sufficient, the operational commands normally include:

docker-compose pull
docker-compose up -d
docker-compose ps
docker-compose logs

Do not run these as an automatic update policy without preserving the prior image and configuration. An image tagged latest can change over time, which makes an unrecorded rollback difficult.

Post-update verification checklist

• The Node.js process or Docker container remains healthy after startup.
• The selected HTTP or HTTPS origin still responds on port 3010.
• The Localtonet client remains connected and the tunnel is running.
• The public HTTPS URL loads without redirecting to a private address.
• Host protection, room passwords, authentication, or lobby behavior still works as intended.
• Two external participants can join and exchange audio and video in both directions.
• Restrictive-network testing still succeeds through the intended ICE or TURN design.
• Stopping the Localtonet tunnel removes public access to the web interface.

Frequently asked questions