flutter-webrtc-server: a Go signaling server with TURN built in

One binary for signaling, TURN and the web client

flutter-webrtc-server is described as a simple WebRTC signaling server for flutter-webrtc and HTML5, and it is written in Go with an MIT licence.

The scope is narrow on purpose. A WebRTC peer connection needs a way for two peers to exchange session descriptions and ICE candidates, and that exchange needs a server. This project provides that server, and it provides two more things alongside it that a bare signaling service would not: a built-in TURN server, and the web client that serves the flutter web demo.

The TURN part comes from pion, and the project points at the pion turn server example in its feature list. It also supports the REST API for access to TURN services, described in the draft for TURN REST access. That matters because TURN normally needs shared credentials between the server and whoever allocates them, and the REST API is the standard way to hand out time limited credentials from an external TURN server.

The result is a single process that can serve a local development loop: the web client at the same port, signaling on the same port, and relay candidates from a TURN server that is already running.

There is a hosted instance, an online demo at demo.cloudwebrtc.com on port 8086, and a separate flutter-webrtc-demo repository that the project recommends for all platforms, with screenshots in the repository for iOS, Android and the HTML5 build in Chrome.

Running it locally needs a real certificate

The usage section is short, and the certificate step is the part people underestimate, because the server speaks TLS and browsers do not accept self-signed certificates without being told to.

The first step is the clone:

git clone https://github.com/flutter-webrtc/flutter-webrtc-server.git
cd flutter-webrtc-server

Then you create a self-signed certificate with mkcert, and the command is specific about where the files must land and which names go into the certificate:

brew update
brew install mkcert
mkcert -key-file configs/certs/key.pem -cert-file configs/certs/cert.pem  localhost 127.0.0.1 ::1 0.0.0.0

The key file goes to configs/certs/key.pem and the certificate to configs/certs/cert.pem, which tells you the server reads its TLS files from that directory rather than from environment variables. The names in the certificate matter: localhost and 127.0.0.1 cover local access, ::1 covers IPv6 loopback, and 0.0.0.0 is what the server listens on.

Running it is two commands:

brew install golang
go run cmd/server/main.go

Then you open https://0.0.0.0:8086 to use the flutter web demo. The port 8086 is the same one used by the hosted demo, and the scheme is https, which is why the certificate step is not optional.

For mobile testing the project points at the webrtc-flutter-demo repository rather than trying to make the web build do the job, which is the sensible split: the server is the same, the client is different.

Four dependencies and a Go version from 2018

The dependency list is short enough to read at a glance, and each entry tells you what the server is doing.

The WebSocket handling is gorilla/websocket at 1.5.3, which is the standard choice for a Go WebSocket server and the core of the signaling channel. The TURN server is pion/turn/v2 at 2.0.5, the same project whose example the documentation points at. Logging is rs/zerolog at 1.23.0. The INI configuration parsing is gopkg.in/ini.v1, which fits a server configured from a file rather than from flags, and the module also lists chuckpreslar/emission, a publish and subscribe library, which is the natural way to fan a signaling message out to the peers in a room. The test dependency is smartystreets/goconvey, marked as indirect.

The go directive is the line to notice. It reads 1.12, which is the language version the module was written against, and it is not an upper bound: a newer toolchain will still build it. What it does tell you is that the project has not been re-baselined against recent Go releases, and the dependency versions are similarly conservative, with gorilla/websocket still on 1.5.3 rather than a later minor.

The repository layout matches a small service. There is cmd/ for the entry point, pkg/ for the packages, configs/ for the configuration and the certificate directory, web/ for the client that gets served, a Makefile for building, screenshots for documentation, and a renovate.json, which tells you the dependency updates are automated rather than manual.

Five binaries from one Makefile

The Makefile is where this project looks like a release engineering setup rather than a demo, and it is worth reading because it shows how the artefacts are produced.

The version comes from git describe, so a build is stamped with the tags it was made from, and the release binaries are stripped with the -s -w linker flags.

The targets are per operating system, and each line is a cross compilation with CGO disabled so the result is a static binary that runs on a bare container or a minimal host:

The linux target produces an amd64 and an i386 binary, the darwin target produces an amd64 binary, and the windows target produces an amd64 and an i386 executable. The all target runs the three platform targets, release runs all and then zip, and the zip target packages the binaries together with the configs and web directories into flutter-webrtc-server-bin-VERSION.zip. There is also an upx target that compresses the binaries with upx -9, which is how a small server can ship in a smaller download.

Two things are missing from that list, and both matter. There is no container image target, no Dockerfile in the repository entries, so deploying this means building the binaries and shipping them with the configs and web directories. And there is no test target, despite goconvey being present as a dependency, so the continuous integration story for this repository is thin compared with the release story.

Signaling only, and the TURN you already run

The limitation is structural and worth being explicit about, because it is easy to assume this server does more than it does.

This is a signaling server. It brokers the connection setup between peers, it serves the web client, and it can relay traffic through TURN when a direct connection is not possible. It is not a selective forwarding unit, it does not terminate media, and it is not an SFU. Two clients that connect through it exchange media peer to peer, or through the TURN relay, but the server is not in the media path unless TURN is used.

The second limitation is the one the documentation states outright: if you need to use it in a production environment, you need more testing. That sentence is short and it is the honest summary of where this project sits.

There is a sensible alternative for anyone who already has TURN infrastructure. The project supports the REST API for access to TURN services, which is the standard mechanism for using an external TURN server with time limited credentials. Running your own TURN server, for instance the pion example this project itself points at, and pointing this signaling server at it through that API gives you the same relay capability with the relay under your own operational control, and it removes the bundled TURN server from the picture.

The other alternative is not a server at all. If your two peers are on a network you control and a direct connection works, a signaling server is still needed to exchange the session descriptions, so it cannot be removed, but it can be a much smaller deployment than the full bundle once TURN is external.

A 2021 release, an August 2026 push

The maintenance record is the thing to weigh before adopting this for anything long lived.

The repository's tagged releases are 1.0 from 2020-03-14, 1.0.1 from 2020-03-16 and v1.1.0 from 2021-02-02. So the newest published release is more than five years old. The last push to the repository was on 2026-08-25, which is inside the six month window in which the project can be described as receiving work, but the code has moved since v1.1.0 without a new tag.

That combination is not unusual for a small infrastructure project with a stable API. The signaling protocol between two clients does not change often, the WebSocket library has not needed a major bump, and the TURN dependency has stayed on the same major version. The renovate.json in the repository suggests dependency updates are handled automatically rather than by hand, which is the kind of arrangement that keeps a quiet project safe.

What it means for you is concrete. If you pin to v1.1.0 you get a 2021 build. If you take master you get whatever has landed since, including the fixes, with no release notes to tell you what changed. For a local development server, that trade is fine. For something you intend to keep running, you should vendor the commit you test rather than track a branch, and be prepared to maintain it yourself.

The licence is MIT, with the licence file at the root of the repository, which is the permissive end of the scale and means you can fork it without ceremony, though your counsel should confirm anything specific to your organisation.

Editorial conclusion

flutter-webrtc-server suits a developer who wants a working WebRTC call between a flutter-webrtc app and a browser today, without assembling a signaling service, a TURN server and a certificate by hand. It is the wrong choice for a production deployment that has to be defended, since the documentation itself says production use needs more testing and the newest tagged release is from 2021, and it is the wrong choice if you already run TURN infrastructure, because the bundled server duplicates something you may have. Verify three things before you build on it: that your clients can reach the built-in TURN server through the ports you expose, that the certificate you generate with mkcert is the one your client will trust, and whether the version you pull from master matches the behaviour your flutter-webrtc client expects.

Frequently asked questions

Official sources

1. flutter-webrtc/flutter-webrtc-server on GitHub
2. Issues
3. License: MIT
4. README
5. Releases