Tuwunel for Docker

Docker

To run tuwunel with Docker you can either build the image yourself or pull it from a registry.

Use a registry

OCI images for tuwunel are available in the registries listed below.

Registry	Image	Size	Notes
GitHub Registry	ghcr.io/matrix-construct/tuwunel:latest		Most recent tagged release. Recommended for automated updates (~monthly).
Docker Hub	docker.io/jevolk/tuwunel:latest		Most recent tagged release. Recommended for automated updates (~monthly).
GitHub Registry	ghcr.io/matrix-construct/tuwunel:preview		Selected higher-confidence updates between releases (~weekly).
Docker Hub	docker.io/jevolk/tuwunel:preview		Selected higher-confidence updates between releases (~weekly).
GitHub Registry	ghcr.io/matrix-construct/tuwunel:main		Every reviewed merge to the main branch (~daily).
Docker Hub	docker.io/jevolk/tuwunel:main		Every reviewed merge to the main branch (~daily).

Run

When you have the image you can simply run it with

docker run -d -p 8448:8008 \
    -v db:/var/lib/tuwunel/ \
    -e TUWUNEL_SERVER_NAME="your.server.name" \
    -e TUWUNEL_ALLOW_REGISTRATION=false \
    --name tuwunel $LINK

or you can use docker compose.

The -d flag lets the container run in detached mode. You may supply an optional tuwunel.toml config file, the example config can be found here. You can pass in different env vars to change config values on the fly. You can even configure tuwunel completely by using env vars. For an overview of possible values, please take a look at the docker-compose.yml file.

If you just want to test tuwunel for a short time, you can use the --rm flag, which will clean up everything related to your container after you stop it.

Health check

The image ships a HEALTHCHECK which runs tuwunel --health-check: it reads the same configuration as the server, connects to each configured listener, and requests /_tuwunel/server_version. Container platforms report the result as the container’s health status. The probe reads the configuration from the environment and any config file named by TUWUNEL_CONFIG; arguments passed on the container command line are not visible to it, so when configuring via command-line arguments override the health check accordingly. The probe targets the configured listeners, so sockets passed in by a process manager (systemd socket activation) are not covered. The same flag also works outside containers, e.g. as a Kubernetes exec probe.

Docker-compose

If the docker run command is not for you or your setup, you can also use one of the provided docker-compose files.

Depending on your proxy setup, you can use one of the following files:

• If you already have a traefik instance set up, use docker-compose.for-traefik.yml
• If you don’t have a traefik instance set up and would like to use it, use docker-compose.with-traefik.yml
• If you want a setup that works out of the box with caddy-docker-proxy, use docker-compose.with-caddy.yml and replace all example.com placeholders with your own domain
• For any other reverse proxy, use docker-compose.yml

When picking the traefik-related compose file, rename it so it matches docker-compose.yml, and rename the override file to docker-compose.override.yml. Edit the latter with the values you want for your server.

When picking the caddy-docker-proxy compose file, it’s important to first create the caddy network before spinning up the containers:

docker network create caddy

After that, you can rename it so it matches docker-compose.yml and spin up the containers!

Additional info about deploying tuwunel can be found here.

Run

If you already have built the image or want to use one from the registries, you can just start the container and everything else in the compose file in detached mode with:

docker compose up -d

Note: Don’t forget to modify and adjust the compose file to your needs.

Nix build

Tuwunel’s Nix images are built using buildLayeredImage. This ensures all OCI images are repeatable and reproducible by anyone, keeps the images lightweight, and can be built offline.

This also ensures portability of our images because buildLayeredImage builds OCI images, not Docker images, and works with other container software.

The OCI images are OS-less with only a very minimal environment of the tini init system, CA certificates, and the tuwunel binary. This does mean there is not a shell, but in theory you can get a shell by adding the necessary layers to the layered image. However it’s very unlikely you will need a shell for any real troubleshooting.

The flake file for the OCI image definition is at nix/pkgs/oci-image/default.nix.

To build an OCI image using Nix, the following outputs can be built:

• nix build -L .#oci-image (default features, x86_64 glibc)
• nix build -L .#oci-image-x86_64-linux-musl (default features, x86_64 musl)
• nix build -L .#oci-image-aarch64-linux-musl (default features, aarch64 musl)
• nix build -L .#oci-image-x86_64-linux-musl-all-features (all features, x86_64 musl)
• nix build -L .#oci-image-aarch64-linux-musl-all-features (all features, aarch64 musl)

Use Traefik as Proxy

As a container user, you probably know about Traefik. It is a easy to use reverse proxy for making containerized app and services available through the web. With the two provided files, docker-compose.for-traefik.yml (or docker-compose.with-traefik.yml) and docker-compose.override.yml, it is equally easy to deploy and use tuwunel, with a little caveat. If you already took a look at the files, then you should have seen the well-known service, and that is the little caveat. Traefik is simply a proxy and loadbalancer and is not able to serve any kind of content, but for tuwunel to federate, we need to either expose ports 443 and 8448 or serve two endpoints .well-known/matrix/client and .well-known/matrix/server.

With the service well-known we use a single nginx container that will serve those two files.

Voice communication

See the TURN page.