Galène (or Galene) is a videoconference server (an “SFU”) that is easy to deploy and that requires moderate server resources. It was originally designed for lectures and conferences (where a single speaker streams audio and video to hundreds or thousands of users), but later evolved to be useful for student practicals (where users are divided into many small groups), and meetings (where a dozen users interact with each other).
Galène is 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).
Galène's server side is implemented in Go, and uses the Pion implementation of WebRTC. The server is regularly tested on Linux/amd64 and Linux/arm64; it has also been shown to run on Linux/armv7 and Linux/mips (OpenWRT), and even on Windows. It should in principle be portable to other systems, including Mac OS X. The client is implemented in Javascript, and works on recent versions of all major web browsers, both on desktop and mobile (but see the FAQ for caveats with specific browsers).
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 is supported by Nexedi, who used to fund Alain Takoudjou's work on the user interface.
Go to galene.org:8443 and choose public (no password required).
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.
Galène's protocol is designed to be shared by multiple clients. In addition to the default client, at least the following are available:
The server is reasonably complete:
The following server features have been implemented, but haven't been merged into the mainline yet:
The following server features are planned but haven't been implemented yet:
The following features would be nice to have, but need support from the browser:
I am less sure about the following features:
The Javascript frontend needs some love, but it is quite usable:
A number of features are currently only available as commands to be
typed in the chat window (type /help for help). If you don't
like our frontend, it should be easy to roll your own:
human-readable outline,
API documentation.
For a typical lecture (less than 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 fourty participants or so, but only a few had their cameras switched on at a given time).
Galène assumes that the server is trusted: all media is decrypted by the server and reencrypted before it is sent to the clients. This is, as far as I know, unavoidable with DTLS-SRTP, the security mechanism used by WebRTC. (Yes, I know about insertable streams.) On the other hand, since the client is not trusted, any bugs in the client code should in principle not create security issues. Thus, it is reasonable to build user-friendly clients using the unscrutable Javascript frameworks that web developers tend to like.
Be aware however that I am neither a security specialist nor a competent system administrator, and I may have gotten something wrong.