# Galène: a lightweight Go server for WebRTC group calls

> Galène is an MIT-licensed Go videoconferencing server for operators who want a self-hosted SFU rather than a managed conferencing service. The README provides a short build and group-access example, while production networking and administration are documented in separate files.

**jech/galene** — The Galène videoconference server

- Repository: https://github.com/jech/galene
- Website: https://galene.org
- Stars: 1,422 · Forks: 205
- Language: Go
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jech-galene

## The deployment problem addressed by Galène

Galène targets operators who need to operate a videoconferencing server rather than rely on a hosted meeting platform. Its repository topics identify it as an SFU and a WebRTC application, while the project name and homepage establish its focus on group videoconferencing. This places it in the server-side category of self-hosted conferencing software: an operator runs the Go process, defines access to meeting groups, and directs a browser or compatible client to the server.

The README describes Galène as "fully-featured" and says it requires "very moderate server resources," but it does not quantify CPU use, memory use, participant limits, or call capacity. Those numbers should not be inferred from the repository description. The concrete scope is still meaningful: a single Go server binary, file-backed group data, a web-facing HTTPS endpoint, and separate documentation for usage, administration, clients, protocol, and API operations.

This is primarily an infrastructure choice, not an application for end users installing meeting software on each laptop. The person adopting it must still decide where the server will run, how participants will reach it, which certificate it will present, and how identities and permissions are administered. The quick start covers only enough of those concerns to demonstrate one group and one operator account.

## Galène's Go server and WebRTC data path

The repository is a Go module named `github.com/jech/galene`, and its entry point is `galene.go`. Based on the package layout, the implementation is divided into areas such as `conn/`, `group/`, `rtpconn/`, `rtptime/`, `sdpfrag/`, `ice/`, `turnserver/`, `token/`, and `webserver/`. That organization points to separate handling of connections, groups, RTP media, session descriptions, ICE, TURN, tokens, and HTTP or WebSocket service delivery.

The dependency list reinforces this structure. Galène uses `github.com/pion/webrtc/v4`, with related Pion packages for ICE, RTP, RTCP, SDP, data channels, and TURN. It also depends on `github.com/gorilla/websocket`, which is relevant to a browser-facing signaling path, although the README does not provide the exact client-server exchange. The separate `galene-protocol.md` file is identified as the client protocol documentation.

Media processing is also visible in dedicated packages. `estimator/` relates to estimation, `jitter/` to jitter handling, `packetcache/` and `packetmap/` to packet organization, and `diskwriter/` to writing data to disk. The `codecs/` package indicates media codec handling. These names show a modular server implementation, but they do not justify claims about recording formats, congestion behavior, scalability, or recording workflows because those details are not documented in the README.

## Building the binary and entering the night-watch group

The README's quick start is a source build rather than an installation from a package registry. The following commands clone `master`, compile a static binary without cgo, create a `groups` directory, and write the first group configuration. The build command is copied exactly from the README:

```sh
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups
echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &
```

The JSON file defines one user named `vimes`, assigns the password `sybil`, and grants the permission value `op`. Running `./galene &` leaves the server as a background process in the example. This is suitable for a first demonstration, not evidence of a production service manager, restart policy, log destination, or upgrade procedure.

After starting the process, open the group URL below. The README directs the browser to an HTTPS endpoint on the server's local port. Because the quick start has not configured a trusted certificate, it instructs the user to accept the unknown certificate warning.

```text
https://localhost:8443/group/night-watch/
```

Log in with `vimes` and `sybil`. The expected first result is access to the group named `night-watch`, although the README does not describe the exact meeting controls or test call procedure.

## TLS, TURN, and client boundaries in the documented example

The short tutorial ends at `https://localhost:8443`, but it does not explain how to replace the unknown certificate with one issued by a trusted certificate authority. That omission matters because the example is suitable for demonstrating a local connection, while a public deployment needs network trust and likely DNS configuration. The repository lists `cert` as a direct dependency, but the README does not show the certificate command or configuration used in production.

The dependencies include Pion TURN and the repository includes `turnserver/`, so Galène has code related to TURN. However, the README does not state when an external TURN service is mandatory, whether it can be omitted for some networks, or which deployment configuration connects it to the server. It would be unsafe to reduce Galène deployment to the eight quick-start lines without consulting `galene-install.md` and `galene.md`.

Client compatibility is another boundary. The README links to `galene-client.md` for writing clients and to the Galène website for answers to common questions. It does not identify supported browsers, operating systems, native clients, or a default client version. A browser-based call may work differently across networks if UDP paths are blocked and TURN is unavailable, but the exact fallback behavior is not stated in the README.

## Operational limits of JSON groups and the example account

The quick start stores access data directly in `groups/night-watch.json`. That makes the first group visible in the filesystem and gives administrators a concrete file to inspect. It also means this example has no secret-management service, identity-provider integration, or database. Those alternatives are not documented in the README, so they should not be presented as supported Galène deployment models.

The only permissions value shown is `op`, assigned through the user's `permissions` field. The README does not enumerate other permission levels, explain how meeting roles are assigned during a call, or document whether group membership can be changed without restarting the server. Any adoption decision that depends on granular moderation roles must check `galene.md` and `galene-api.md` rather than extrapolating from the single key.

The tutorial also embeds a literal password in shell output. That is acceptable for a disposable demonstration, but the README does not provide password hashing, rotation, recovery, or multi-factor authentication instructions. Production identity policy is therefore not established by the quick start. The linked administration and API files are the first places to verify those requirements.

## Galène compared with a full-mesh conferencing design

The repository identifies Galène as an SFU. The practical architectural alternative for a small browser call is a full-mesh design in which each participant sends media directly to every other participant. Those approaches differ in topology: the SFU model uses a server to relay selected media flows, while full mesh creates a participant-to-participant mesh and sends each stream several times.

The full-mesh approach can fit a small, controlled group with capable peer connections. Its deployment burden is concentrated in the clients, and there is no central media server to operate. It becomes less practical as participant count rises because each client must manage and encode or receive multiple peer relationships. Galène moves group media coordination to a server process, which makes server deployment, identity configuration, and network reachability part of the operator's work.

This comparison does not establish that Galène uses less bandwidth for every call or supports every conference size. Bandwidth depends on topology, stream layout, codecs, and participant behavior, none of which are quantified in the README. The grounded distinction is architectural: Galène centralizes media handling in a self-hosted Go SFU, while a full-mesh client application distributes peer connections among participants.

## Maintenance signals and upgrade work in the Go repository

The repository is not archived, and its last push was on 2026-10-04. That supports a current maintenance signal, although it does not establish release cadence because the repository has no GitHub releases. Upgrade policy is not documented in the README, so operators cannot assume that every commit represents a supported release.

The module declares `go 1.24.0`. An upgrade can therefore affect the Go toolchain, `go.mod`, `go.sum`, and pinned dependencies, not just the compiled server binary. The repository includes `CHANGES`, which is the most direct listed file for checking documented changes, but the README does not describe its contents or a release workflow. The MIT license permits use and modification under its terms; this is a factual license statement, not legal advice about deployment, privacy, or regulatory compliance.

Because no container recipe, system service unit, configuration schema, or backup procedure appears in the README, the operational upgrade cost cannot be stated precisely. The documented continuation path is to consult `galene-install.md`, `galene.md`, and `CHANGES` before replacing a running binary.

## Conclusion

Galène suits operators comfortable running a Go service and managing WebRTC deployment details, especially when a self-hosted SFU and JSON group configuration are acceptable. It is a poor fit for someone seeking a documented turnkey service, since the README points to separate installation, client, protocol, and administration guides. Before adoption, verify that galene-install.md covers the target operating system, certificate, firewall, and TURN requirements for the intended network, then confirm that an available Galène client supports the required call workflows.

## FAQ

### How do I build and start a Galène server for a first group call?

Clone the repository, run the README's `CGO_ENABLED=0 go build -ldflags='-s -w'` command, create a JSON file under `groups`, and start `./galene`. Then open `https://localhost:8443/group/night-watch/` and use the credentials defined in that JSON file.

### Does the Galène quick start create a production-ready HTTPS setup?

No such claim is made. The quick start directs the user to ignore an unknown certificate warning, while the full certificate and deployment procedure is referred to `galene-install.md`.

### What should I check before deploying Galène beyond the quick-start demonstration?

First consult `galene-install.md`, `galene.md`, `galene-client.md`, and `galene-api.md` for the target deployment, client, and administration requirements. Also inspect the JSON permission model and decide how certificate and TURN networking will be provided.

## Sources

- [Issues](https://github.com/jech/galene/issues)
- [jech/galene on GitHub](https://github.com/jech/galene)
- [License: MIT](https://github.com/jech/galene/blob/master/LICENSE)
- [Project website](https://galene.org)
- [README](https://github.com/jech/galene/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jech-galene