edumeet WebRTC meetings with Docker and mediasoup

edumeet for self-hosted multiparty meetings

edumeet addresses the need for a browser-based meeting service controlled by the organization that operates it. Its documented features cover the common parts of an online meeting: microphone and camera streams, an additional video stream, screen sharing, text chat, file sharing, and local browser recording. The README lists authentication through OIDC, SAML, or a local database, which makes the service relevant to institutions that already depend on an identity provider or need a local account store.

The project is not merely a client application. The repository contains a client, a room server, a proxy configuration, certificate handling, and Docker Compose orchestration. The service description and repository topics identify mediasoup and WebRTC as its media foundation. That places edumeet among multiparty media systems in which browsers handle media capture and real-time communication while server-side components coordinate rooms and connectivity.

The intended operators extend beyond application developers. Someone must prepare a server, point DNS records at it, expose web traffic, manage certificates, and choose the authentication and client settings. A team evaluating whether it can operate a meeting service should inspect this deployment surface before focusing on individual meeting controls. The degree of control is also a cost: infrastructure decisions are part of adopting edumeet.

edumeet's Docker service topology

The checked-in `docker-compose.yml` shows several cooperating services. The `proxy` service uses `nginx`, publishes `80:80/tcp`, `443:443/tcp`, and `443:443/udp`, and links the room server and client. Its command substitutes `MAIN_DOMAIN`, `MEDIA_DOMAIN`, and `LISTEN_IP` into the Nginx template before starting Nginx and reloading it periodically. This places the proxy at the public HTTP and HTTPS boundary.

The `certbot` service runs the `certbot/certbot` image and periodically executes `certbot renew`. Its certificate and web-root data are mounted from `./certbot/conf` and `./certbot/www`. The proxy mounts the same locations, connecting certificate management to public traffic handling.

The `turn` service uses `coturn/coturn` with host networking. The Compose file configures it with `EXTERNAL_IP`, `LISTEN_IP`, `MEDIA_SECRET`, a media realm, authenticated TURN operation, and a port range from `50000` to `60000`. That range differs from the README's recommended connectivity range of `40000-40249`. Operators should resolve that discrepancy against the deployed Compose file rather than assume both sources describe the same firewall plan.

The `edumeet-client` service exposes host port `8080` to container port `80` and mounts `./client` as `/app/config`. The `edumeet-room-server` service mounts `./room-server` at `/usr/src/app/config` and sets `TEMPLATE_REPLACE=true`. These mounts make local configuration part of the deployment. The README also lists media-node and management-server images, so a complete deployment may span more services than the abbreviated Compose section shown in the repository file.

Media, files, and identity in edumeet

The feature table describes media flow at the user level rather than documenting the internal signaling protocol. Participants can share a microphone and camera, add a second video stream, and send screen content from a desktop. The service also supports local recording of a window, tab, or screen with room audio. Recording is disabled by default, which is an important operator decision because it affects both client configuration and user expectations.

File sharing uses a torrent solution underneath the browser interface, according to the README. That detail matters when reviewing network and security requirements because file transfer is not described as a conventional upload to the room server. The README does not specify retention, access control, size limits, or behavior when peers cannot reach one another. An organization that requires centrally governed files with predictable retention needs answers beyond this feature list.

Authentication is handled separately from meeting media. The documented options are OIDC, SAML, and a local database. The README does not provide a complete identity-provider setup in this repository, so it would be incorrect to infer exact claims, callback URLs, user provisioning behavior, or group mapping rules. It directs operators to the `edumeet-client` and `edumeet-room-server` repositories for configuration-property examples.

This separation offers deployment flexibility, but it means that meeting access depends on more than starting the media containers. Identity configuration, room behavior, client settings, and reverse proxy setup need independent verification.

Installing edumeet with the first-run script

The README lists Docker, `docker-compose`, and Curl as prerequisites. For internet access, it requires a public IP address, two FQDNs pointing to that address, open ports `80/tcp` and `443/tcp`, and recommended connectivity ports `40000-40249/udp` and `40000-40249/tcp`. The Compose file also exposes host port `8080` for the client and configures TURN ports `50000` through `60000`, so the firewall plan must account for the checked-in deployment.

Start with the repository's first-run script:

./run-first.sh

The script asks for a main domain, a media domain, an email address for certificates, the server listen IP, and the external IP. An email address can be left empty when certificate notification mail is not wanted. It prepares certificates and services, reads existing values from `.env`, and can use those values on later runs. Deleting `.env` starts configuration from scratch.

Start the services after the script has prepared the deployment:

docker-compose up -d

The README says this starts the services, after which the main domain can be opened. Client and room-server configuration can be changed in the `client` and `room-server` folders. The README says changes are not necessary for basic operation, but it points to separate component repositories for configuration-property examples.

This is a server installation procedure rather than a local client setup. Its documented result is a self-hosted meeting service available through the configured main domain.

Network and certificate constraints in edumeet

edumeet has a public network contract that extends beyond ordinary web hosting. The README requires two FQDNs, one for the main service and one for the TURN server. Both must point to the public IP. Distinct names give the proxy and media-facing service separate hostnames, but they also create two DNS records that must remain correct when providers or addresses change.

TLS is handled through the `certbot` container and mounted certificate directories. The README describes `run-first.sh` as preparing certificates and requesting an email address, while the Compose file runs a certificate renewal loop. It does not document the exact DNS or HTTP challenge configuration. It also does not explain recovery after a domain migration or certificate renewal failure, so those cases require validation during installation.

The README recommends opening `40000-40249/udp` and `40000-40249/tcp` for better connectivity, while the shown TURN service uses `50000` to `60000`. The README does not explain the difference. This discrepancy should be treated as a deployment warning rather than normalized into one range without checking the generated configuration.

The proxy also publishes `443:443/udp`, while the README's prerequisite list calls for `443/tcp`. Operators should compare the firewall rules with the checked-in Compose file and browser connectivity requirements. A service can start successfully while public media connectivity still fails because these external paths are outside the container lifecycle.

Configuration ownership and upgrade work for edumeet

The README states that releases are distributed as Docker images using the `stable` tag. It lists `edumeet-client`, `edumeet-room-server`, `edumeet-media-node`, and `edumeet-management-server`. Recorded releases include `4.0.0` from 2024-03-14, `3.5.6` from 2023-04-24, and `3.5.5` from 2022-12-20. The last push was on 2026-09-25, and the repository is not archived.

A recent push does not by itself establish compatibility between every client image, room-server image, configuration directory, and external identity provider. The README does not provide an upgrade matrix, rollback procedure, migration guide, or documented process for moving between releases. It also does not explain how to pin a specific image version if an operator does not want the moving `stable` tag.

The deployment mounts client and room-server configuration directories into containers. Those files therefore need to remain compatible with the image versions being run. Certificate state, `.env`, proxy templates, TURN settings, and persistent volumes are also relevant to service state, although the repository file does not enumerate every retained path beyond the certificate and configuration mounts shown in the Compose configuration.

The README identifies the project under the MIT License. Organizations reviewing the source should inspect `LICENSE.md` for redistribution, notice, and compliance obligations. This is not legal advice, and the MIT project license should not be assumed to govern every dependency image or external service used in a deployment.

When edumeet is the wrong meeting-service choice

edumeet is a poor fit for an organization that wants meeting software without server administration. Its documented path depends on Docker and `docker-compose`, a public IP, DNS records, certificate handling, firewall decisions, and configuration files mounted into multiple containers. A managed meeting product places those infrastructure responsibilities with its provider, while edumeet gives the operator control over the service boundary.

It may also be unsuitable when required browser media behavior cannot be confirmed in advance. Local recording is documented but disabled by default, and the README does not state a supported browser matrix, recording-container list, participant limit, or behavior under constrained networks. Although the repository contains `WEBINAR-LOADTEST.md` and `WEBINAR.md`, their contents are not reproduced in the README, so the repository entry alone cannot support a capacity claim.

File sharing has another boundary. The README identifies a torrent solution under the hood but gives no retention or access policy. Teams that require centrally managed file storage, auditing, or predictable retention should not infer those properties from the feature table.

For organizations unwilling to own public connectivity and upgrades, a managed WebRTC meeting provider is the more direct alternative. edumeet's distinguishing trade-off is organizational control. It fits a team prepared to operate the server rather than simply join a vendor-operated service.

Editorial conclusion

Adopt edumeet when an organization needs a self-hosted meeting service and can operate Docker, DNS, TLS certificates, a public endpoint, and the associated network paths. Do not choose it when an externally operated platform or a deployment without infrastructure administration is required. Verify the public IP, two FQDNs, firewall rules, TURN configuration, authentication choice, and image compatibility before installation.

Frequently asked questions

Official sources

1. edumeet/edumeet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases