Galène (or Galene) is a videoconference server (an “SFU”) that is easy to deploy and that requires very moderate server resources. It was originally designed for lectures, conferences and student tutorials, but is also useful for traditional meetings.
Galène has been used in production at two major universities (Université de Paris and Sorbonne Université) for lectures, practicals, seminars, and for staff meetings. It has been used to host two conferences (SOCS'2020 and JFLA'2021).
While traffic is encrypted and authenticated from sender to server and again from server to receiver, Galène does not perform end-to-end encryption: anyone who controls the server might, in principle, be able to access the data being exchanged. For best security, you should install your own server.
Galène's is not the only self-hosted WebRTC server. High-quality alternatives include Janus, Ion-SFU, and Jitsi.
Galène is free and open source software, subject to the MIT licence. Galène's development was partly supported by Nexedi.
Go to galene.org:8443 and choose public or public/whatever, for any value of whatever.
git clone https://github.com/jech/galene
Mailing list archives, Atom feed.
Please subscribe to the galene at lists.galene.org mailing list. This list is both for user questions and development of Galène.
Get the source code by doing
These packages are provided by users, and have not necessarily been verified by Galène's author.
The server is complete:
The web browser frontend is functional:
A number of features are currently only available as commands to be
typed in the chat window (type
/help for help).
A native Android client for Galene is in development. The web client is usually a better choice, but the native Android client supports screensharing, which is not possible in a mobile browser. The client is expected to work on all devices running Android 5 or later.
For a typical lecture (100 students), Galène needs roughly 1/4 of a CPU core.
For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core. For many-to-many communication (meetings), the behaviour is quadratic (the server load grows as the square of the number of participants), expect to be able to handle on the order of 20 participants in a single meeting on one core, 40 on four cores (and of course way more if some participants don't switch their camera on — we've had staff meetings with forty participants or so, but only a few had their cameras switched on at a given time).
Be aware however that I am neither a security specialist nor a competent system administrator, and I may have gotten something wrong.